Get more updates and further details about your project right in your mailbox.
The best time to establish protocols with your clients is when you onboard them.
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Suspendisse varius enim in eros elementum tristique. Duis cursus, mi quis viverra ornare, eros dolor interdum nulla, ut commodo diam libero vitae erat. Aenean faucibus nibh et justo cursus id rutrum lorem imperdiet. Nunc ut sem vitae risus tristique posuere.
Simple question right? Sure it is! It is a serverless compute service. And? You don’t have to provision or manage servers. And? It scales automatically. It helps you abstract the infrastructure completely. Now, If I have to go a little in-depth but not too deep, I would quote that AWS Lambda is a service based on an event-driven architecture and it runs code in a highly-available environment.
Now how does this Lambda work? What does the event-driven architecture mean? What is the environment that is highly-available? Let’s focus on these features of AWS Lambda.
An event-driven architecture uses events to trigger a function or a service, like our AWS Lambda. Here, an event is an object, that represents a state change and contains data for the Lambda to process. The services that trigger/invoke the Lambda function are called event sources.
Now, Let us learn how an event source invokes the Lambda with an event.
There are three patterns to invoke a Lambda function, called Invocation models. The invocation model to be used depends on the event source that invokes the Lambda.
Synchronous Invocation Model:
In this kind of invocation model, the event source invokes the Lambda and waits for the function to execute and return a response.
Lambda function must be written in such a way that it handles the errors efficiently. There are no built-in retries in this kind of invocation, in case of failure, which is why the function must manage the retry strategy in the code itself.
Amazon API Gateway, AWS CloudFormation, and Amazon CloudFront are some AWS Services that use the Synchronous Invocation Model to invoke a Lambda function.
Asynchronous Invocation Model:
In this kind of invocation model, the event sources invoke the Lambda and do not wait for the function to complete execution. These events are put in a queue instead.
Once the Lambda function finishes execution, one can use Destinations to send the results to other services based on the success or failure of the response. This way, one can configure destinations to address errors without writing more code.
Amazon S3, Amazon Simple Notification Service(SNS), and Amazon EventBridge are some AWS services that use the Asynchronous Invocation Model to invoke a Lambda function.
Polling Invocation Model:
In this kind of invocation model, Lambda will poll AWS streaming and queuing-based services, retrieve any matching events and invoke the functions accordingly.
The configuration of services as event triggers is called Event Source Mapping.
Amazon DynamoDB, Amazon Kinesis, and Amazon Simple Queue Service(SQS) are some AWS Services that support Polling Invocation Model.
Now that we have some idea about why AWS Lambda is said to have event-driven architecture, let’s learn about Lambda’s execution environment.
Lambda invokes the function in a secure, isolated environment that manages the resources and extensions required and provides lifecycle support for the function’s runtime.
The configurations like the amount of available memory and maximum invocation time that is specified at the time of Lambda creation are used during environment setup. The environment lifecycle is divided into three.
A cold start occurs when a new environment is required to run a Lambda function and handle an event.
On the other hand, a warm start is when Lambda retains the environment instead of destroying it right after an event is handled. A new event can be handled using the same environment without recreating a new environment with the same configurations.
Two types of permissions are provided to Lambda that control who can invoke it and what actions it can perform when it is invoked.
A resource policy or function policy defines who can invoke the Lambda function. An AWS Principal may be a user, role, AWS Service, or another AWS Account.
The policy is created a trigger is added to the Lambda function. This allows the event source(that invokes the Lambda) to take the ‘lambda:InvokeFunction’ action.
An execution role gives Lambda function permissions to perform actions of other AWS Services. This role is provided when a Lambda function is created.
IAM Policy: It allows the Lambda function to perform an action on an AWS Resource.
Trust Policy: It allows the Lambda function to “AssumeRole”. This is to specify that the Lambda service Principal as a trusted service.
In conclusion, understanding the foundations of AWS Lambda is crucial for building serverless applications based on your business needs. Lambda offers a cost-effective solution for handling various kinds of events, ensures security with an isolated execution environment, and fine-tunes access control, allowing you to focus on writing business logic.