Oct
13
2017

Serverless Architecture with AWS Lambda

Article by Roshan Fernando

AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you.

“Serverless” architecture is the new trend of designing software and getting more popular nowadays by replacing server-based stacks. Although the term “Serverless” suggests there is no server, what it really means is that there is no need of owning servers or even to manage them.

So, is there a Server?

Yes, there’s a server. Only the server is split into pieces, utilizing an event-driven, serverless computing platform like AWS Lambda or Azure Functions. Each of these functions runs simple logic to handle one specific job.

In a traditional server-based application, the entire logic layer would run in an application in a server stack. All the logic would go through one of the nodes in a cluster of these replicated servers. Contrasting to this with an application built around serverless architecture, application’s compute processing is balanced between the client and various API endpoints that connect to lambda functions.

In the serverless architecture, the application is split into several small functions called micro-services. Depending on the load the application is scaled automatically. The client application consumes different micro-services or functions that are hosted on diverse platforms, languages and locations. The functions are loaded only when they are required or being requested, thus making booting lightweight and quick. Each function is executed by a trigger that can be an event or the culmination of another trigger. These functions can be services hosted in a cloud or functions provided by third-party providers, using the user register process. Serverless architecture, in fact, largely depends on third-party service providers.

Figure1 :

Illustration of the serverless architecture and interaction between different components. (Source: http://thinkpalm.com/wp-content/uploads/2017/01/Serverless-Architecture.jpg)

Serverless architecture depends entirely on third-party services where the code runs in an ephemeral (momentary) containers using function as a service(FaaS) and calling back-end as a service(BaaS) for data storage needs.

Function as a service(FaaS)

FaaS is an innovative product of the public cloud model where the economies of scale makes it feasible for the providers to provide a platform where in simple terms, user’s code is executed in containers (e.g using Docker) and these containers are formed in response to events like an http call to an API gateway or a data packet in a data stream, whatever the cloud provider might support.

FaaS is AWS lambda, although Azure provides Azure Functions while Google has Cloud Functions. All of the latter follow the same principle, which they don’t create or maintain a server.

Back-end as a service(BaaS)

Unlike FaaS, BaaS became popular sometime ago in the app developers circuit as they looked for a back end service over the internet which provides features such as data storage, event driven notifications and something that can horizontally scale as their app grows, as a result, BaaS offerings are currently more mature than FaaS and has more features. AWS has Dynamo DB as its primary offering in this segment, Azure has Cosmos DB, while google has Cloud Datastore.

The advantages are

No need to manage and maintain (virtual) servers.
No need to worry about the health of instances.
No need to worry about the scaling.
Pay only for what you are using.

What is AWS Lambda?

“AWS Lambda is a serverless compute service that runs your code in response to events and automatically manages the underlying compute resources for you. You can use AWS Lambda to extend other AWS services with a custom logic, or to create your own back-end services that operate at AWS scale, performance and security.”

Benefits of AWS Lambda

No infrastructure to manage.
- Since the users do not have to maintain any servers.
Cost-effective and efficient.
- Since users do not have to pay for the idle time, it is very cost-
Bring your own code.
- With AWS lambda, users do not have to learn new programming languages. Currently, it supports Java, C Sharp, NodeJs and Python.

How does a Lambda Function work?

To understand how a lambda function work, we must be familiar with these three key components.

Handler:

The only unique component of the lambda function in comparison to some other traditional service which is running on your server is the handler function. Whenever, a lambda function receives an invoke, its ‘handler’ function acts as the starting point thus it simply defines the entry point for a lambda function.

Event:

The actual request, which comes to the lambda function is passed as the ‘event’ object to the lambda function. There are predefined format for AWS integrations & events. Both java and C sharp supports simple data types, POJOs and POCOs respectively.

Context:

Another important parameter passed to lambda function is context object. This object provides a lot of control over the different properties which you can use to determine the environment of its execution. For instance, you can determine how much time left before the function getting timed out using the getRemainingTimeInMillis method.

Please refer below figure for a basic lambda function.

What are the Function Configuration Metadata?

Further, there are two key configurations for AWS lambda functions in development perspective.

Dead Letter Configuration:

A dead letter queue is a queue that other queues can target for messages that can’t be processed successfully. By default, a failed Lambda function invoked asynchronously is retried twice and then the event is discarded. Using Dead Letter Queues (DLQ), you can configure a target Amazon Resource Name (ARN) on a Lambda function’s DeadLetterConfig parameter of an Amazon SNS topic or an Amazon SQS queue where you want the event payload delivered.

Environment:

Environment variables for Lambda functions, dynamically pass settings to function code and libraries, without making changes to the code. These variables are key-value pairs that can be create and modify as a part of function configurations.

Limitations of the AWS Lambda Functions

The following table describes the limitations of the AWS lambda functions.

Resource Limits	Default Limit
Ephemeral disk capacity (“/tmp” space)	512 MB
Number of file descriptors	1024
Number of processes and threads (combined total)	1024
Maximum execution duration per request	300 seconds
Invoke request body payload size (RequestResponse)	6 MB
Invoke request body payload size (Event)	128 K
Invoke response body payload size (RequestResponse)	6 MB
Dead-letter payload size (Event)	128 K
Deployment Limits	Default Limit
Lambda function deployment package size (.zip/.jar file)	50 MB
Size of code/dependencies that you can zip into a deployment package (uncompressed zip/jar size)	250 MB
Total size of all the deployment packages that can be uploaded per region	75 GB
Total size of environment variables set	4 KB
Throttling Limits (can request service limit increase)	Default Limit
Concurrent executions	1000

Lambda – Performance Issues

One of the main performance issue with the AWS lambda function is called cold start.What cold start means is the time to set up a new container and do necessary bootstrapping when a Lambda function is invoked for the first time or after it has been updated or inactive (cold).

There are several ways to reduce the cold start latency,

More memory = faster performance, lower start up time.
Smaller function ZIP loads faster.
js and Python start execution faster than Java and C#

There is a third party plugin – ( serverless-plugin-warmup) which will solves cold starts by creating one schedule event lambda that invokes all the service lambdas you select in a configured time interval (default: 5 minutes) or a specific time, forcing your containers to stay alive.

Best Practices

Following are list of items you should keep in mind when developing AWS lambda functions.

Use versions and aliases.

- Versioning allows you to better manage your in-production Lambda function code by enabling you to publish one or more versions of your Lambda function. As a result, you can work with different variations of your Lambda function in your development workflow, such as development, beta and production.
- Aliases enable you to abstract the process of promoting new Lambda function versions into production from the mapping of the Lambda function version and its event source.
Externalize authorization to IAM roles whenever possible.
Least privilege and separate IAM roles.
Externalize configuration.
- Developers can use DynamoDB to store the configuration data.
Use Stage variables.
- Stage variables are name-value pairs that you can define as configuration attributes associated with a deployment stage of an API. They act like environment variables and can be used in your API setup and mapping templates.
Take advantage of dead letter queues.
- By default, a failed Lambda function invoked asynchronously is retried twice, and then the event is discarded. Using Dead Letter Queues (DLQ), you can indicate to Lambda that unprocessed events should be sent to an Amazon SQS queue or Amazon SNS topic instead, where you can take further action.
Limit concurrency when talking to relational databases.
Limit your function/code size.
Use for securing credentials and keeping them out of code.

Comparison between Other Platforms

The following table compares the features of the lambda functions with its competitors.

Feature	AWS Lambda	Google Cloud	Azure Functions
Scalability & availability	Automatic scaling (transparently)	Automatic scaling	Manual or metered scaling (App Service Plan), or sub-second automatic scaling (Consumption Plan)
Max # of functions	Unlimited functions	1000 functions per project	Unlimited functions
Concurrent executions	1000 parallel executions per account, per region (soft limit)	No limit	No limit
Max execution	300 sec (5 min)	540 seconds (9 minutes)	300 sec (5 min)
Supported languages	JavaScript, Java, C#, and Python	Only JavaScript	C#, JavaScript, F#, Python, Batch, PHP, PowerShell
Dependencies	Deployment Packages	npm package.json	Npm, NuGet
Deployments	Only ZIP upload (to Lambda or S3)	ZIP upload, Cloud Storage or Cloud Source Repositories	Visual Studio Team Services, OneDrive, Local Git repository, GitHub, Bitbucket, Dropbox, External repository
Environment variables	Yes	Not yet	App Settings and ConnectionStrings from App Services
Versioning	Versions and aliases	Cloud Source branch/tag	Cloud Source branch/tag
Event-driven	S3, SNS, SES, DynamoDB, Kinesis, CloudWatch, Cognito, API Gateway, CodeCommit, etc.	Cloud Pub/Sub or Cloud Storage Object Change Notifications	Blob, EventHub, Generic WebHook, GitHub WebHook, Queue, Http, ServiceBus Queue, Service Bus Topic, Timer triggers
HTTP(S) invocation	API Gateway	HTTP trigger	HTTP trigger