Serverless with AWS Lambda
Serverless offers a new and exciting approach to developing web applications and APIs, with huge cost saving potential.
When we decided to move our hosting infrastructure to Amazon Web Services (AWS) at the start of 2014 one of the main factors that attracted us was the ability to no longer have to manage actual server hardware. To no longer be the team that had to handle the consequences of a server or disk failure that would inevitably happen at the most unsociable of hours. With AWS we could sleep easy in the knowledge that a hardware failure was no longer an issue we had to deal with and most importantly it wouldn’t impact upon the uptime of our websites and web applications.
AWS gave us the capability to design a web hosting infrastructure to be tolerant of failures, in fact to expect them. This has given us a much more resilient hosting infrastructure and vastly reduced the potential for sleep interruptions! It also affords us the ability to be incredibly nimble, scaling up and down server resources on-demand to almost limitless scale. But, we’re still managing servers, albeit now virtual servers.
Serverless is a new approach, one born out of new services like AWS Lambda, Azure Functions, Google CloudFunctions. A serverless approach allows developers to create a function and run it on-demand within it’s own container. I suppose this is almost another layer of abstraction, our first was moving from physical servers to virtual servers, now we could move from virtual servers to on-demand functions running in AWS managed containers.
Taking AWS Lambda as an example this is a service that allows us to run a piece of code (currently Node.js, Java or Python) on-demand so an API request comes in or an event elsewhere in the AWS ecosystem occurs and our function runs and performs a task. The beauty of this is the on-demand part, AWS Lambda is billed only for the time the function is actually running. Compare this to the traditional virtual server model, where we could have a server sitting idle 75% of the time. Virtual servers, being billed hourly means that we’re paying for all those idle hours. A serverless approach changes this so we’d only have to pay for the time we’re actually using AWS compute resources.
Savvy companies are already moving some of their workloads over to AWS Lambda and reporting enormous cost savings compared to running on virtual servers. Alas for us, most of our workloads are handled by content management systems, which would not be able to run within AWS Lambda (without being purpose built to do so) so whilst it’s not something we can take great advantage of at the moment we’ll certainly have it foremost in our minds when planning new web applications and APIs.
Given the usage patterns of content management systems, where customers log-in fairly infrequently to make changes, coupled with the ability to cache the output, there’s certainly potential to utilise a serverless approach to great effect.
One of the frameworks making waves in this area is the aptly named Serveless Framework, which enables developers to:
The following is a good introduction video to the Serverless Framework:
