Serverless applications with AWS Lambda and node.js

Topics

• Serverless
• AWS Lambda
• Benefits and drawbacks
• Use Cases
• Demo

Serverless

History

?

BaaS

FaaS

BaaS

• Rich client application
• Fully dependant on 3rd party providers
• Different approaches
  • Cloud databases
  • Authentication services

FaaS

• Backend code written by an actual developer
• Code runs inside compute containers
  • Stateless
  • Ephemeral (only live until end of execution)
  • Managed by the vendor
• Code needs to expose a conventional interface
• Triggered by events
  • HTTP calls
  • Database streams/triggers
  • Message Queues

Examples

Credit to Mike Roberts

http://martinfowler.com/articles/serverless.html

UI Driven Apps

UI Driven Apps

Message driven apps

Message driven apps

AWS Lambda

AWS Lambda lets you run code without provisioning or managing servers. You pay only for the compute time you consume - there is no charge when your code is not running. With Lambda, you can run code for virtually any type of application or backend service - all with zero administration. Just upload your code and Lambda takes care of everything required to run and scale your code with high availability. You can set up your code to automatically trigger from other AWS services or call it directly from any web or mobile app.

Without provisioning or managing servers

• This is the point of the term serverless
• Provisioning can become complicated and weird
• Management is expensive and exhausting
• Lambdas can be provisioned by hand or by IAC
  • CloudFormation
  • Terraform
• Logs are automatically dumped to CloudWatch

There is no charge when your code is not running

• High idle time of servers
• Limited budget for small projects
• No upfront investment with Lambda
• Pay per request & execution time

Any type of application or backend service

• It's just code - you have full control
• Predefined proxies for API Gateway -> Lambda
• Every library can be used
• (5 minutes execution limit)

Runs and scales your services

• Getting scaling right for usage peaks is hard
• Wrong predictions can cost tons of money
• High availability is science
• No long running processes in Lambda
• Every function execution (= request) gets a dedicated instance

Trigger from other AWS services or call it directly

• API Gateway can expose lambdas as HTTP controllers
• Event driven computing
  • DynamoDB Streams
  • S3 Events
  • Kinesis Streams
  • and many more
• Scheduled task running

Supported languages

Hello Lambda

module.exports.hello = (event, context, callback) => {
   return callback(null, "Hello lambda");
};

JSON response

module.exports.hello = (event, context, callback) => {
   return callback(null, JSON.stringify({
        message: "Hello lambda"
   }));
};

Reading the payload

module.exports.hello = (event, context, callback) => {
   return callback(null, "Hello " + event.name);
};

Returning errors

module.exports.hello = (event, context, callback) => {
    if (event.company != "NewStore") {
        return callback(
            "You're working for the wrong company",
            null
        );
    }
    return callback(null, "You made a good choice!");
};

API Gateway

module.exports.hello = (event, context, callback) => {
    // giving an error here would lead
    // to a 500 response code
    return callback(
        null, 
        {
            statusCode: 200,
            body: JSON.stringify({
                message: "Hello Lambda"
            })
        }
    );
};

Benefits and drawbacks

Benefits

• Reduced initial and development costs
• No server management
• Easy scaling
• Zero downtime deployments
• (Less integration work)
• (Easier to think the micro service way)

Greener computing

• Energy usage (CO2 consumption) becomes a problem
• Dedicated/virtual servers dedicate resources to one party
• Servers stay in idle most of their lifetime
• FaaS allocates resource only if they are needed
  • More efficient usage of servers

Drawbacks

Vendor coupling

• FaaS hosting is no excuse for bad separation of concerns
• Migration does not come for free but can be limited
  • Separating business logic and transport code
  • Implementing vendor specific data providers

Missing in-process state

• Services can not cache data in memory
  • They need to use 3rd party services - much slower
• Expensive application bootstrap needs to be done on every request
  • Connections can not be pooled and kept open

Configuration

• There is no de-facto configuration standard
• Hack most commonly used: generated config file
  
  
   
• AWS just introduced environment variable support!

Limited resources

• 5 minute execution limit on Lambda
• Maximum of 1000 parallel executions on Lambda
  • Account wide
  • Load testing on dev stage might nuke your production env if on same account
  • Learning: Use different accounts for dev and production

Startup latency

• Process needs to be started upon request
  • Hack: keep functions alive (use vendor cache)
• JVM Lambdas used to keep 10s until available

Testing

• Integration testing needs to code to run in a Lambda
  • Costs money
  • Might nuke your production system
• Current best practice: Shallow lambda wrapper and unit tested business logic
• How to stub out 3rd party services?
• (AWS is working on this!)

Deployment and Versioning

• Currently no concepts for versioned deployments
• Atomic rollbacks not out of the box
  • Need to use git + redeploy
• Event replay may be hard
• Events can hardly be stored
• Packaging is hard
  • If you have test tooling installed in your node_modules you will deploy it
  • Heavy configuration needed

Debugging

• No local development environment
  • Change and deploy workflow
• Need to go through CloudWatch for logs

It's easy to forget ops

• Going live is possible without ops
• You will face problems if lacking ops knowledge
  • Monitoring + metrics
  • Testing infrastructure
  • Security
• What if you get media coverage and you get > 1000 requests per second?

Use cases

Every kind of project *

What's the *?

• Do the math for your company
• 5 minutes max computation time
• Affordable end-2-end testing is still a riddle

Okay but when?

• Bootstrap a startup
• Kick off a side project
• Hosting customer specific code
• Managed scheduling
• Vendor specific processing
  • Processing images uploaded to S3
  • Send mails through SNS after AWS event

Field study

Situation

• Very small budget
• Side project - no time for server maintenance
• Handling payments - data loss is a nono
• SPA frontend - HTTP API based backend

Usage

• Saves coupon and payment data to DynamoDB
• Coupon PDF generation triggered by DynamoDB-Stream
• Mail sent with PDF as attachment using S3 events