AWS Lambda is a AWS Serverless service that lets you run code without actually thinking about the servers. In this post, the core features and configurational abilities are discussed.
Timeout
A lambda function can run from 3 seconds (default) to 15 minutes or 900 seconds. When considering lambda function during the design, the use case should align with this constraint. After 15 minutes, the lambda execution environment gets terminated.
Runtime Environment
Runtime Environment is the actual environment in which the code is supposed to be executed. Lambda supports a wide range of runtime environments including Python, Java, Nodejs, .NET, Ruby, go, C# and various others. In the chosen environment, only the default packages are included. If your script requires any other third-party libraries, then either those dependencies should be included as a part of deployment or a lambda layer can be utilized.
Layers
A lambda layer is a ZIP archive or the collection of dependencies needed for a lambda function to run. With the help of these layers, the dependencies and the actual business code can be isolated. Instead of including all the dependencies as a part of each lambda function, the lambda layer can be utilized.
Versioning
A lambda function once published can be versioned and aliased. This provides the flexibility to either roll back to a working version or point different services to unique versions if required.
Integrations
Lambda function can either be triggered manually to perform the task or ideally the lambda function is configured to a trigger event. If the result needs to be further processed then a destination service can also be configured. Lambda almost provides integration with most of the AWS Services.
Monitoring
The lambda executions can be monitored by using AWS CloudWatch Logs, AWS X-ray Services. By default, the lambda function creates a CloudWatch log group and start logging the execution logs. Other monitoring services needs to be explicitly configured and the necessary permissions has to be added to the lambda execution policy.
Concurrency
Lambda functions follow asynchronous invocation. So, the same lambda function can be triggered by multiple services and each request is handled in an isolated environment. An individual lambda can also be restricted to a certain number of concurrent lambda execution. The default concurrency limit for lambda functions is 1000 per account, this can be further increased if required.
Cold Starts
Each time a lambda function is triggered, there will be some delay before handling the actual request. Lambda function maybe a serverless service for us, but it internally runs on a server and that server's runtime environment needs to be setup as per the configured runtime. The delay is caused due to this setup and this delay is termed as Cold Start.
Provisioned Concurrency
To overcome the problem of Cold Starts, Provisioned Concurrency can be used. It the way of provisioning a certain number of lambda function ready even before the request. These x number of lambda functions will have the runtime setup configured already and start processing the request right after its arrival. This needs to configured mindfully as it might cost you a fortune if not done correctly. Since the lambda functions are being reserved, there will be an additional overhead cost for the duration of lambda functions during which they are awake.
Use cases
- File Processing
- Web Application Backend
- IoT Backends
- Stream Processing
- Transformation Layer in ETL process
Top comments (0)