Serverless Best Practices - Serverless Computing London

Medium/Twitter: @PaulDJohnston
Serverless Best Practices
Paul Johnston
Opinionated Serverless Person
“Serverless all the things”
Serverless Computing London November 2018

Paul Johnston
Experienced Interim CTO and Serverless
Consultant - linkedin.com/in/padajo
C-Level Consultant
Environmentalist #ClimateChange bit.ly/2024wp
Twitter/Medium @PaulDJohnston
Co-founder ServerlessDays (formerly JeffConf)

Cloud, Data Centres and Energy

Future of Cloud and Climate
Data Centres at least 2% of Global Carbon Emissions (bigger than aviation)
Growth of Cloud/Data Centres likely to grow by at least 5x in next 7 years
Efficiency is irrelevant due to Jevons Paradox - increased efficiency leads to
increased demand
Not just climate, but energy security - energy price rises
Whitepaper written by Anne Currie and myself bit.ly/2024wp
And Bitcoin energy consumption? About the same as Austria
https://digiconomist.net/bitcoin-energy-consumption

Ethics Whitepaper - The State of Data Centre
Energy Use in 2018

Background - Movivo
CTO of Movivo in 2015
One of the first Serverless startups
Android App + AWS Lambda
By early 2017 was in 20+ countries with over
500,000 MAU
AWS bill was ~$300/month (half data backup)
Team of 2 serverless and 2 android developers in
total

Background - AWS
Senior Developer Advocate for Serverless
2017-18
Part of Lambda Product Team
Responsible for speaking about Lambda, API
Gateway, Step Functions, Serverless Application
Repository, Lambda@Edge and other services
Met and did workshops with many serverless
customers

bit.ly/serverlessbestpractices

bit.ly/serverlessbestpractices*
*not the only practices and you can break the rules if you want

What is Serverless?

Serverless is Inherently
Event Driven
And
Asynchronous*
*Consequence of FaaS and Queues

Definition of Serverless
“A Serverless solution is one that
costs you nothing to run if nobody is
using it, excluding data storage.”
Me - September 2017

Serverless is
Economic
not Technological

So Serverless is about
Business
not
Technology*
*Consequence of CTO thinking

Serverless Best Practices blog:
bit.ly/serverlessbestpractices
August 2018

Each function should do only one
thing
Functions don’t call other functions
Use as few libraries in your functions
as possible (preferably zero)
Avoid using connection based
services e.g. RDBMS
One function per route (if using
HTTP)
Learn to use messages and queues
(async FTW)
Data flows not data lakes
Just coding for scale is a mistake,
you have to consider how it scales

Practice 1:
Each Function should do
only one thing

Scaling And Error Isolation
(If you have a switch statement, you’re doing it wrong)

Practice 1: Scaling
Lots of tutorials/frameworks put monoliths into functions (miniliths) - Microservices
If you have multiple logic elements, then you have to scale memory and compute
to the most hungry element

Practice 1: Scaling
Function
Function Function
Function Function
Function Function
Scaling up of function
= Logic within function code

Practice 1: Scaling
Function
Function Function
Function Function
Function Function
Assumption: All logic is
equal within function

Practice 1: Scaling
Function
Function Function
Function Function
Function Function
Memory and compute
allocated for most
memory/compute intensive
compute e.g.
e.g. 1 GB + 15 second timeout

Practice 1: Scaling
Scaling up of function logic
as needed
Memory and compute
allocated as required
Function
Function
Function
1 GB + 3 second timeout
256MB + 500 ms timeout
128MB + 15 second timeout

Practice 1: Debugging
Function
Function
Function
1 GB + 3 second timeout
256MB + 500 ms timeout
128MB + 15 second timeout
Errors are easier to debug
and can replace functions
with minimal disruption
!!!

Practice 1:
Each Function should do
only one thing
FunctionFunctionFunction

Practice 2:

Practice 2: Functions and Microservices
Functions != Microservices
Logically you might think it’s ok to call other functions
Removes isolation
Doubles cost
Makes debugging more complex

Practice 2: Function calling
FunctionFunction
Direct invoke
Doubling up invoke cost
Removes isolation
If errors occur, it’s more
difficult to identify in logs
which function is
responsible

Practice 2: Use queues
FunctionFunction
Queue Trigger
⚡
Replace with a queue
Automatic trigger

Practice 2: Use data stores
FunctionFunction
Data Store Trigger
⚡
Or a data store
Automatic trigger

Practice 2: Unidirectional
FunctionFunction
Data Store Trigger
⚡
Unidirectional

Practice 2:
FunctionFunction
⚡

Practice 3:
Use as few libraries in your functions as
possible (preferably zero)

Practice 3: Show me the code… vulnerabilities
Libraries make things easier...
…but always introduce technical debt
It’s a trade off
If you know it (really know it) and trust it then use it
But then you manage that on top of your logic

Practice 3: AWS Lambda Function Lifecycle
Full Cold Start
Start new
container
Bootstrap the
runtime
Start your
code
Time
AWS Optimisation Your Optimisation
Partial Cold Start Warm Start
Download your
code
Source: AWS Online Tech Talks - Become a Serverless Black Belt - Optimizing Your Serverless Applications

Practice 3: Small packages
Download your
code
Small packages are faster to download
Not a major optimisation for speed
But fewer lines of code are easier to debug

Practice 3: Global variables and connections
Bootstrap the
runtime
Global variables loaded before
execution
Lazy loading is a good idea
Libraries loaded here can be a real
problem. What is being loaded?
Using Practice 1 - Each function
should only do one thing - then this
should limit your libraries

Practice 3: Code optimisation
Start your
code
Most optimisation is found here - your code
If you have zero libraries, then this is where most of
your optimisation is
Reliance on libraries here may seem like you have
fewer lines of code in functions, but actually many
more lines of actual code

Practice 3: LOC
Lines of Code matters
Not just your code, but libraries too - 1 library can have many dependencies
So no libraries unless you absolutely have to
It’s amazing what you don’t need
And Cold Starts are often very fast when you have very few libraries

Practice 3: e.g. AWS SDK
npm init -y
npm install --save aws-sdk
echo "var AWS = require('aws-sdk');" > index.js
sloc ./
---------- Result ------------
Physical : 503378
Source : 295886
Comment : 197692
Single-line comment : 5458
Block comment : 192281
Mixed : 1794
Empty : 16109
To Do : 33
Number of files read : 620
------------------------------
295,886 Lines of Source Code

Practice 3: No express or django
Functions were not built for running server based solutions
So don’t use them
It adds in huge amounts of unnecessary code written for servers
It doesn’t save time in the long run

Practice 3:
Use as few libraries in your functions as
possible (preferably zero)
Start new
container
Bootstrap the
runtime
Start your
code
Download your
code

Practice 4:
Avoid using connection based services
e.g. RDBMS

WARNING
WARNING
WARNING

Practice 4: Bottlenecks
Concurrent Functions
RDBMS
n = 20
100 connections
limit

RDBMS
n = 20 ALL GOOD
100 connections
limit

Scale x4

RDBMS
n = 80
100 connections
limit

RDBMS
n = 80 ALL GOOD
100 connections
limit

100 connections
limit
RDBMS
n = 320

RDBMS
n = 320 NO CONNECTIONS
100 connections
limit

Practice 4: Solution?
RDBMS
n = 320
Connection
pooling proxy?
throttle as
needed
100
connections

Practice 4: Service interfaces
n = 320
e.g. DynamoDB
Managed Service
Interface

Practice 4: Service interfaces
n = 1000s?
e.g. DynamoDB
Need to be aware
of provisioning
Managed Service
Interface
More likely to be
able to scale up

Practice 4: Upstream scale
Serverless
Functions
Connections
Data Layer
Other Services
Concurrency of
functions
defined by
upstream scale

Practice 4: Beware of I/O
Serverless
Functions
Connections
Data Stores
Other Services
Concurrency of
functions
defined by
upstream scale
Be aware of I/O (cold start)

Practice 4: Rethink your data layer
Small spikes in functions can max out connections in a database
Concurrency can limit your scale
Your data layer constraints affect how you build your functions and applications
Managed data services are likely to be able to scale better than trying to scale
yourself

Practice 4:
Avoid using connection based services
e.g. RDBMS
Managed Service Interface

Practice 5:
One function per route (if using HTTP)

Practice 5: HTTP routes - API Gateways
Relatively common use case
A lot of tutorials are “miniliths” - a single function to handle all routes
Others are “run django, express etc in a function” (middleware?)
Easy to start (Hello World!), more difficult to isolate errors (Practice 1)
Can make it difficult to decouple data layer from functions

Practice 5: API Gateways - easy start, doesn’t scale
Single proxy
function
or django/express
style function
APIGateway
Internet
GET /
POST /posts
GET /posts/{id}
POST /authors
GET /authors/{id}

Practice 5: API Gateways
APIGateway
Internet
GET /
POST /posts
GET /posts/{id}
POST /authors
GET /authors/{id}
Fn 1
Fn 2
Fn 3
Fn 4
Fn 5

Practice 5: Lots of functions - manage it!
This does increase the number of resources
Each function will need security rules and may need secrets etc
So, use infrastructure as code
E.g. Terraform, SAM, CloudFormation, Serverless Framework, Architect, Stackery

Practice 5:
One function per route (if using HTTP)
GET /
POST /posts
Fn 1
Fn 2

Practice 6:
(async FTW)

Practice 6: So queues (from Practice 2)
FunctionFunction
Queue Trigger
⚡
Automatic trigger

Practice 6: And data stores (from Practice 2)
FunctionFunction
Trigger
⚡
Automatic trigger
Data Store

Practice 6: Event pattern
Trigger
⚡
Automatic trigger
Thing
? Function

Practice 6: Event pattern
Trigger
⚡
Automatic trigger
Thing
? Function
RUN STUFF WHEN STUFF
HAPPENS

Practice 6: Event pattern - queues
Trigger
⚡
Automatic trigger
Queue Function
Push messages in
Asynchronous
is not request
response
Circuit breaker
{
“Data”:
{
“a”: [
...

Practice 6: Event pattern - queues
Trigger
⚡
Automatic trigger
Queue Function
Happy path
Errors...
DLQ?
Blocking?
Non-Blocking?

Practice 6: Async queues and messages
Decouples logic through queues
Primarily stops you building request-response
Learn to use circuit breakers
Understand which queues to use and when

Basically, learn how distributed systems work

Practice 6: CQRS
Command Query Responsibility Segregation
Basically Reads and Writes go through different logic
Trigger on data writes
Build caches to read from
Asynchronous

Practice 6:
(async FTW)
⚡
{
“Data”:
{
“a”: [
...

Practice 7:

Your data in your application is always in motion

Applications are not code

Applications are like landscapes and water

Practice 7: Data flows and Data lakes
Data Lake
Data Flows

Practice 7: Data flows into Data lakes

Practice 7: Data flows
Data flows through your application
Queues - Functions - Events
Fast Data Stores - Caches, Fast Reads/Writes
Performant data throughput
Scale considerations are higher
e.g Document DBs, K/V stores, blob stores

Practice 7: Data lakes
Data ends up in a lake
Lots of different types of data
Usually the end of a data flow
Less need for performance
Scale considerations are lower
e.g. RDBMS, Logging, Analytics

Practice 7: Changing data flows
Easier to reroute a data flow
Than to dam a lake
Events allow for flexible data structures
Rigidity makes rerouting harder
Applications always change, and this allows
for it

Practice 7: Data flows
Your application
Is more about the
flows
than it
is about the
lakes
Application

Practice 7:
Application

Practice 8:
Just coding for scale is a mistake, you
have to consider how it scales

Just because the
Function
scales does not mean the
Application
will scale

What are upstream and downstream effects?

Practice 8: Scale all the things
Your application is more than just functions
What are your application dependencies?
Data stores?
Third Party Services?
+ ? + Scale = ?

Practice 8:
Just coding for scale is a mistake, you
have to consider how it scales
+ ? + Scale = ?

Quick Point:
These are “Best Practices”
not “Only Practices”*
*know the practices so that you can understand when to break them

Paul Johnston
Experienced Interim CTO and Serverless
Consultant - linkedin.com/in/padajo
C-Level Consulting
Introducing and Moving to Serverless
Building Teams
Cloud Agnostic
Contact: paul@roundaboutlabs.com or
Twitter/Medium @PaulDJohnston

Serverless Best Practices - Serverless Computing London

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Serverless Best Practices - Serverless Computing London

Ähnlich wie Serverless Best Practices - Serverless Computing London (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Serverless Best Practices - Serverless Computing London