1
By the end of this chapter, you will be able to:
This chapter teaches you the basics of serverless architectures, focusing on AWS.
Imagine that a critical application in your company is having performance issues. This application is available to customers 24-7, and during business hours, the CPU and memory utilization reaches 100%. This is resulting in an increased response time for customers.
Around 10 years ago, a good migration plan to solve this issue would involve the procurement and deployment of new hardware resources for both the application and its databases, the installation of all required software and application code, performing all functional and performance quality analysis work, and finally, migrating the application. The cost of this would run into millions. However, nowadays, this issue can be resolved with new technologies that offer different approaches to customers – going Serverless is definitely one of them.
In this chapter, we'll start with an explanation of the serverless model, and get started with AWS and Lambda, the building blocks of a serverless applications on AWS. Finally, you'll learn how to create and run Lambda functions.
To understand the serverless model, let's first understand how we build traditional applications such as mobile applications and web applications. Figure 1.1 shows a traditional on-premises architecture, where you would take care of every layer of application development and the deployment process, starting with setting up hardware, software installation, setting up a database, networking, middleware configuration, and storage setup. Moreover, you would need a staff of engineers to set up and maintain this kind of on-premises setup, making it very time-consuming and costly. Moreover, the life cycle of these servers was no longer than 5-6 years, which meant that you would end up upgrading your infrastructure every few years.
The work wouldn't end there, as you would have to perform regular server maintenance, including setting up server reboot cycles and running regular patch updates. And despite doing all the groundwork and making sure that the system ran fine, the system would actually fail and cause application downtime. The following diagram shows a traditional on-premises architecture:
The serverless model changes this paradigm completely, as it abstracts all the complexity attached with provisioning and managing data centers, servers, and software. Let's understand it in more detail.
The serverless model refers to applications in which server management and operational tasks are completely hidden from end users, such as developers. In the serverless model, developers are dedicated specifically to business code and the application itself, and they do not need to care about the servers where the application will be executed or run from, or about the performance of those servers, or any restrictions on them. The serverless model is scalable and is actually very flexible. With the serverless model, you focus on things that are more important to you, which is most probably solving business problems. The serverless model allows you to focus on your application architecture without you needing to think about servers.
Sometimes, the term "serverless" can be confusing. Serverless does not mean that you don't need any servers at all, but that you are not doing the work of provisioning servers, managing software, and installing patches. The term "the serverless model" just means that it is someone else's servers. Serverless architectures, if implemented properly, can provide great advantages in terms of lowering costs and providing operational excellence, thus improving overall productivity. However, you have to be careful when dealing with the challenges imposed by serverless frameworks. You need to make sure that your application doesn't have issues with performance, resource bottlenecks, or security.
Figure 1.2 shows the different services that are part of the serverless model. Here, we have different services for doing different kinds of work. We have the API Gateway service, a fully managed REST interface, which helps to create, publish, maintain, monitor, and secure APIs. Then, we have the AWS Lambda service that executes the application code and does all the computation work. Once computation is done, data gets stored in the DynamoDB database, which is again a fully managed service that provides a fast and scalable database management system. We also have the S3 storage service, where you can store all your data in raw formats that can be used later for data analytics. The following diagram talks about the serverless model:
Serverless models have become quite popular in recent times, and many big organizations have moved their complete infrastructure to serverless architectures and have been running them successfully, getting better performance a much a lower cost. Many serverless frameworks have been designed, making it easier to build, test, and deploy serverless applications. However, our focus in this book will be on serverless solutions built on Amazon Web Services (AWS). Amazon Web Services is a subsidiary of Amazon.com that provides on-demand cloud service platforms.
There are a number of benefits to using a serverless model:
Moreover, today's serverless models, such as AWS, work on the "pay as you go" model, meaning that you don't pay for any capacity that you don't use. This way, you don't pay anything when your servers are idle, which helps to control costs.
AWS is a highly available, reliable, and scalable cloud service platform offered by Amazon that provides a broad set of infrastructure services. These services are delivered on an "on-demand" basis and are available in seconds. AWS was one of the first platforms to offer the "pay-as-you-go" pricing model, where there is no upfront expense. Rather, payment is made based on the usage of different AWS services. The AWS model provides users with compute, storage, and throughput as needed.
The AWS platform was first conceptualized in 2002 and Simple Queue Service (SQS) was the first AWS service, which was launched in 2004. However, the AWS concept has been reformulated over the years, and the AWS platform was officially relaunched in 2006, combining the three initial service offerings of Amazon S3 (Simple Storage Service): cloud storage, SQS, and EC2 (Elastic Compute Cloud). Over the years, AWS has become a platform for virtually every use case. From databases to deployment tools, from directories to content delivery, from networking to compute services, there are currently more than 100 different services available with AWS. More advanced features, such as machine learning, encryption, and big data are being developed at a rapid pace. Over the years, the AWS platform of products and services has become very popular with top enterprise customers. As per current estimates, over 1 million customers trust AWS for their IT infrastructure needs.
We will take a quick tour of the AWS serverless ecosystem and briefly talk about the different services that are available. These services will be discussed in detail in future chapters.
Figure 1.4 shows the AWS serverless ecosystem, which is comprised of eight different AWS services:
Here's a diagram of the AWS serverless ecosystem:
AWS Lambda is a serverless computing platform that you can use to execute your code to build on-demand, smaller applications. It is a compute service that runs your backend code without you being involved in the provisioning or managing of any servers in the background.
The Lambda service scales automatically based on your usage and it has inbuilt fault-tolerance and high availability, so you don't need to worry about the implementation of HA or DR (disaster recovery) with AWS Lambda. You are only responsible for managing your code, so you can focus on the business logic and get your work done.
Once you upload your code to Lambda, the services handles all the capacity, scaling, patching, and infrastructure to run your code and provides performance visibility by publishing real-time metrics and logs to Amazon CloudWatch. You select the amount of memory allocation for your function (between 128 MB and 3 GB). Based on the amount of memory allocation, CPU and network resources are allocated to your function. You could also say that AWS Lambda is a function in code that allows stateless execution to be triggered by events. This also means that you cannot log in to actual compute instances or customize any underlying hardware.
With Lambda, you only pay for the time that your code is running. Once execution is completed, the Lambda service goes into idle mode and you don't pay for any idle time. AWS Lambda follows a very fine-grained pricing model, where you are charged for compute time in 100 ms increments. It also comes with a Free Tier, with which you can use Lambda for free until you reach a certain cap on the number of requests. We will study AWS Lambda pricing in more detail in a later section.
AWS Lambda is a great tool for triggering code in the cloud that functions based upon events. However, we need to remember that AWS Lambda (in itself) is stateless, meaning that your code should run as you develop it in a stateless manner. However, if required, a database such as DynamoDB can be used. Over the years, AWS Lambda has become very popular for multiple serverless use cases, such as web applications, data processing, IoT devices, voice-based applications, and infrastructure management.
Lambda is stateless and serverless. You should develop your code so that it runs in a stateless manner. If you want to use other third-party services or libraries, AWS allows you to zip up those folders and libraries and give them to Lambda in a ZIP file, which in turn enables other supportive languages that you would like to use.
AWS Lambda supports code written in the following six languages:
AWS Lambda could change the list of supported languages at any time. Check the AWS website for the latest information.
In this exercise, we'll create a Lambda function, specify the memory and timeout settings, and execute the function. We will create a basic Lambda function to generate a random number between 1 and 10.
Here are the steps for completion:
Name: Enter myFirstLambdaFunction.
Runtime: Choose Node.js 6.10. The Runtime window dropdown shows the list of languages that are supported by AWS Lambda, and you can author your Lambda function code in any of the listed options. For this exercise, we will author our code in Node.js.
Role: Choose Create new role from one or more template. In this section, you specify an IAM role.
Role name: Enter lambda_basic_execution.
Policy templates: Select Simple Microservice permissions:
So, you have created your first Lambda function, but we have yet to change its code and configuration based on our requirements. So, let's move on.
//TODO implement
let minnum = 0;
let maxnum = 10;
let generatednumber = Math.floor(Math.random() * maxnum) + minnum
callback(null, generatednumber);
You don't need to manage any underlying infrastructure, such as EC2 instances or Auto Scaling groups. You only have to provide your code and let Lambda do the rest of the magic.
Create a new Lambda function that finds the square root of the average of two input numbers. For example, the two numbers provided are 10 and 40. Their average is 25 and the square root of 25 is 5, so your result should be 5. This is a basic Lambda function that can be written using simple math functions.
Here are the steps for completion:
The solution for this activity can be found on page 152.
AWS Lambda imposes certain limits in terms of resource levels, according to your account level. Some notable limits imposed by AWS Lambda are as follows:
If you want to learn more about other limits of Lambda functions, go to https://docs.aws.amazon.com/lambda/latest/dg/limits.html#limits-list.
AWS Lambda is a serverless compute service and you only pay for what you use, not for any idle time. There is a Free Tier associated with Lambda pricing. We will discuss the Lambda Free Tier in the next section.
To understand the AWS billing model for Lambda, you first need to understand the concept of GB-s.
1 GB-s is 1 Gigabyte of memory used per second. So, if your code uses 5 GB in 2 minutes, and then 3 GB in 3 minutes, the accumulated memory usage would be 5*120 + 3*180 = 1140 GB seconds.
The prices for the AWS services discussed in this section and in this book are current at the time of writing, as AWS prices may change at any time. For the latest prices, please check the AWS website.
Lambda pricing depends on the following two factors:
As part of the Lambda Free Tier, you can make 1 million free requests per month. You can have 400,000 GB-seconds of compute time per month. Since function duration costs vary with the allocated memory size, the memory size you choose for your Lambda functions determines how long they can run in the Free Tier.
The Lambda Free Tier gets adjusted against monthly charges, and the Free Tier does not automatically expire at the end of your 12-month AWS Free Tier term, but is available to both existing and new AWS customers indefinitely.
We have a Lambda function that has 512 MB of memory allocated to it and there were 20 million calls for that function in a month, with each function call lasting 1 second. Calculate the total Lambda cost.
Here's how we calculate the cost:
Monthly billable compute (GB- s) = Total compute – Free Tier compute
Monthly compute charges = Monthly billable compute (GB-s) * Monthly compute price
Monthly billable requests = Total requests – Free Tier requests
Monthly request charges = Monthly billable requests * Monthly request price
Monthly compute charge + Monthly request charges
The solution for this activity can be found on page 153.
While estimating Lambda costs, you must be aware of additional costs. You will incur costs as part of Lambda integration with other AWS services such as DynamoDB or S3. For example, if you are using the Lambda function to read data from an S3 bucket and write output data into DynamoDB tables, you will incur additional charges for read from S3 and writing provisioned throughput to DynamoDB. We will study more about S3 and DynamoDB in Chapter 2, Working with the AWS Serverless Platform.
In summary, it may not seem like running Lambda functions costs a lot of money, but millions of requests and multiple functions per month tend to escalate the overall cost.
In this chapter, we focused on understanding the serverless model and getting started with AWS and Lambda, the first building block of a serverless application on AWS. We looked at the main advantages and disadvantages of the serverless model and its use cases. We explained the serverless model, and worked with AWS serverless services. We also created and executed the AWS Lambda function.
In the next chapter, we'll look at the capabilities of the AWS Serverless Platform and how AWS supports enterprise-grade serverless applications, with and without Lambda. From Compute to API Gateway and from storage to databases, the chapter will cover the fully managed services that can be used to build and run serverless applications on AWS.