Introduction
In the rapidly evolving landscape of cloud computing, AWS Lambda is an important innovation that redefines the way we build and deploy applications. It offers unparalleled simplicity, scalability, and cost-effectiveness. What makes AWS Lambda significant is that it represents a paradigm shift towards serverless computing, enabling developers to focus on crafting code and delivering seamless user experiences without the burdens of managing traditional server infrastructure.
Before discussing AWS Lambda, it is important to first throw some light on serverless.
What is serverless?
Simply put, serverless applications are the ones that don't need any server provision and do not require one to manage servers. In the context of Lambda functions, AWS does that for you.
AWS Lambda is an event-driven, serverless computing platform provided by Amazon as a part of Amazon Web Services. Therefore you don't need to worry about which AWS resources to launch, or how will you manage them. Instead, you need to put the code on Lambda, and it runs. Let's dive into some of the basic concepts, practical applications and limitations of Lambda Functions to get a good grasp and get one going quickly.
Basic Concepts
Function
A function is a program, code or script that runs in AWS Lambda. Lambda passes invocation events into your function, which processes an event and returns its response. The idea of a serverless solution is that a developer should focus only on the business side of things i.e the actual code to server customers run as functions in AWS Lambda
Runtimes
The runtime provides a language-specific environment that runs in an execution environment. The runtime relays invocation events, context information, and responses between Lambda and the function. You can use runtimes that Lambda provides, or build your own. If you package your code as a .zip file archive, you must configure your function to use a runtime that matches your programming language. For a container image, you include the runtime when you build the image.
Execution Environment
Lambda invokes your function in an execution environment, which provides a secure and isolated runtime environment. The execution environment manages the resources required to run your function like the amount of memory required, the maximum execution time allowed etc. The execution environment also provides lifecycle support for the function's runtime and any external extensions associated with your function.
Trigger
An event source like an AWS service, such as Amazon SNS, a new file added in the S3 bucket, HTTP call, new message in the SQS queue or a custom service to trigger function. It helps you to execute logic.
Event
An event is a JSON-formatted document that contains data for a Lambda function to process. The runtime converts the event to an object and passes it to your function code.
When an AWS service invokes your function, the service itself defines the format of the event.
Deployment Package
Lambda is deployed using a deployment package. Lambda supports two types of deployment packages:
A .zip file archive that contains your function code and its dependencies. Lambda provides the operating system and runtime for your function.
A container image. This image includes function code, dependencies, an operating system and a Lambda runtime.
Configuring a Lambda
Lambda requires certain configuration to be made that gives a developer more granular control over its execution to suit his requirements.
Memory: Lambda allocates CPU power in proportion to the amount of memory configured. Memory is the amount of memory available to your Lambda function at runtime. The memory of 1769 MB is equivalent to a function having one vCPU.
Environment Variables: A set of key-value pairs to give control over Lambda functions. These variables can be configured outside of code and thus provide flexibility.
Tags: Key-value pairs that Lambda attaches to your function resource. Use tags to organize Lambda functions into groups for cost reporting and filtering
Monitoring: This is used to configure monitoring of lambda function using services like Cloudwatch.
Timeout: The lambda function can run for a maximum of predefined time after which it times out. The maximum allowed time is 15 minutes.
Ephemeral Storage: By default, the lambda functions allocate 512MB for a function's /tmp directory as ephemeral storage.
Version: Lambda creates a new version of the function each time that it is published. The new version is a copy of the unpublished version of the function. The unpublished version is named $LATEST.
Alias: A Lambda alias is like a pointer to a specific function version. Users can access the function version using the alias Amazon Resource Name (ARN). If you specify a Lambda function alias in the mapping configuration, you don't need to update the mapping when the function version changes.
Now we will dig into the actual execution of the lambda function.
Lambda Execution Environment Lifecycle
Whenever a function receives a request(triggered by an event), lambda goes through a lifecycle from setting up the execution environment to its shutdown in following phases:
Init phase: In this phase, lambda performs three asks. First, it starts all the extensions. Second, it bootstraps the runtime. Third, it runs the function's static code.Invoke phase: In this phase, lambda sends the invoked event to the runtime and to each extension. The function's timeout setting limits the duration of the entire invoke phase.Shutdown phase:Here, lambda shuts down the runtime and then the extensions
After the function and all extensions have been completed, Lambda maintains the execution environment for some time in anticipation of another function invocation. In effect, Lambda freezes the execution environment. When the function is invoked again, Lambda thaws the environment for reuse. This prevents rerunning of init phase.
An important concept to understand here is Cold Start. Whenever lambda function receives a request, it takes some time before init phase is complete. Actual function execution happens in invoke phase. This adds latency in the lambda function response time. This delayed start is called cold start.
Scaling a Lambda Function
For any modern application to serve its customers, it's important that all its components scale as traffic goes through peaks and troughs. And if the lambda function has to serve as compute solution to applications, it should be no different. Thus, scaling is integrally connected with the number of concurrent requests a lambda function has to serve.
Concurrency is the number of in-flight requests the AWS Lambda function is handling at the same time. For each concurrent request, Lambda provisions a separate instance of your execution environment. As functions receive more requests, Lambda automatically handles scaling the number of execution environments until you reach your account's concurrency limit.
Concurrency = (average requests per sec) * (average request duration in seconds)
By default, your account has a concurrency limit of 1,000 across all functions in a region.
There are two types of concurrency controls available:
Reserved Concurrency: Use this to reserve a portion of your account's concurrency for a function.
Provisioned Concurrency: Use this to pre-initialize a number of environment instances for a function. This is useful for reducing cold start latencies. When using provisioned concurrency, Lambda still recycles execution environments in the background. However, at any given time, Lambda always ensures that the number of pre-initialized environments is equal to the value of your function's provisioned concurrency setting.
Practical applications
Lambda's serverless solution finds practical usage across different requirements
Interactive (synchronous) – web apps, web services. The microservices-based architecture in particular works well with serverless given its event-driven nature.
Background Data Processing (asynchronous) – big data processing, image/video manipulation
Streaming – processing inbound data streams, from apps, IoT devices
Limitations
Lambda provides a good compute solution. However, it has its own limitations. One needs to deploy code in lambda only after weighing all the pros and cons. Here are important Lambda's limitations:
Long-Running Tasks: AWS Lambda functions have a maximum execution time limit (e.g., 15 minutes for AWS Lambda in most regions). If your task requires more time to complete, Lambda might not be suitable. Consider using AWS Fargate, EC2 instances, or other compute options for longer tasks.
High Memory or CPU Requirements: AWS Lambda provides a limited amount of memory and CPU power for each function. If your application requires a substantial amount of memory or CPU, you might hit performance constraints. In such cases, using EC2 instances or other compute options could be more appropriate.
Persistent State: Lambda functions are stateless by design, meaning they don't retain any state between invocations. If your application requires maintaining a persistent state or holding onto data between function executions, a serverless approach might not be the best fit. Consider using databases or other storage solutions for persistent data.
Continuous High Traffic: While AWS Lambda is designed to scale automatically, extremely high and continuous traffic might lead to cold starts, which can impact latency. For consistent high-traffic workloads, you might want to explore other compute options or optimize your Lambda function for better cold start performance.
Large Files or Data Processing: Lambda has limitations on the size of the deployment package and input/output payloads. If your use case involves processing large files or data sets, you might run into these limitations. Look into services like AWS Batch or other data processing services for such scenarios.
Resource-Intensive Workloads: CPU-intensive or resource-intensive workloads might not perform optimally in Lambda due to their limited compute resources. In these cases, using specialized compute resources like EC2 instances or GPU instances could be more appropriate.
Costly when steady traffic: While serverless architectures can offer cost savings if your application has very predictable and steady workloads, the pay-as-you-go model of Lambda might not provide significant cost advantages over reserved or on-demand instances.
Complex Workflows: If your application involves complex workflows with multiple steps or requires orchestration, AWS Step Functions or other workflow orchestration tools might be a better fit than Lambda functions alone.
Conclusion
AWS lambda is a revolutionary concept in application compute solutions. It provides easy, simplified and scalable solution to architects without going into the hassles of infrastructure maintenance. Lambda functions, if deployed for right use cases can accelerate product development lifecycle and thus help businesses grow by leaps and bounds. So next time you are looking for a good compute solution, let the serverless serve you!
If you like this article, give it a like and share it with your peers. Also, let me know what you think in the comments!