A WalkThrough with AWS Lambda

Serverless Architecture

Serverless is an application framework for building a serverless application without having to worry about managing infrastructures. It is based on the principle of third party service (BaaS) and on custom codes which run on a container(FaaS). Serverless architecture doesn’t mean we don’t have a server. With the serverless architecture, we still have a server to run our application, it’s just that we don’t need to manage it on our end. We can just focus on developing our application rest will be handled automatically.

AWS SAM

The AWS Serverless Application Model (AWS SAM) is a model to define serverless applications. AWS SAM is natively supported by AWS CloudFormation and defines a simplified syntax for expressing serverless resources. The specification currently covers APIs, Lambda functions, and Amazon DynamoDB tables. AWS SAM uses Cloudformation template to deploy the lambda in a cloud formation stack. These templates are written in JSON or YAML file which states the step to execute in the cloud stack. So our main motive of this blog is to focus on lambda so the rest of the content will be on lambda functions.

AWS Lambda

AWS Lambda is a serverless framework so we can just create an application, make an artifact out of it and just upload it. AWS Lambda will handle the rest. It runs the application based on the language, scale it whenever required and the best part of it is that we are charged for only when we run a lambda function i.e NO CHARGE for not running it.

Building blocks of AWS lambda-based application:

1. Lambda function: It consists of our application code and related dependencies which we upload as an artifact.
2. Events: An AWS service, such as Amazon SNS, or a custom service, that triggers your function and executes its logic. For more information
3. Downstream resources: Like DynamoDB or S3 which can be used to trigger a lambda function.
4. Log streams: Logs are automatically maintained in cloud watch which we can use to analyze the execution flow and performance of the lambda function.
5. AWS SAM: It defines a serverless model which provide support to AWS cloudformation for creating the deployment cycle for our application.

AWS Lambda supports the following runtime versions:

Let us see a simple lambda function written in Java.

package com.knoldus

import com.amazonaws.services.lambda.runtime.Context;

public class Lambda {
    // Lambda function
    public String requestHandler(String name, Context context) {
       return String.format("Hello %s.", name);
    }
}

In this example, we have a requestHandler function which we have taken as our lambda function. It contains 2 parameters. The first argument is the input parameter to the function and the second is the context object. The context object allows you to access useful information available within the Lambda execution environment like the memory limit, request id etc.

After creating the function we will create an artifact with all the dependencies and upload that to the AWS Lambda console and specify the handler as com.knoldus.Lambda::requestHandler (package.class::method-reference). Then we will specify a trigger for it i.e when this lambda function needs to be triggered like specifying an API gateway or triggering the function when something is pushed to S3 etc.

There may be questions in your mind like,

“Why Lambda? Why not ECS?”

“When to use what?”

“Lambda vs ECS?”

“Which AWS service should I use?”

I have answers for these.

Why Lambda? Why not ECS?

Both AWS Lambda and AWS ECS are similar in some regard as both of them do the same job but there are some differences that we need to keep in mind and use one of them according to our needs.

Lambda vs ECS

AWS Lambda does not provide any visibility into the server infrastructure environment used to run the application code, while Amazon ECS actively exposes the servers used in the cluster as standard Amazon EC2 instances and allows the user to size and scale themselves.

AWS Lambda supports only a few languages but ECS will run any code written in any language.

AWS Lambda is best when we have a small function instead of complex function as it will affect its execution on the other hand AWS ECS can run any type of code.

In Lambda we don’t have to worry about scaling our application as it is automatically handled but on the other hand in ECS either we need to scale up manually or we have to use tools for auto-scaling.

When to use what?

Lambda should be used when we have few functions which don’t have complex dependencies on other functions in the code. It is mainly used when we are handling event-based requests. It has only a few supported languages so we need to have a check on those.

Amazon ECS allows running Docker containers in a standardized, AWS-optimized environment. The containers can contain any code or application module written in any language.

Which AWS service should I use?

Again the answer is simple it is based on the needs i.e it depends on the code written.

In my next blog, I will give a complete step by step procedure for creating a Lambda function and setting up the function in the AWS Lambda console.

Hope this content helps you in some ways. Let’s meet in my next blog. Till then

Happy reading…!!

References:

• AWS Lambda Documentation
• diginomica.com