AWS Lambda is a compute service that runs code without the developer having to manage the infrastructure which it runs on. The compute resources are automatically managed by AWS. The code is triggered to execute based on events, in other words the code runs on demand. AWS charges only for code execution time.
AWS Lambda is an ideal compute platform for many application scenarios, provided that you can write your application code in languages supported by AWS Lambda, and run within the AWS Lambda standard runtime environment and resources provided by Lambda.
Lambda Features
- Scales out (not up) automatically
- Functions are independent, 1 event = 1 function
- Serverless
- Can trigger other lambda functions, 1 event can = x functions
- Architectures can get extremely complicated. AWS X=ray allows you to debug lambda
- Can do things globally, like back up S3 buckets to other S3 buckets
- Several trigger types
- Several languages supported
Evolution of Server-side Computing
These are some of the major evolution steps in server-side computing:
- Mainframes (1950s – 1970s )
- Minicomputers / Personal Computers (1970s)
- Virtualization / Hypervisors (mid-2000s)
- Cloud Servers (2006+)
- Serverless Computing (2015+)
Server-less has a cost benefit over previous managed infrastructure in that only execution time is paid for. It removes maintenance and management cost of the infrastructure/platform. This also elevates complexities related to infrastructure and keeps focus on the execution process only. It creates a separation of concern and as such, it is much easier to integrate server-less programs with other services and infrastructure.
The major server-less providers are (as of 2016)
- AWS Lambda
- Azure Functions
- Google Cloud Functions
- Iron.io *one of the first server-less computing providers
- IBM Open Whisk
It’s important to note that server-less computing requires an event to start the execution. Some of these event types are:
- File Upload
- Scheduled Time
- API Request
Requirements and Limitations
Being that AWS Lambda is one of the newest services provided and only a few years old, there are some limitations to take note of.
- Lambda functions must be less than 250MB uncompressed
- Lambda functions must be less than 50MB compressed
- The total number of functions in a single region must be less than 75GB
- Must use less than 1000MB of memory
- Must execute under 300 seconds
- Cannot run more than 100 concurrent functions
- Any other service lambda interacts with must be in the same region
There are some workarounds for the above limitations. Also, these limitations are as of 2017. It is expected to change over time.
Managing Functions
From the AWS console, the Lambda designer can be used to configure triggers, layers, and destinations.
- Triggers – Triggers are services and resources that you have configured to invoke your function.
- Layers – Choose the Layers node to add layers to your application. A layer is a ZIP archive that contains libraries, a custom runtime, or other dependencies.
- Destinations – Add a destination to your function to send details about invocation results to another service. You can send invocation records when your function is invoked asynchronously, or by an event source mapping that reads from a stream.
Invoking Functions
You can invoke Lambda functions directly with the Lambda console, the Lambda API, the AWS SDK, the AWS CLI, and AWS toolkits. You can also configure other AWS services to invoke your function, or you can configure Lambda to read from a stream or queue and invoke your function.
When you invoke a function, you can choose to invoke it synchronously or asynchronously. With synchronous invocation, you wait for the function to process the event and return a response. With asynchronous invocation, Lambda queues the event for processing and returns a response immediately. For asynchronous invocation, Lambda handles retries and can send invocation records to a destination.
An event source mapping is an AWS Lambda resource that reads from an event source and invokes a Lambda function. You can use event source mappings to process items from a stream or queue in services that don’t invoke Lambda functions directly. Lambda provides event source mappings for the following services.
- Kinesis
- DynamoDB
- SQS
The following example shows an event source mapping that reads from a Kinesis stream. If a batch of events fails all processing attempts, the event source mapping sends details about the batch to an SQS queue.
Programming Model for Lambda Functions
The following notes come from here:
https://docs.aws.amazon.com/lambda/latest/dg/programming-model-v2.html
The following core concepts are common patterns for any Lambda function:
- Handler
- This is what starts the function execution
- In the project examples, this is the index.handler method
- Context Object
- Lambda passes the context object for all function calls (2nd parameter after the event parameter)
- This object is used to interact with AWS Lambda service
- Optionally, for node.js functions, there is the callback parameter, which can be seen in the example
- Logging
- Logging to CloudWatch
- Exceptions
- Function invoked during exceptions/errors
References
AWS Developer Guide
https://docs.aws.amazon.com/lambda/latest/dg/lambda-introduction-function.html
Scalable AWS API Gateway (pluralsight)
William Button; 2016
https://app.pluralsight.com/player?course=scalable-aws-api-gateway
AWS Developer Introduction (pluralsight)
Fernando Corey; 2017
https://app.pluralsight.com/player?course=aws-developer-introduction-aws-lambda
AWS Serverless with NodeJS
https://app.pluralsight.com/player?course=aws-nodejs-serverless-framework-using