Serverless in production, an experience report (IWOMM)

in production
an experience reportan experience report
what you should know before you go to production
ServerlessServerless

Yan Cui
http://theburningmonk.com
@theburningmonk
Domas Lasauskas

hey guys, vote on this post
and I’ll announce a winner at
10PM tonight

low utilisation to leave room for spikes
EC2 scaling is slow, so scale earlier

lots of $$$ for unused resources

up to 30 mins for deployment
deployment required downtime

- Dan North
“lead time to someone saying
thank you is the only reputation
metric that matters.”

“what would good
look like for us?”

be small
be fast
have zero downtime
have no lock-step
DEPLOYMENTS SHOULD...

FEATURES SHOULD...
be deployable independently
be loosely-coupled

WE WANT TO...
minimise cost for unused resources
minimise ops effort
reduce tech mess
deliver visible improvements faster

170 Lambda functions in prod
1.2 GB deployment packages in prod
95% cost saving vs EC2
15x no. of prod releases per month

1st function in prod!
time
is a good fit

?
time
is a good fit

ALERTING
CI / CD
TESTING
LOGGING
MONITORING

Practices ToolsPrinciples
what is good? how to make it good? with what?

170 functions
? ?
time
is a good fit

SECURITY
DISTRIBUTED TRACING
CONFIG MANAGEMENT

Legacy Monolith Amazon Kinesis Amazon Lambda
Amazon CloudSearch

Amazon CloudSearchAmazon API Gateway Amazon Lambda

Google BigQuery

Google BigQuery
1 developer, 2 days
design production
(his 1st serverless project)

Google BigQuery
“nothing ever got done
this fast at Skype!”
- Chris Twamley

Expensive operations
SNS retries for “free”

nov, 2016
Decouple using events
Small iterative features
Proxy old endpoints
Focus on delivering value
Leverage cloud services
recap

choose a tried-and-tested
deployment framework,
don’t invent your own

https://github.com/awslabs/serverless-application-model

https://github.com/claudiajs/claudia

https://github.com/Miserlou/Zappa

Level of Testing
1.Unit
do our objects do the right thing?
are they easy to work with?

Level of Testing
1.Unit
2.Integration
does our code work against code we
can’t change?

handler
test by invoking
the handler

Level of Testing
1.Unit
2.Integration
3.Acceptance
does the whole system work?

Level of Testing
unit
integration
acceptance
feedback
confidence

Don’t Mock Types You Can’t Change

Don’t Mock Types You Can’t Change
Services

Paul Johnston
The serverless approach to
testing is different and may
actually be easier.
http://bit.ly/2t5viwK

LambdaAPI Gateway DynamoDB
Unit Tests

Unit Tests
Mock/Stub

is our request correct?
is the request mapping
set up correctly?is the API resources
conﬁgured correctly?
are we assuming the
correct schema?
is Lambda proxy
conﬁgured correctly?
is IAM policy set
up correctly?
is the table created?
what unit tests will not tell you…

most Lambda functions are simple
have single purpose, the risk of
shipping broken software has largely
shifted to how they integrate with
external services
observation

optimize towards shipping working
software, even if it means slowing
down your feedback loop…

learning the wrong thing faster does not
help us deliver working software faster

Test Input

Test Input
Validate

integration tests exercise
system’s Integration with its
external dependencies
my code

acceptance tests exercise
system End-to-End from
the outside
my code

integration tests differ from
acceptance tests only in HOW the
Lambda functions are invoked
observation

end-to-end tests exercise both
the system and the process by which
it’s built and deployed
…has to be done
anyway repeatedly
during the software’s
lifetime…

Yan
the earlier you consider CI/CD
the more time you save in the
long run

Yan
deployment scripts that only
live on the CI box is a disaster
waiting to happen…

Jenkins build config deploys and tests
unit + integration tests
deploy
acceptance tests

if [ "$1" = "deploy" ] && [ $# -eq 4 ]; then
STAGE=$2
REGION=$3
PROFILE=$4
npm install
AWS_PROFILE=$PROFILE 'node_modules/.bin/sls' deploy -s $STAGE -r $REGION
elif [ "$1" = "int-test" ] && [ $# -eq 4 ]; then
STAGE=$2
REGION=$3
PROFILE=$4
npm install
AWS_PROFILE=$PROFILE npm run int-$STAGE
elif [ "$1" = "acceptance-test" ] && [ $# -eq 4 ]; then
STAGE=$2
REGION=$3
PROFILE=$4
npm install
AWS_PROFILE=$PROFILE npm run acceptance-$STAGE
else
usage
exit 1
ﬁ

if [ "$1" = "deploy" ] && [ $# -eq 4 ]; then
STAGE=$2
REGION=$3
PROFILE=$4
npm install
STAGE=$2
REGION=$3
PROFILE=$4
npm install
STAGE=$2
REGION=$3
PROFILE=$4
npm install
else
usage
exit 1
ﬁ
install Serverless Framework
as dev dependency

if [ "$1" = "deploy" ] && [ $# -eq 4 ]; then
STAGE=$2
REGION=$3
PROFILE=$4
npm install
STAGE=$2
REGION=$3
PROFILE=$4
npm install
STAGE=$2
REGION=$3
PROFILE=$4
npm install
else
usage
exit 1
ﬁ
install Serverless Framework
as dev dependency
mitigate version
conflicts

build.sh allows repeatable 
builds on both local & CI
or NPM script, or Gradle, or …

nov, 2016
Automate early
Reproducible locally & on CI
Use version control
Release process to fit your team
recap

2016-07-12T12:24:37.571Z 994f18f9-482b-11e6-8668-53e4eab441ae
GOT is off air, what do I do now?

2016-07-12T12:24:37.571Z 994f18f9-482b-11e6-8668-53e4eab441ae
GOT is off air, what do I do now?
UTC Timestamp API Gateway Request Id
your log message

…but you can stream them somewhere else
CloudWatch Logs are too basic

CloudWatch Logs AWS Lambda ELK stack

AWS CloudTrail 
events on resource operations
CloudWatch Events

a user
my followers didn’t receive
my new post!

correlation IDs*
* eg. request-id, user-id, yubl-id, etc.

wrap HTTP client & AWS SDK clients
to forward captured correlation IDs

kinesis client
http client
sns client

use X-Ray for performance tracing

X-Ray traces do not span over API
Gateway, or async event sources

no place to install agents/daemons

• invocation Count
• error Count
• latency
• throttling
• granular to the minute
• support custom metrics

• same metrics as CW
• better dashboard
• support custom metrics
https://www.datadoghq.com/blog/monitoring-lambda-functions-datadog/

my code
internet internet
press button something happens

those extra 10-20ms for
sending custom metrics
would compound when
you have microservices
and multiple APIs are
called within one slice
of user event

Amazon found every 100ms of latency
cost them 1% in sales.
http://bit.ly/2EXPfbA

no more background processing,
other than what the platform provides

console.log(“hydrating yubls from db…”);
console.log(“fetching user info from user-api”);
console.log(“MONITORING|1489795335|27.4|latency|user-api-latency”);
console.log(“MONITORING|1489795335|8|count|yubls-served”);
timestamp metric value
metric type
metric namemetrics
logs

CloudWatch Logs AWS Lambda
ELK stack
logs
metrics
CloudWatch

don’t forget to setup dashboards
& CW alarms

design for easy & quick
propagation of conﬁg changes

me
Environment variables make it
hard to share conﬁgurations
across functions.

me
Environment variables make it
hard to implement ﬁne-grained
access to sensitive info.

sensitive data should be encrypted
in-ﬂight, and at-rest

enforce role-based access to sensitive
conﬁguration values

SSM Parameter Store
HTTPS
role-based access
encrypted in-flight

SSM Parameter Store
encrypt
role-based access

SSM Parameter Store
encrypted at-rest

HTTPS
role-based access
SSM Parameter Store
encrypted in-flight

invest into a robust client library

invalidate at interval & weak signals

that’s all for now, folks ;-)

API Gateway and Kinesis
Authentication & authorisation (IAM, Cognito)
Testing
Running & Debugging functions locally
Log aggregation
Monitoring & Alerting
X-Ray
Correlation IDs
CI/CD
Performance and Cost optimisation
Error Handling
Configuration management
VPC
Security
Leading practices (API Gateway, Kinesis, Lambda)
Canary deployments
http://bit.ly/production-ready-serverless
get 40% off
with: ytcui

@theburningmonk
theburningmonk.com
github.com/theburningmonk

Serverless in production, an experience report (IWOMM)

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Serverless in production, an experience report (IWOMM)

Similar a Serverless in production, an experience report (IWOMM) (20)

Más de Yan Cui

Más de Yan Cui (20)

Último

Último (20)

Serverless in production, an experience report (IWOMM)