Going Serverless with AWS Lambda? Here's what you should know
Serverless has gone mainstream now: it’s the natural next-step in the evolution of cloud-computing.
The value proposition is that you can:
- Focus exclusively on your application code
- Pay only for actual compute time and resources consumed.
All infrastructure is completely abstracted away. Well :) in theory, perhaps… in practice things are a bit different.
Here is a very high-level overview of AWS Lambda, Amazon Web Services' implementation of serverless computing.
Runtime Context:
- AWS Lambda’s current implementation runs your code within a Docker container under the hood. Your code has access to the Docker scratch volume for a filesystem.
- Lambda supports specific versions of runtimes. Custom runtimes can be built or shimmed.
Execution:
- Lambda functions can have a “cold start” time when executed after an interval since the container needs to be booted up. It’s possible to keep the function “warm” via a ping or health check.
- You can design your function to reuse expensive resources (db connections etc) between immediate invocations.
- Lambdas have built-in retries on failures. Retry is triggered based on exit code or callback error.
- Lambdas can have a DLQ (Dead-letter Queues) to collect failed events for investigation or additional processing.
- Each Lambdas can run for a max of 15mins, after which they will be killed. The available time remaining to execute can be inspected within Lambda.
- The amount of compute and memory allocated to the Lambda determines how fast it will run. Pricing is based on 100ms increments and reserved CPU/Memory (vs. actually used). The first million Lambda invocations per account are free every month.
- AWS Lambda has concurrency limits - max 1000 concurrent lambdas executing at one time. You can reserve concurrency for critical Lambda functions if necessary.
- AWS Step Functions can be used to compose complex workflows using Lambda functions.
Triggers:
- AWS Lambdas are typically invoked in response to (the ever expanding) list of event sources.
- Lambdas can be “manually” invoked as well from other code, cli tools or via the AWS Console.
- Invocation can be synchronous (Request/Response) or Asynchronous (Fire and Forget)
- Lambdas permissions are handled via IAM Roles. Event sources may need to be given IAM permissions to invoke Lambda functions.
- Lambda integrates well with the AWS API Gateway service. External APIs can trigger Lambda functions and Lambdas can perform Authentication/Authorization or serve as a proxy for APIs as well.
- Lambdas can be triggered via internal Application Load Balancers, via target groups and on schedule via CloudWatch Scheduled events.
VPCs:
- Lambdas can execute either outside a VPC (i.e only uses other AWS Services i.e S3, DynamoDB) or within a VPC (can access VPC-specific resources - RDS, EC2 instances etc).
- When executing within a VPC, every function will provision an ENI (elastic network interface) within the VPC in order to access resources, say in a private subnet. One ENI (& IP address) per subnet.
- To make AWS service calls, AWS Lambdas running inside a VPC will need internet access, even inside a private subnet i.e via NAT-ing (NAT Gateway or Instance). You can get around this for some services by using VPC endpoints.
Other:
- AWS Lambda offers encryption via KMS (Key Management Service) for environment variables during execution.
- AWS X-Ray (tracing) support is available for Lambda functions. Helpful to see where latency is being introduced.
- Lambda logs are automatically sent to CloudWatch LogStreams. The request ID and time billed and memory used are logged per invocation.
- There are many tools to facilitate deployment to AWS Lambda. Serverless.com is big. AWS has it’s own tool called SAM.
I am a huge fan of serverless computing and find AWS Lambda to be an extremely powerful tool, as long as you understand and use it within it’s limitations.
Questions? Comments? Concerns? Feel free to ping me.