Serverless Architectures & AWS Lambda Introduction

Introduction to AWS Lambda and Serverless Architectures

Before we talk about AWS Lambda, it’s essential to understand the general principles of server-based and serverless architectures. In short, a serverless architecture will leverage short bursts of processing power as required by the load. In other words, the foundational difference between the two is that a server-based architecture will have a “permanent” infrastructure in place that will wait for requests to come in. In contrast, a serverless architecture will only spin up a “server” when it has to process a request.

Figure 1 — Serverless Architectures & AWS Lambda Introduction | Fundamental Diagram of Lambda Functions in AWS

As shown above, AWS services integrate well with what we’ll be covering in this tutorial — Lambda Functions. Lambda Functions run on a server, but they don’t require developers and software engineers to maintain infrastructure. In other words, they can focus on building applications without the hassle of maintaining what their code runs on.

AWS started off as a service for engineers to easily deploy applications via various services that created obstruction from hardware. Engineers could allocate hardware resources as needed. The serverless movement was pioneered by AWS as an effort to keep making it easier to deploy code.

Serverless Services on AWS

Here’s what’s available on “serverless” deployments on AWS:

• AWS Lambda
• DynamoDB
• AWS Cognito
• Amazon S3
• AWS API Gateway
• Fargate
• Step Functions
• AWS Kinesis Data Firehose
• AWS SNS
• AWS SQS
• Aurora Serverless

Understanding AWS Lambda

In traditional server architectures, including AWS, you’re almost always paying for hardware upkeep. You’re either continuously running on-prem servers that consume power and appreciate over time, or you’re paying a fee to have EC2 instances running in the cloud. AWS Lambda offers a way to run functions on demand. In other words, you’re saving yourself the cost of continuously running a server and are relying on sending out a request when it is issued within your system.

Although you may assume that the choice between using servers or serverless architectures is black or white, it’s a bit more nuanced than that. As an AWS or any cloud provider user, you’re paying a fee to run your queries at a moment’s notice. In other words, serverless architectures do have some drawbacks. We’ll examine some advantages and disadvantages in the sections below.

Benefits of AWS Lambda

Straightforward pricing — Lambda functions are priced per request and compute time. Simpler queries will result in lower pricing than complex computations. The free tier plan, for learning purposes, includes 1,000,000 Lambda requests and 400,000 GBs of compute time.

Lambda functions are compatible and integrate with most AWS services. They’re also compatible with most modern programming languages.

Lambda functions can be easily monitored and fine-tuned via various external and AWS-provided services, such as AWS CloudWatch.

Lambda functions scale easily — As mentioned above, the goal is to have an API that will compute anything thrown at it — higher amounts and higher complexity. Keep in mind that pricing will scale accordingly.

AWS Lambda Supported Languages

Lambda supports various languages and platforms; here’s the list:

• Python
• Golang
• Java
• C#
• Ruby
• Rust
• Node.js (JavaScript)
• Lambda Container Image | ECS / Fargate

AWS Lambda Hands-On Creation Walkthrough

It’s time for us to get practical when it comes to AWS Lambda. In this section, you’ll find a walkthrough of getting started with AWS Lambda on an actual AWS account.

Step 1 — Navigate to the Lambda Console and Create a New Function

1.1 — From the AWS Console, search for “lambda.”
1.2 — From the drop-down menu, click on “Lambda.”

Figure 2 — Serverless Architectures & AWS Lambda Introduction | Navigate to the Lambda Console and Create a New Function

1.3 — From the main page, click on “Create a function.”

Figure 3 — Serverless Architectures & AWS Lambda Introduction | Creating a New Lambda Function on AWS

Step 2 — Specify the Parameters of the Lambda Function

2.1 — We will be creating a “Hello World” function. For that purpose, we can select from a list of blueprints pre-created in AWS. Click on “Use a blueprint.”

2.2 — You can choose from a variety of blueprints available; in this demo, we’re going to use the python v3.10 blueprint called “Hello world function.”

2.3 — Give your function a unique name; we’ve called ours “kerno-lambda-ex1.”

Figure 4 — Serverless Architectures & AWS Lambda Introduction | Specifying the Parameters of the Lambda Function

2.4 — At the bottom of the specifications page, you’ll be presented with the function you’re going to be running in AWS Lambda. You’ll notice that predefined functions can’t be changed in this section. However, if you do specify your own lambda function, you’ll be able to preview and change the code here.

2.5 — Click on “Create function.”

Figure 5 — Serverless Architectures & AWS Lambda Introduction | Viewing the Function Implementation

AWS Lambda Hands-On Testing Walkthrough

At this point, we have the demo function deployed in our AWS environment. However, a Lambda function will only execute based on a trigger. We can simulate a trigger via the “Test” function to see what the response of our function is going to be based on the inputs provided. In this section, we’re going to run a test to see what happens.

Step 1 — Locate the Code Source and Start Testing

1.1 — From the AWS Lambda Dashboard, go to “Functions.”

Figure 6 — Serverless Architectures & AWS Lambda Introduction | Locate the Code Source and Start Testing

1.2 — From the list of functions, select the one you’d like to work with. In this case, we’re selecting the function we created in the previous section.

Figure 7 — Serverless Architectures & AWS Lambda Introduction | Locate the Code Source and Start Testing

1.3 — Scroll down until you see the “Code” section, which displays the entire Lambda function.

1.4 — Click on the “Test” button.

Figure 8 — Serverless Architectures & AWS Lambda Introduction | Locate the Code Source and Start Testing

At this point, we need to specify the parameters of the test event.

1.5 — We don’t have any events in the current environment, so the only option is to select “Create new event.”

1.6 — Give your event a unique name; we’re using “Kerno-test-ev1.”

1.7 — Notice that the event will specify JSON that will be used as input into the Lambda function. In our specific case, we’re feeding three key-value pairs into the hello function executable; you don’t need to change the default values, but it’s something you need to pay attention to for custom functions.

1.8 — Press on “Save.”

Figure 9 — Serverless Architectures & AWS Lambda Introduction | Configuring the Parameters of the Lambda Function

Now that we have a trigger, all we have to do is click on “Test” to see the results.

Figure 10 — Serverless Architectures & AWS Lambda Introduction | Execution Results for the Test Function

You’ll notice that under the “Execution results” tab, you’ll be presented with a variety of indicators of how the function was performed. In addition to technical details needed to run your code in a production environment, you’ll be presented with details around billing. In other words, you can review what it will cost you to run this function in your environment.

Configuring AWS Lambda Parameters Walkthrough

Although our test Lambda function ran without any issues, it’s good practice to create guardrails that would prevent the function from taking up more resources than anticipated and costing the business more than it should. In this section, we’ll take a look at a few options that will help you limit the potential usage of your Lambda functions.

Step 1 — Access AWS Lambda Function Settings

1.1 — Open the “Configuration” tab under a specific function.

1.2 — Press on the “Edit” button.

Figure 11 — Serverless Architectures & AWS Lambda Introduction | Configuration of Guardrail Parameters for a Lambda Function

Figure 12 — Serverless Architectures & AWS Lambda Introduction | Configuration of Memory, Ephemeral Storage, and Timeout Parameters

You’ll find three key parameters you should be familiar with and configure for every function:

Memory

The key factor influencing the performance of Lambda functions lies in memory allocation, ranging from 128 MB to 10,240 MB, with the default often set to the smallest capacity. While 128 MB is suitable for basic functions like event transformation and routing, more complex tasks involving libraries, Lambda layers, or data from S3 or EFS benefit from higher memory settings. Notably, memory allocation also dictates the virtual CPU available to a function, offering increased computational power as memory is augmented. Adjusting memory becomes particularly impactful when a function faces constraints in CPU, network, or memory. Despite the Lambda service charging based on gigabyte-seconds, where cost equals memory (in gigabytes) multiplied by duration (in seconds), the overall expense can be influenced by the interplay of these factors. Increasing memory may lead to decreased duration, potentially offsetting or even reducing the overall cost, making it a strategic consideration in optimizing Lambda function performance and cost efficiency.

Here’s a pricing sample for 1000 invocations of a function that computes prime numbers from the AWS documentation along with the cost:

• Memory 128MB | Duration 11.722 sec | Cost $0.024628
• Memory 512MB | Duration 6.678 sec | Cost $0.028035
• Memory 1024MB | Duration 3.194 sec | Cost $0.026830
• Memory 1536MB | Duration 1.465 sec | Cost $0.024638

Ephemeral Storage

Ephemeral storage in Lambda functions provides a temporary, local storage solution that is available only during the execution of a function, with no persistence between invocations. Lambda functions are designed to be stateless, relying on external services for data storage. The ephemeral storage proves beneficial for scenarios requiring temporary file storage, caching of intermediate results, or as a scratch space for complex computations within a function. For instance, it allows Lambda functions to efficiently process and manipulate files or store frequently accessed data during their execution. However, it’s crucial to recognize that data stored in ephemeral storage is specific to the current invocation and does not endure across different function runs. For persistent data storage, external services like databases or cloud storage are more appropriate in the serverless paradigm.

Timeout

As we’ve mentioned multiple times, you’ll be charged based on the execution time of your function. It’s not uncommon that coders deploy functions that run into problems, fail to recover and hang the underlying service. Therefore, it’s important to create reasonable timeouts for your functions with 15 minutes being the maximum. Keep in mind that you can monitor what’s going on with your Lambda functions using a variety of tools; you can always increase the Timeout limit if you see execution of functions fail for this reason.

Monitoring AWS Lambda Functions

AWS Provides a convenient way to see what is happening with a specific Lambda function. After deploying a specific function, you can navigate into the “Monitor” tab and see the number of times the function has been ran, how long it took, what were some of the exceptions (if any), etc.

Note that you can choose to view this information in CloudWatch, including logs.

Figure 13 — Serverless Architectures & AWS Lambda Introduction | Monitoring Lambda Function Execution via Dashboard

Conclusion on AWS Lambda Functions

In this tutorial, we’ve covered various topics, from serverless architectures to deploying, monitoring, and configuring AWS Lambda functions. In conclusion, this comprehensive exploration of AWS Lambda and serverless architectures has provided a valuable roadmap for both beginners and experienced developers. Starting with an insightful introduction to AWS Lambda and the fundamental concepts of serverless architectures, we delved into the underlying principles and mechanisms. The hands-on creation walkthrough offered a step-by-step guide, empowering users to set up their Lambda functions with confidence. Subsequently, the article shifted focus to the critical aspect of understanding AWS Lambda, shedding light on its configuration parameters. The hands-on testing walkthrough then exemplified the practical application of these configurations, ensuring robust and efficient Lambda functions. Together, these sections form a cohesive journey, demystifying AWS Lambda and equipping readers with the knowledge and skills needed to navigate the dynamic landscape of serverless computing. Whether embarking on the initial stages of serverless exploration or refining existing expertise, this article serves as a valuable resource for harnessing the full potential of AWS Lambda in modern application development.