Serverless & Stateless
One year in, what we’ve learnt
Intro
• Been working on distributed apps for 10 years.
• Accordo’s new app has been built serverless* from the ground up and
has been in production seven months
• Why serverless? Simple, get a lot more done for your business by not
worrying about instances and administration.
* Disclaimer: At Accordo, Serverless has a broader meaning than static sites and FaaS
This isn’t all that new
If you struggle to explain to the boss. Think if it as
outsourcing to the best in the business
Simply the next generation of distributed apps and
containerisation
Serverless challenges are often just distributed
app challenges
Main app overview
1. Static website served via
cloudfront. Site is build using
React, Redux and webpack
2. Users authenticate via auth0
3. Access data apis using JWT
and APIGW
4. Most apis are implemented
as lambdas.
5. Main data in RDS postgres
6. Same lambdas for user apis
apso process async messages
Authorization – JWT claims based
Mind your (core) business
• Developers vary in skill, capacity and maturity, but
they’re all expensive for what you get.
• Every day, they turn up and write ‘stuff’. Make sure
they’re working on stuff that matters.
• Any hour spent on functionality not core to your
business is potential waste
Potential waste?
- A/B testing
- Alerting
- Analytics & Tracking
- Authentication
- Database
- Email
- Failover
- Queues & Message processing
- Reporting
- Search
- Automated Tests (not the testing)
- Configuration management
- Logging
- Permissions
Good ROI
Serverless Vs
The Twelve-Factor App
Can feel like a mis-match, but not impossible.
…and getting easier.
https://12factor.net
FaaS Vs Twelve-Factor pain points
- Configuration
- Much improved. was a major pain. Azure and
now AWS have environment variables.
- FaaS frameworks still have a tendency to
bundle config with build and or use named
environments.
- Ideally configuration management and
updates don’t require a re-build of app.
- Build artifacts
- Immutable build artifacts that and can be
deployed to any environment.
- Still Nothing of the shelf, but there are good
SDKs, not that hard to roll your own.
- Managed CI/CD is fine for nano services or
calculators. Be careful of loosing environment
control with larger components (build promotion,
rollbacks, config)
Frameworks
How to Manage your app?
- Developer workflow
- Build  Test  Artifact  Deploy
- Configuration
- Triggers & Endpoints
All frameworks have opinions. Some you’ll agree with.
Some….
Be clear on how you want to work, try not to
compromise
- CI for a user facing app – needs a lot of test
automation
- Its ok, it’s an evolving world, the frameworks will
catch up.
AWSServerless Application Model (SAM)
Log everything
- Logging services are the debugger
- Be careful of sensitive info.
- Log the positive and negative
- Keep them as long as is practical
- console.log(), console.time()
- Excited about AWS X-Ray or other things like Netflix
Vizceral
Warning 1 – alias confusion
AWS lambda Aliases and Versioning -
Great idea, very powerful useful concept but….. no support
for Alias level log groups or configuration.
V3
V2
V1
DEV
UAT
PROD
UAT API Stage
UAT API Stage
UAT API Stage
V2 logs
V2 code
V? config
Warning 2 – the cold start
Cold function invocation is a problem on AWS and
Azure. Webpack and sensible dependency
management helps the load speed.
Best band-aid to keep them alive is Cloudwatch +
a scheduled event. Event input can be
customised to a heartbeat type call.
Cold load is slow. Cold VPC load is like dial-up
speed. If function calls any outside resource it
waits for an ENI. Can be > 30 sec….
Semi related – database calls with
context.callbackWaitsForEmptyEventLoop
Warning 3 – Lambda Fast, API Gateway Slow
Calls to API gateway are routed through
cloudfront. Low traffic* APIs suffer from high
latency delays within cloudfront.
Delays reasons cited are low connection reuse,
routing algorithms and extra SSL handshakes.
This is made worse by app making OPTIONS calls.
You need to manually add ‘Access-Control-Max-
Age’
CORS OPTIONS call often takes ~1 second!
* Low traffic is less than 100 requests per second
Same level of latency affects all APIGW calls.
Common to see 1.5 sec round trip, but just 0.1 sec
lambda execution
Top 3 Integrations
Fastly - Consider a better CDN
Auth0 - Authenticate with anything…
Segment – Integrate with anything
Real-time CDN lets you purge content near
instantly - less than 150ms!
Cache API responses
One integration to rule them all…
Developer first, anything is possible
Testing
Write testable code, Strive for functional
Abstract the calling interface asap (lambda | azure | mocha)
Don’t sweat too much about the mocking side of things. We’re not testing AWS or
Azure
Links
Tidy diagrams https://cloudcraft.co/app
Some Auth strategies
https://aws.amazon.com/blogs/compute/introducing-custom-authorizers-in-amazon-api-gateway
https://auth0.com/docs/integrations/aws-api-gateway
Twelve-factor App https://12factor.net
Lambda Versioning & Aliases http://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html
One of the latency forum threads
https://forums.aws.amazon.com/message.jspa?messageID=729169#729169
Thanks!
linkedin.com/in/myles-henaghan

Serverless meetup Auckland #6

  • 1.
    Serverless & Stateless Oneyear in, what we’ve learnt
  • 2.
    Intro • Been workingon distributed apps for 10 years. • Accordo’s new app has been built serverless* from the ground up and has been in production seven months • Why serverless? Simple, get a lot more done for your business by not worrying about instances and administration. * Disclaimer: At Accordo, Serverless has a broader meaning than static sites and FaaS
  • 3.
    This isn’t allthat new If you struggle to explain to the boss. Think if it as outsourcing to the best in the business Simply the next generation of distributed apps and containerisation Serverless challenges are often just distributed app challenges
  • 4.
    Main app overview 1.Static website served via cloudfront. Site is build using React, Redux and webpack 2. Users authenticate via auth0 3. Access data apis using JWT and APIGW 4. Most apis are implemented as lambdas. 5. Main data in RDS postgres 6. Same lambdas for user apis apso process async messages
  • 5.
  • 6.
    Mind your (core)business • Developers vary in skill, capacity and maturity, but they’re all expensive for what you get. • Every day, they turn up and write ‘stuff’. Make sure they’re working on stuff that matters. • Any hour spent on functionality not core to your business is potential waste
  • 7.
    Potential waste? - A/Btesting - Alerting - Analytics & Tracking - Authentication - Database - Email - Failover - Queues & Message processing - Reporting - Search - Automated Tests (not the testing) - Configuration management - Logging - Permissions Good ROI
  • 8.
    Serverless Vs The Twelve-FactorApp Can feel like a mis-match, but not impossible. …and getting easier. https://12factor.net
  • 9.
    FaaS Vs Twelve-Factorpain points - Configuration - Much improved. was a major pain. Azure and now AWS have environment variables. - FaaS frameworks still have a tendency to bundle config with build and or use named environments. - Ideally configuration management and updates don’t require a re-build of app. - Build artifacts - Immutable build artifacts that and can be deployed to any environment. - Still Nothing of the shelf, but there are good SDKs, not that hard to roll your own. - Managed CI/CD is fine for nano services or calculators. Be careful of loosing environment control with larger components (build promotion, rollbacks, config)
  • 10.
    Frameworks How to Manageyour app? - Developer workflow - Build  Test  Artifact  Deploy - Configuration - Triggers & Endpoints All frameworks have opinions. Some you’ll agree with. Some…. Be clear on how you want to work, try not to compromise - CI for a user facing app – needs a lot of test automation - Its ok, it’s an evolving world, the frameworks will catch up. AWSServerless Application Model (SAM)
  • 11.
    Log everything - Loggingservices are the debugger - Be careful of sensitive info. - Log the positive and negative - Keep them as long as is practical - console.log(), console.time() - Excited about AWS X-Ray or other things like Netflix Vizceral
  • 12.
    Warning 1 –alias confusion AWS lambda Aliases and Versioning - Great idea, very powerful useful concept but….. no support for Alias level log groups or configuration. V3 V2 V1 DEV UAT PROD UAT API Stage UAT API Stage UAT API Stage V2 logs V2 code V? config
  • 13.
    Warning 2 –the cold start Cold function invocation is a problem on AWS and Azure. Webpack and sensible dependency management helps the load speed. Best band-aid to keep them alive is Cloudwatch + a scheduled event. Event input can be customised to a heartbeat type call. Cold load is slow. Cold VPC load is like dial-up speed. If function calls any outside resource it waits for an ENI. Can be > 30 sec…. Semi related – database calls with context.callbackWaitsForEmptyEventLoop
  • 14.
    Warning 3 –Lambda Fast, API Gateway Slow Calls to API gateway are routed through cloudfront. Low traffic* APIs suffer from high latency delays within cloudfront. Delays reasons cited are low connection reuse, routing algorithms and extra SSL handshakes. This is made worse by app making OPTIONS calls. You need to manually add ‘Access-Control-Max- Age’ CORS OPTIONS call often takes ~1 second! * Low traffic is less than 100 requests per second Same level of latency affects all APIGW calls. Common to see 1.5 sec round trip, but just 0.1 sec lambda execution
  • 15.
    Top 3 Integrations Fastly- Consider a better CDN Auth0 - Authenticate with anything… Segment – Integrate with anything Real-time CDN lets you purge content near instantly - less than 150ms! Cache API responses One integration to rule them all… Developer first, anything is possible
  • 16.
    Testing Write testable code,Strive for functional Abstract the calling interface asap (lambda | azure | mocha) Don’t sweat too much about the mocking side of things. We’re not testing AWS or Azure
  • 17.
    Links Tidy diagrams https://cloudcraft.co/app SomeAuth strategies https://aws.amazon.com/blogs/compute/introducing-custom-authorizers-in-amazon-api-gateway https://auth0.com/docs/integrations/aws-api-gateway Twelve-factor App https://12factor.net Lambda Versioning & Aliases http://docs.aws.amazon.com/lambda/latest/dg/versioning-aliases.html One of the latency forum threads https://forums.aws.amazon.com/message.jspa?messageID=729169#729169
  • 18.

Editor's Notes

  • #4 Story of running your app; Dedicated machines  hosted machines on demand  provisioning scripts  auto scaling & load balancing???  infrastructure as code  Docker  Docker as a service   just my code!!!!???
  • #5 API authorization via custom lambda, JWT, generate user specific policy Web app is React-Redux, webpack Nice diagramming - https://cloudcraft.co/app
  • #6 https://aws.amazon.com/blogs/compute/introducing-custom-authorizers-in-amazon-api-gateway/ Alternative; https://auth0.com/docs/integrations/aws-api-gateway
  • #7 New products, young company. You need to focus on building something useful, focus on finding something useful. Don’t get distracted by developers making problems
  • #8 https://stockfresh.com/image/6706947/concentrated-software-developer-eating-pizza-and-coding New products, young company. You need to focus on building something useful, focus on finding something useful. Don’t get distracted by developers.
  • #10 Must be able to send any build to any environment Can rollback.
  • #11 Working in teams vs deploy from your machine? Release approvals? Distributed teams? AB testing?
  • #12 Currently on log entries, looking at logz.io You’ll quickly outgrow cloudwatch or azure logs. Logs = errors, activity, anomalies, baseline performance
  • #13 Immutable versions – great idea. Instant rollbacks. Confidence in ‘what’s in there will work’ Instant deploys – just sway an alias to point from V1 to V2 The split brain lambda instance. Who am I? We pulled config from S3 and cached it in a global var. Separate config per invoked ARN. Invoked as ‘PROD’, apply the prod config, continue. It was messy. Problem still there with env vars. Would need to load all vars. That leads to named environments etc  In the end having production and and UAT going to sale cloudwatch log stream was just too messy. We abandoned it and now deploy an entire lambda per environment.
  • #14 If your function is directly responding to a user consider keeping them alive. If in VPC, it’s essential. Azure has classic deployment mode. Seems a step backwards. We have generic a generic ‘keep alive’ function Semi-related if making a database connection experiment with context.callbackWaitsForEmptyEventLoop With Sequalize and some other libs, this setting can cause the lambda to wait for the connection to time out even though you have your response already. One connection, short timeout, don’t wait.
  • #15 Double latency - https://forums.aws.amazon.com/message.jspa?messageID=729169#729169 AWS have discussed making Cloudfront part optional for small low volume APIs
  • #16 Double latency - https://forums.aws.amazon.com/message.jspa?messageID=729169#729169 CDN behaviour is very important to the static app, and becoming so for APIs. More locations, faster purging or invalidating. Controlling response headers Realtime API can cache app reference data and dramatically reduce load times to get your app running sooner. GETs, OPTIONS Auth0: Super flexible platform, Extendable through webtasks, You name it - they support it, Very responsive & helpful support. Cost effective. Segment – So many tools, so many script bundles. Marketing and experimentation teams have shifting opinions and demands. Put on one integration. Back end, front end, your partner services all sending to one stream.
  • #19 Serverless work in progress; - Step functions for file processing - Two-way notifications over websockets and IoT topics