Seattle Serverless

June 2019 🚀

Brian LeRoux

CTO, co-founder begin.com
co-author of arc.codes server-less pundit @brianleroux

Ref: article about making CFN turing complete

Context Required

A brief history of our relationship to serverless. 
Nov 2014: chilly PnW morning AWS Lambda was released
me: this is interesting *





* said warming my hands over a dumpster fire of HTTP servers

Aug 2015: api gateway release 
me: ... it is time then
We started work on what would become Architect that November and
Lambda was roughly one year old …API Gateway barely a few months old



  We were VERY aware this was early and going to be painful. It was.



But…why go servers-less then?



  
Only paying for what you use 💸
 (💯% utilization)





Better security model 🔐

No ports to scan!





  
Focusing on business value 💰
 instead of managing infra






3 🔑 reasons to serverless


    

  • 💰 Fixed costs

  • 🔒 Better security

  • 🎢 Faster iterations







  
Mini-talk: 3 things that totally sucked about serverless late 2015

  
    
    
  1. Coldstart!
    
  2. DynamoDB or gtfo
    
  3. Cloudformation support
  





  
Coldstart


We observed the problem


We observed cold start correlated to the function payload size

  
We determined that sub 5mb functions remained consistently subsecond

  
We started authoring sub 5mb functions





  
3 things that

  
DO NOT

  
solve coldstart





  
pings

  
DOES NOT

  
solve coldstart





  
lambda warmers

  
DOES NOT

  
solve coldstart





  
putting web servers into functions

  
DOES NOT

  
solve coldstart





  
Sub 5mb Lambda functions

  
MOSTLY

  
solves coldstart





  Consider using a framework, like arc.codes, that encourages small functions.




  
DynamoDB or GTFO





  We tried using traditional databases, elastic search and elastic cache (redis)




  
It was swimming upstream

  But it is better now




  DynamoDB consistently great product that just keeps getting better




  Maybe you can avoid DynamoDB by using… S3?!




  
Cloudformation

  

  1. Did not support the services we needed it to

  2. Severe limits (200 ish resources)

  3. Really slow iteration cycles (for us and them!)

  4. Verbose and difficult to debug configuration

  





  Begrudgingly, and like so many before us,  we started by writing our own provisioning scripts.




  Our goal was to support building a database backed web app.




  We needed the primitives for CRUD apps: http routes, fast read/write of structured data and background tasks.




  We wanted iteration speed, zero downtime deploys, stateful http via stateless endpoints.




  Build one to throw away?




  
Mini talk: 17 Lessons Learned





  
Lesson 1: Coldstart can be defeated

  Sub 5mb functions; no web servers its server-less remember!




  
Lesson 2: Small functions better on all dimensions

  Faster to read, write and debug. What can be better than that?




  
Lesson 3: NO functions is even better

  API Gateway proxying is a delicious hack.




  Lesson 4 
convention > configuration

  Config is liability just as is code. (Just ask GCP this wknd.) Seek to eliminate it with conventions and smarter defaults.




  
Lesson 5: Namespace units of deployment

  Infra is cattle; versions belong to revision control not deployment artifacts




  
Lesson 6: Deps need to be in sync within a deployment namespace

  Deps needed to be automated and synchronized across a namespace of deployment




  
Lesson 7: There is Common Code

  There will be common code that needs to be shared within a deployment namespace that is too small/specific for publishing to a module registery. That's ok. 




  
Lesson 8: Runtime needs Context

  Runtime needs to know about its app context (find resources: tables, buckets, broadcast events or to publish to queues




  
Lesson 9: functions are cheap/disposable

  Run lots; ideally in parallel




  
Lesson 10: functions can be deployed in parallel

  Monolithic apps have lots of functions too… and no isolation. They cannot be deployed in parallel ever.




  
Lesson 11: DynamoDB is Fucking Awesome

  Just use it ok.




  
Lesson 12: S3 and Lambda are amazing together

  use it for static assets. use it for JSON data.




  
Lesson 13a: evented everything

  take everything possible off the user path with either sns events or sqs queues




  
Lesson 13b: SQS and SNS are subtly different

  Slightly different approaches and guarentees for delivery.




  
Lesson 13c: Cloudwatch Scheduled Events

  Super powerful combined with feedback control systems.




  
Lesson 13d: State Machines?

  queues/events/scheduled can be consolidated into a single primitive 'step function'




  Bonus!
  
Lesson 14: Lambda works REAL GOOD with S3

  Static assets




  
Lesson 14b: Lambda works REAL GOOD with S3

  Flat file data base?
    
  • S3 Select
    
  • S3 Batch
  

    • 

    
  
    Lesson 15: Regions are a leaky abstraction
    
  
    
  • regionless will be a thing: stacksets?
    
  • CDN is only part of the story
  

    • 

    
  
    Lesson 16: Accounts are the best unit of isolation
    
  
    
  • one per person
    
  • bonus: one per person per app!
  

    • 

    
  
    Lesson 17: Infra as Code
    
  
    
  • Non optional! as in: required
    
  • Reproducability and determinism
    
  • Precursors: chef, puppet, anisible, salt, reems of fucking yaml/bash
    
  • Rising stars: Terraform (2014), CFN (2011), SAM (Nov 2016)
  

    • 


    
  
    
  What did we do with what we learned...?
  
    

    

    
  We did the unthinkable.

    

    
  
    Heresy #1
    
  We created a manifest format .arc which stood for 'amazon run commands' because we wanted to be cool like .bashrc, .vimrc, etc

    

    
  goals

    

    
  Be terse and as syntax free as possible; solve for one of the biggest problems of XML

    

    
  Have comments; solve for one of the biggest problems of JSON

    

    
  Discourage nesting; solving for the biggest problem of YAML

    

    
  Support for basic scalar values: String, Number, Boolean

    

    
  Support for complex values: Vector and Map

    

    
REALLY terse; we want to express the infrastructure with the minimum readable syntax

    

    
REALLY terse; we want to remember how to express infra without reference docs

    

    
  
  Read more about the format here: architect/parser

    


    
  
    Hacker News
    
  
    HATED IT
    
  So we knew it was doing something good (and unique).

    

    
  
    HN gets a bad rap; you can judge for yourself
     
  Full thread here

    

    
  Heresy #2

    

    
  
    Architect was not Cloudformation based
    
  Was not a realistic option for our requirements at that time.

    

    
  
    Aside: Don't Judge Tech Choices
    
  
    Unless it is K8s
    
  Haha, jk. Rails is cool.

    

    
  Stable! Documented! Tested!
  
    Architect 5.x 🎉
    
  NOT Cloudformation based 😭; install arc.codes.

     

    
  SAM/CFN based ALPHA! Documented! Tested!
  
    Architect 6.x 🎉
    
  npm install -g @architect/cli

    

    
  WARNING! Beta code. Demo gremlins. Etc!

    


    
  
    Architect 6.x Highlights
    
  
      
    
    1. Work locally!
    
    2. Staging and production are first class concepts
    
    3. Node, Python and Ruby fully supported
    
    4. Export as sam.json
    
    5. Deploy with Cloudformation
    
    6. 🆕 Dirty deploy 
    
    7. Distribute with SAR
  
    

    




    
  
    Get Involved in JSF Architect
    
  
      
  
    • 💓 Pull requests are always nice
  
    • 🐞 Bug reports are APPRECIATED
  
    • 🦋 Feature requests are APPRECIATED
  
    • 🎙 Share what you learn on Twitter or blogs
  
    

    


    
  
    thx eh!
    
  @brianleroux