What are some best practices for serverless applications? Paul Johnston gives his opinion based on his widely shared blog post bit.ly/serverlessbestpractices
Axa Assurance Maroc - Insurer Innovation Award 2024
Serverless Best Practices - Serverless Computing London
1. Medium/Twitter: @PaulDJohnston
Serverless Best Practices
Paul Johnston
Opinionated Serverless Person
“Serverless all the things”
Medium/Twitter: @PaulDJohnston
Serverless Computing London November 2018
4. Medium/Twitter: @PaulDJohnston
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
6. Medium/Twitter: @PaulDJohnston
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
7. Medium/Twitter: @PaulDJohnston
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
12. Medium/Twitter: @PaulDJohnston
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
17. Medium/Twitter: @PaulDJohnston
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
Serverless Best Practices
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
20. Medium/Twitter: @PaulDJohnston
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
22. Medium/Twitter: @PaulDJohnston
Practice 1: Scaling
Function
Function Function
Function Function
Function Function
Assumption: All logic is
equal within function
Scaling up of function
23. Medium/Twitter: @PaulDJohnston
Practice 1: Scaling
Function
Function Function
Function Function
Function Function
Assumption: All logic is
equal within function
Scaling up of function
24. Medium/Twitter: @PaulDJohnston
Practice 1: Scaling
Function
Scaling up of function
= Logic within function code
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
25. Medium/Twitter: @PaulDJohnston
Practice 1: Scaling
Scaling up of function logic
as needed
= Logic within function code
Memory and compute
allocated as required
Function
Function
Function
1 GB + 3 second timeout
256MB + 500 ms timeout
128MB + 15 second timeout
26. Medium/Twitter: @PaulDJohnston
Practice 1: Debugging
= Logic within function code
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
!!!
29. Medium/Twitter: @PaulDJohnston
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
30. Medium/Twitter: @PaulDJohnston
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
36. Medium/Twitter: @PaulDJohnston
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
37. Medium/Twitter: @PaulDJohnston
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
38. Medium/Twitter: @PaulDJohnston
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
39. Medium/Twitter: @PaulDJohnston
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
40. Medium/Twitter: @PaulDJohnston
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
41. Medium/Twitter: @PaulDJohnston
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
42. Medium/Twitter: @PaulDJohnston
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
43. Medium/Twitter: @PaulDJohnston
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
44. Medium/Twitter: @PaulDJohnston
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
58. Medium/Twitter: @PaulDJohnston
Practice 4: Service interfaces
Concurrent Functions
n = 1000s?
e.g. DynamoDB
Need to be aware
of provisioning
Managed Service
Interface
More likely to be
able to scale up
60. Medium/Twitter: @PaulDJohnston
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)
61. Medium/Twitter: @PaulDJohnston
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
64. Medium/Twitter: @PaulDJohnston
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
65. Medium/Twitter: @PaulDJohnston
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}
67. Medium/Twitter: @PaulDJohnston
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
76. Medium/Twitter: @PaulDJohnston
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
78. Medium/Twitter: @PaulDJohnston
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
89. Medium/Twitter: @PaulDJohnston
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
90. Medium/Twitter: @PaulDJohnston
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
91. Medium/Twitter: @PaulDJohnston
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
97. Medium/Twitter: @PaulDJohnston
Practice 8: Scale all the things
Your application is more than just functions
What are your application dependencies?
Data stores?
Third Party Services?
+ ? + Scale = ?
102. Medium/Twitter: @PaulDJohnston
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
109. Medium/Twitter: @PaulDJohnston
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
110. Medium/Twitter: @PaulDJohnston
Serverless Best Practices
Paul Johnston
Opinionated Serverless Person
“Serverless all the things”
Medium/Twitter: @PaulDJohnston
Serverless Computing London November 2018