What does a typical 3-tier architecture look like? In a very generic deployment, there are three building blocks for a 3-tier architecture: a presentation layer, business logic layer, and database layer.
An amazing array of applications and frameworks have been designed, developed, and sometimes thrust upon us to adhere to this basic principle of web-application design. To make things more complicated, we have to take care of auto-scaling, caching, routing and many other tasks that add up to an organizations’ responsibilities. Recently, a new way of using serverless architecture has emerged, and Amazon Web Services (AWS) is taking all right steps to make serverless architecture friendlier and more powerful.
Servers or, EC2 instances, are powering thousands of popular sites and application. But to do that, servers cost money and a minimum number of servers are required to run the websites. Those servers need permanent disks, caching layers, and more scaffolding services to serve user requests. Servers require frequent refreshing with hardware and software to keep them up-to-date and bug-free. Serverless architecture, or services, play a significant role to address these issues, including managing costs, and performance. This is not to say that there will be no servers involved. Users, developers, and organizations building their applications with popular frameworks can now focus on their applications, not their backend.
Advantages serverless architecture offers:
How will we achieve these goals? Well, in this series of posts, we are going to discuss some of the Amazon’s game-changing technologies that are making serverless architecture a reality.
We are going to discuss following AWS services in a general way, offering an overview of the technologies. We will discuss sample applications developed by these technologies and the use-cases for these implementations. I think it is worthwhile reviewing the AWS documentation and blog posts, then do some hands-on exercises. The services that are considered for serverless architectures are:
Services for serverless architectures are:
The last two services are well known. They don’t make a great platform for production grade infrastructure entirely, but I have implemented S3 static website hosting for a number of very large organizations, and they are static running at their best, even after a couple of years.
Let’s discuss the Amazon API Gateway. We will cover a few basic building blocks and the AmazonAPI Gateway’s space and capability for a serverless architecture.
The Amazon API Gateway is part of Amazon’s serverless-architecture logic tier. According to Amazon’s documentation:
“Amazon API Gateway is a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale. With a few clicks in the AWS Management Console, you can create an API that acts as a “front door” for applications to access data, business logic, or functionality from your back-end services, such as workloads running on Amazon Elastic Compute Cloud (Amazon EC2), code running on AWS Lambda, or any Web application. Amazon API Gateway handles all the tasks involved in accepting and processing up to hundreds of thousands of concurrent API calls, including traffic management, authorization and access control, monitoring, and API version management.”
This means that the Amazon API Gateway provides users a means to use HTTP(S) requests for other Amazon serverless infrastructures, such as Lambda functions, or a data tier from the presentation layer, such as websites or mobile applications. This is the entry point for users to the Amazon serverless logic tier. Behind the scenes, the API Gateway uses Amazon CloudFront to distribute the load globally.
Amazon API Gateway is based on two services:
There are 3 different roles for API Gateway users:
We just finished our first Amazon API Gateway hands-on project. This is only a mock execution, but it opens the possibilities for building a real, scalable backend service, and fronting it with both mobile clients and websites.
All of this may be accomplished without servers or other infrastructure in any part of the system: front-end, back-end, API, deployment, or testing. As I said in the introduction, we are only scratching the surface here and the best is yet to come. Cloud Academy offers a free 7-day trial that allows users access to development environments through hands-on labs, quizzes, courses, and curated learning paths. For additional reading, I suggest a post from October by Alex Casalboni, AWS Lambda and the Serverless Cloud.
In a typical 3-tier application you need numerous code modules to perform tasks that are application critical and enhance the application’s feature. To put the code into work, you need the infrastructure to run. For example: To transcode an image that you put in your AWS S3 bucket you need some coding, an infrastructure to run the code, and the skill to install & run the infrastructure.
Quite a task. As a programmer, you are not expected to think about the other two skills — installing and managing infrastructure. If you are using AWS cloud, you set must set up an EC2 server, apply a run-time environment, like Java SDK, app server etc. These are the bare minimum requirements and they are complicated. Is there a better way?
AWS believes there should be and introduced a service called AWS Lambda as part of their serverless architecture. Lambda, in simple terms, is a service that reduces the effort of running application code in response to some events, and automatically provisions resource for you.
Consider our problem of transcoding the image that we need to put in our S3 bucket. We have a sample app that only allows the image to be .jpeg format and must be less than 200 KB. To run this code, we need an EC2 server and a Tomcat web server to run the java code for the task.
Thankfully, we can now do the same thing with Lambda, and with much less effort. With lambda, you upload your application code zip file — or even write your code in the inline editor provided by AWS Lambda console, and get going.
According to AWS Lambda documentation: “AWS Lambda runs your code on high-availability compute infrastructure and performs all the administration of the compute resources, including server and operating system maintenance, capacity provisioning and automatic scaling, code and security patch deployment, and code monitoring and logging. All you need to do is supply your code in one of the languages that AWS Lambda supports (currently Python 2.7, Node.js (0.10 or 4.3) Java 8 or higher).”
That’s a lot of behind the scenes work, and that’s the beauty of working with Lambda, automation.
AWS Lambda is a serverless compute platform for executing Stateless and event-driven code execution. What does this mean for a user, programmer, or AWS administrator. It means that AWS runs a chunk of optimized java script functions, or Lambda functions that carry out an event driven task. An event-driven task can be an object added/deleted in S3 bucket, a table updated in DynamoDB, a message arriving to an AWS Kinesis stream or SQS, when a lifecycle event occurs in AWS EC2, or any custom event in AWS.
AWS Lambda use-cases can be categorized into four broad sections:
Pre-requisites:
Following pre-requisites are required for Amazon Lambda execution:
Currently, Lambda is supported in the US-east (N. Virginia), US-west (Oregon), EU (Ireland), EU (Frankfurt) & Asia-pacific (Tokyo) regions.
When you start using Lambda, you already have some sample functions ready for use. Take a look:
I have chosen the “hello-world” application. In future, we are going to execute more complex, real-world examples. Keeping things simple at the start is often the best way of building skills and confidence. I suggest we use this example for familiarization with Lambda.
Take a look at the next screen:
Name: Name of your Lambda function. E.e. HW_lambda
Description: A short description of what the function does for reference
Runtime: You can choose Python 2.7, Node.js 0.10 or 4.3 or Java 8.
Lambda function code:
The next section is code-entry type. You can upload your .zip file or even write the code in-line. Let choose in-line for this example. In the in-line code snippet, we have added a console.log that says, “Hello world Lambda.” Notice the syntax check against our code. It suggests we missed a semicolon (;). Fantastic, isn’t it?
Lambda function handler and role:
Handler: When you create a Lambda function you must specify the handler in your code that will receive the events and process them. In the console, you specify the handler in the Handler box. A handler function has the following signature:
outputType handler_name(inputType input, Context context) { ….. }
In order for a Lambda function to successfully invoke a handler, it must be invoked with input data that can be serialized into the data type of the input parameter.
If you plan to invoke the Lambda function synchronously, you can mention output_type. For an asynchronous Lambda function invocation (using Event invocation type), the output type should be void.
Role: This role is mapped to AWS IAM role. This role should have sufficient permission to perform AWS actions that the lambda function needs. Let’s choose Basic Execution Role from “create role.”
We kept the default values, and “Allow.” You then set Memory and Timeout values. Click “Next” and “Create function.” After the function is created, execute it with the “Test” button.
Now, I offer a more practical example.
We want to send welcome emails to users who have registered with our portal. I have a runnable jar file which is 29MB with all dependent jar files from aws-sdk and java.mail.
This ends our hands-on example of sending welcome emails when a file is uploaded in an S3 bucket.
Lambda is a really cool offering from Amazon Web Service. It is actually a microservice from AWS to run the application code from different sources. It is iterating, maturing, and evolving all the time. Try out lambda and see what you can do with it. Maybe share your results with us here or on other public platforms.
Amazon API Gateway and AWS Lambda are my pics for foundation architecture for Amazon serverless architecture. Cloud Academy offers a free 7-day trial subscription where you may work in a real AWS environment without signing up for one. They provide hands-on labs, learning paths, and quizzes that support the video learning courses.
I have written widely about Amazon Kinesis because it offers managed real-time event processing, and I love it. This is an exceptionally useful and intuitive service. I’ve described Amazon Kinesis in-depth in a previous post from 2015 so if you have questions about that service check the link above,
Below, I’ll show you how AWS Lambda and Amazon Kinesis integration works.
To learn about this integration, we are going to discuss two very important event models of the AWS Lambda functionality concept: Push Event Model vs Pull Event Model.
Understanding of the nitty-gritty of AWS services will take you to a long way designing applications using Lambda.
Some event sources publish events, but AWS Lambda must poll the event source and invoke your Lambda function when events occur. This is called the pull model. With appropriate permissions, AWS Lambda maintains an event source mapping from where it will pull the events. AWS Lambda provides APIs for users to write the code for source mapping. When an event occurs at the designated source a record is added to the Kinesis stream. This is treated as an event and the Lambda function is invoked. This is an example of AWS Lambda function Pull Event Model, where AWS Lambda polls the event to invoke your Lambda function.
Some of the event sources can publish events to AWS Lambda and directly invoke your Lambda function. This is called the push model where the event sources invoke your Lambda function. In this model, you maintain association of a Lambda function with its event source, and not in AWS Lambda. For an example, when you add an object to an S3 bucket, S3 detects it as an event and calls a Lambda function to execute for some action, say, to compress it. In this case, AWS Lambda does not maintain the event source mapping, but the service or application calls the Lambda service to take some action.
Coming back to our example of AWS Lambda and Kinesis integration, we found that it will be a pull model. When a record is added to the Kinesis stream whose event source mapping will be created and maintained by the developer using APIs, AWS Lambda will invoke the associated Lambda function to execute the designated action. There are two ways you can create event source mapping, either by using
There are multiple ways of creating event source mapping. You can use the CreateEventSourceMapping API, or the Lambda console. But the pulling model is not the only option for AWS Lambda and Kinesis integration. There is a synchronous invocation using RequestResponse invocation type. The third option is to configure event source mapping by creating a batch of records per invocation of the Lambda function. Users must note that, for the integration of AWS Lambda and Amazon Kinesis, both the services should reside in the same region.
To execute the example, we assume that you have an AWS account with administrator permission and you have AWS CLI installed on your workstation. Also get the following jars through maven or download them from github/maven repo.
Add these libs to your build path and start a new eclipse project. In this example, we have created a Java class “ProcessKinesisEvents” and the handler method is “recordProcessor()”. We are trying to read a batch of records and process them. If the handler processes them successfully, then the next batch will be read and processed, otherwise, Lambda will retry the batch.
The code snippet is as follows:
package example; import java.io.IOException; import com.amazonaws.services.lambda.runtime.events.KinesisEvent; import com.amazonaws.services.lambda.runtime.events.KinesisEvent.KinesisEventRecord; public class ProcessKinesisEvents { public void recordProcessor(KinesisEvent event) throws IOException { for(KinesisEventRecord rec : event.getRecords()) { System.out.println(new String(rec.getKinesis().getData().array())); } } }
The following artifacts have been created to execute this example.
The above example is one of the simplest I could find and is intended for illustrating manually handling streaming data from a Kinesis stream. For a full-fledged Kinesis stream application, you should have strong, working understanding of Amazon Kinesis — which I highly recommended if you have the time.
AWS Lambda monitors Lambda functions automatically in CloudWatch. If you have navigated to the Logs link above, you should notice the Metrics, Lambda, and Logs options with which to monitor the Lambda function life cycle.
Lambda automatically tracks the number of requests, the latency per request, and the number of requests resulting in an error. It then publishes the associated CloudWatch metrics and generates customized alarms. Users can create dashboards of executed Lambda functions with ease.
Before moving ahead with real-world Lambda or other services that facilitate Amazon’s server-less architecture, it is a good idea to review the best practices and limitations of the AWS Lambda.
I have done my best in listing them carefully below.
If you are familiar with 12-factor apps, then following the recommended best practices for using AWS Lambda will fall in the same category.
Some of the best practices from AWS Lambda developer guides are:
AWS Lambda has the following limitations:
Our journey to achieve Amazon server-less architecture is taking shape but is in the early stages yet. We are constantly adding posts to make the readers comfortable with the pace. However, adoptions of Amazon server-less services are blazing fast, and everybody who loves AWS services is trying their hand with them. Cloud Academy offers a free 7-day trial subscription that allows you access to their many learning resources. I suggest you check out a video course Understanding AWS Lambda and a hands-on lab Introduction to AWS Lambda.
It's Flash Sale time! Get 50% off your first year with Cloud Academy: all access to AWS, Azure, and Cloud…
In this blog post, we're going to answer some questions you might have about the new AWS Certified Data Engineer…
This is my 3rd and final post of this series ‘Navigating the Vocabulary of Gen AI’. If you would like…