1. Getting Started
1.1 What is Lambda
AWS Lambda, at a very high level, is a serverless computing option within AWS, embodying the concept of Function-as-a-Service.
AWS Lambda automatically scales as required, and you pay only for what you use. The approach is event-driven, executing functions in response to specific events, such as updates to DynamoDB tables, data streaming via Kinesis, REST API requests, and object uploads to S3 buckets. These functions are not meant to be long-running processes; in fact, there is a limit to how long a single function can execute.
Cost-wise, Lambda is attractive as there are no upfront or monthly subscription fees for standard functions. Charges are incurred per request and based on the duration of code execution. This model allows for potentially significant cost savings, as you only pay when your code is executed in response to an event. Overall, AWS Lambda provides a convenient, cost-effective solution for running code in response to various events within the AWS ecosystem, embodying the essence of serverless computing and Function-as-a-Service.
2. Lambda Fundamentals
2.1 How lambda works
Lambda Function: The Lambda Function is your code, configured with specific execution parameters like RAM usage and permissions.
Lambda Service: The Lambda Service, on the other hand, is responsible for initializing and calling these functions, handling inputs and outputs, and managing the interface between your code and the external world.
We'll delve into different invocation models of Lambda functions, namely synchronous and asynchronous invocations, and event source mappings.
Synchronous invocation: In a synchronous invocation, the calling application pauses and waits for the Lambda function to return a result. This involves the application making a request to the Lambda service, which then routes this request to an available data center where the function is executed, and the response is sent back to the application.
Asynchronous invocation: In asynchronous invocation, the application makes a request to execute the function, but the Lambda service queues this request and returns an immediate response, allowing the application to continue. The queued executions are run against the function as needed, with responses routed to output services like SNS topics or SQSQ.
Event source mappings: Event source mappings are another critical pattern where Lambda connects to sources like Amazon SQS queues, Kinesis streams, and DynamoDB streams, polling them and executing functions based on the events. This model allows Lambda to read, batch, and filter events from these sources, invoking functions with these events as inputs.
2.2 Lambda Usages
Good Use Cases:
Lambda is highly suitable for tasks like;
- Data transformation,
- File processing,
- Backend logic for websites,
- Report generation from DynamoDB item changes,
- IoT data processing,
- Automated remediation,
- Scheduled tasks and many more.
For example, Lambda can transform data streaming from Kinesis, process files uploaded to an S3 bucket, or handle server-side logic as different microservices for a website.
Bad Use Cases:
However, Lambda is not a good fit for long-running processes due to its maximum execution time limit and constant workloads, as it could become expensive. Also, Lambda is not ideal for large codebases or tasks requiring long-term state, as functions are stateless and need to store state externally.
Common Lambda design patterns
1.Microservices in web applications
2.File Processing
File processing with S3 event notifications.
3.Fan-Out Pattern
Where a single event triggers multiple services.
let's say a man triggers a CCTV camera alert, which publishes this to a simple notification service topic. This is a pub sub-service from AWS. SNS can be subscribed to from multiple services so it could first execute a Lambda function that stores the image into an S3 bucket for archiving but it can also execute a second Lambda function to record the time of the sighting into a database. And finally, it could execute a third Lambda function that utilizes an AI service like recognition to identify the man.
To perform multiple operations in parallel rather than bundling it all into a single Lambda.
Anti Patterns
Conversely, anti-patterns in Lambda usage include
Monolithic functions, which can be hard to manage and test. Recursion, which can cause infinite loops of function invocations.
Orchestration, implement complex lambda functions within a single Lambda function.
Chaining, where functions invoke each other synchronously. Waiting, where functions unnecessarily wait for sequential tasks.
To maximize efficiency and maintainability, it's better to create smaller, focused functions, each responsible for a single task. Asynchronous patterns and parallel processing should be leveraged whenever possible.
2.3 Runtime and Processors
Understanding the various runtime options and processor architectures available is crucial for optimizing your Lambda functions in terms of performance and compatibility with your specific use cases.
What is a Runtime
A runtime in AWS Lambda is the execution environment that provides the necessary resources for your Lambda function to execute successfully. It acts as a bridge between the Lambda Service and your function code, handling the complexities of the execution process, including passing the Event and Context Objects to your function.
Supported Runtimes
Like Node.js, Python, Java, .NET, Go, and Ruby, along with essential software libraries and frameworks. These runtimes run on an underlying operating system managed by AWS.
Processors
Regarding processor options, AWS Lambda supports two types of processors based on different Instruction Set Architectures - the 64-bit x86 architecture and the 64-bit ARM architecture. The 64-bit x86 architecture is well-established and offers great compatibility and performance, whereas the 64-bit ARM architecture, used in devices like phones, tablets, and newer MacBooks, is more power-efficient and can offer better performance for certain workloads.
Top comments (0)