Going Serverless with AWS

Source:-mediatemple.net

Despite its name, serverless doesn’t mean servers are absent—that is impossible because code still needs to run somewhere. Rather, the trick is that serverless allows you to stop worrying about where and how exactly the code will be run. 

In this two-part series, we’ll dive into the history of serverless in order to understand this difference correctly. We’ll then explore the benefits and limitations of Amazon Web Services (AWS) Lambda, as well as general approaches to building serverless applications. 

The History of Serverless

In the past, developing and publishing applications was very closely related to manually configuring, managing, and further supporting physical devices (servers) where applications were deployed. Such an approach required many resources, both human and hardware. 

Paid virtual machines definitely made engineers’ lives easier. The possibility to rent remote machines that are secured and supported by third-party providers led to a significant improvement in delivery speed and cost. This model is called Infrastructure as a Service (IaaS). Moreover, risks of failure and potential downtime decreased dramatically, as engineers no longer needed to manage hardware themselves or think about reservation. 

The IaaS model is popular even now, and is usually used for complex applications, especially if they are built on top of specific technologies, need special configuration, or are legacy applications. Nowadays, most web applications are built using one of a few common technology stacks, which implement the same principles and solve similar tasks. 

In the late 2000s, however, a concept called Platform as a Service (PaaS) appeared, bringing with it new opportunities for developers, and for the industry in general. Google App Engine (launched in 2008), AWS Elastic Beanstalk (launched in 2011), and other similar services provided developers with ready, easy-to-scale, pre-configured environments for hosting web applications written in Java, PHP, Python, or other popular languages. Engineers started to focus more on the application’s business logic and code, instead of infrastructure and environment. 

Serverless is the last link in this story. It inherits, and even adds to, the advantages of PaaS, but also creates additional rules and limitations (more on this later). According to Martin Fowler, “Serverless architectures are application designs that incorporate third-party “Backend as a Service” (BaaS) services, and/or that include custom code run in managed, ephemeral containers on a “Functions as a Service” (FaaS) platform.”

Essentially, if your application utilizes different third-party services to implement a significant part of your business logic, you can probably consider it a serverless application. But the second part of Fowler’s definition, the mention of FaaS, is much more interesting. And the launch of AWS Lambda in 2015 was a real breakthrough in application development.

AWS Lambda

AWS Lambda is a service that runs code in response to different events happening across the whole application. Everything except the code itself is managed and provided by AWS: availability, auto-scaling, and software and hardware maintenance. Cost is also an advantage because you’re billed in accordance with the “pay-as-you-go” model. This means that you never pay for idle time, but rather, for the amount of invocations and the execution time of your function (rounded to 100ms). No activity means no bill.

In this context, “function” means a piece of code responsible for a particular functionality of an application, packaged together with all its necessary dependencies and uploaded to AWS. The main purpose of this code is to handle a particular type of incoming event with an action (e.g., save or retrieve data from the database), and then exit properly, with or without response.

The variety of events that can trigger the functions is really impressive: HTTP requests via API Gateway, changes to the files in Amazon S3, Amazon SNS messages, or even updates in Amazon DynamoDB tables. There are many more examples in the official documentation.

Limitations of AWS Lambda

AWS has a few limitations, but all of them are fundamental. The first is execution environment and supported languages. Lambda natively supports Java, Go, PowerShell, Node.js, C#, Python, and Ruby. Honestly, you can run almost everything on Lambda, as underneath it is just a Linux Container. However, be ready for some tricky situations. For example, any binaries that will be used inside a Lambda function must first be compiled in the same environment. 

Also, the current maximum execution time of one function is 900 seconds (15 minutes). That means that long computing processes need some special approaches, such as splitting a job into multiple smaller pieces, invocating the function again with the same job and information about the previous invocation progress, or just using separate tools and services.

Next, remember that functions are invoked in ephemeral stateless containers, so developers should never rely on data from a previous invocation. Each container has a 512MB memory in the /tmp folder, but it should only be used for processing files related to that particular invocation. AWS is fully responsible for scaling resources, which means that those “containers” can disappear with all the data inside.