• Version
  • Download 3
  • File Size 1.30 MB
  • File Count 1
  • Create Date October 11, 2020
  • Last Updated October 13, 2020

AWS Lambda, A Guide to Serverless Microservices

From its conception, AWS Lambda was designed with a sort of “run and forget” model in mind. In other words, the developer provides the code and describes when it should be run (whether on-demand or in response to some
event) and AWS takes care of the rest; they provision the compute power, deal with code storage and updates, deploy the code to the required locations, scale up to match the appropriate demand, manage the disk space,
memory, and CPU requirements of the underlying resources, and manage the networking, OS updates, and all the other requirements in between. Compared to “traditional” models, or even workloads running on EC2, this is
a vast amount of work that is being offloaded from developers to AWS. This is not without its downsides, so be sure to continue reading to make sure a Lambda replacement is appropriate for your project.

Software developers, developer operations engineers, systems administrators, and other IT workers are well aware that the process of running software usually requires significant forethought into how and where that software will run. Traditionally, companies required servers; physical boxes lined row upon row of a data centre, each requiring the attention of an administrator or teams of engineers. Larger shops could easily employ a dozen team members to handle the hardware, security, networking, upgrades, and all other aspects of the life of a server.

 

As a reader of this book, you are most likely familiar with where the industry trended next: the cloud. Rather rapidly in the last few years, existing businesses have transferred large swaths of their networks to cloud providers, while new businesses have been built from the ground up solely

relying on cloud-based infrastructure. Cloud providers like Google, DigitalOcean, Rackspace, and Amazon have surged in popularity, each providing a means of offloading the traditional tasks of hardware management. Despite the reluctance of some large companies, most industry experts agree that cloud-based environments (or, at the very least, hybrid environments) are the way of the future.

 

Without getting into the pros and cons of vendor lock-in, each of these cloud hosting providers has worked continuously to provide cloud-based solutions for traditional problems. Storage solutions, networking capabilities, direct data center connections, and computing power have been developed and continually improved to address the needs of thousands of companies that are now relying on these public cloud environments. With each passing year, more and more computing services are being offered by these companies.

 

The single largest entity of these cloud providers is Amazon. Its Amazon Web Services (AWS) business is now larger than all of its competitors combined and is growing at an incredible pace. With over 45 different offerings, AWS provides solutions that span storage, networking, computing, machine learning, and mobile device testing. One of the oldest products in the AWS catalog is Elastic Compute Cloud, or EC2, which allows developers to launch virtual server instances on-demand. After declaring parameters such as the amount of memory, disk space, and CPU size, administrators can provision a single virtual instance or up to thousands of running instances at once. The administrators and developers are then responsible for deploying code, running the applications, and ensuring that the instances remain healthy (are not consuming too much memory, disk space, etc.).

 

EC2 has been and remains one of AWS’s most popular core offerings. With root or administrator access to a base Linux or Windows machine, developers are free to run almost any kind of code imaginable. Millions of applications have been developed on top of EC2, and entire businesses (such as Heroku) use EC2 for their underlying infrastructure. In fact, using nothing but EC2, most organizations could run their entire workloads including storage, database, and routing needs. The availability and performance of EC2 on AWS is unparalleled.

 

Despite these advantages, AWS Lambda is not yet designed for workloads that are not primarily event-driven. For example, AWS Lambda functions cannot respond directly to HTTP requests (unless paired with AWS API Gateway, another recently announced service), or run long-running processes in the background. Given their low timeouts (currently 300 seconds) and moderate memory allowances (up to 1.5 GB at the time of writing this book), AWS Lambda functions are not designed to completely replace EC2; instead, they can replace some of the functionality for specific services and support an entirely new form of computing in the cloud.