Serverless computing has grown in popularity over the past couple of years, but it is still a bit of a dark art to many. So what is it and why should you care?
Wikipedia describes serverless as follows: Serverless computing is a cloud-computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.
…but what does that actually mean?
Originally, the term Serverless was used to describe rich-client applications that used the wide array of cloud services (such as cloud-accessible databases, authentications services etc) as their “back-end”. This is now more commonly referred to as Back-end as a Service (BaaS). More recently and now more commonly, Serverless is used to refer to Function as a Service (FaaS). In this model, developers write and deploy individual functions to cloud providers who wholly manage the underlying infrastructure required to run a developer’s code. You then only pay for
hosting when your code is executing. Some examples of the major implementations of FaaS are: AWS Lambda , Azure Functions , Google Cloud Functions. It is on this second definition that we will focus.
So, why should we be interested in Serverless?
Serverless provides developers with an application and hosting model that differs significantly from traditional web application architecture and hosting. With this new approach come both advantages and disadvantages. If used correctly, it can have game-changing benefits to your business, but in the wrong hands it can cause all sorts of problems. You need to understand both sides to decide if Serverless is suitable for your application or just an added complication to its development.
Pros
- It can vastly reduce hosting costs
This is the usual headline claim: With FaaS, you only pay for the hosting infrastructure whilst your code is running. If your function is called once a day and only runs for 5 seconds, you only pay for 5 seconds of hosting for that day. - It removes the need for you to manage servers to run your application code
The cloud provider manages all of the underlying infrastructure to provision FaaS. Your team do not need to provision, monitor or manage virtual machines or container clusters, thus reducing a cost overhead. - Inherently scalable
FaaS is inherently scalable –The cloud provider will automatically increase and decrease the infrastructure required to run your application code in line with demand. You don’t need to
manually scale or setup complex scaling environments. - Reduction in lead time
Your developers only have to deploy code to the cloud provider and not worry about infrastructure. In addition, to use a FaaS your application will be split into multiple functions, meaning it can be quick and easy to make changes and additions to an application. - Greener computing
This has become more of a focus for many companies of late. Servers obviously consume energy to run; but it has been estimated that, with traditional application hosting models, servers only deliver between 5% and 15% of their maximum computing power over the course of a year (see this Forbes.com article). So much of that energy is going to waste. Cloud providers need to optimise utilisation in order to maximise profit, so it is likely they will use much less energy to provide the same availability of compute power.
Cons
- Lack of available developer skills
With any new programming model, there are pitfalls to avoid. Serverless is no different and your team need to know how to avoid them. Some examples: - You must ensure your functions assume horizontal-scaled parallelism from the outset
- FaaS functions are effectively stateless, so you must manage this yourself.
- FaaS functions are typically limited in how long each invocation is allowed to run. So it is not suited to long running functions.
- 3rd party dependencies can be cumbersome
- Performance (specifically “cold starts”)
Due to the underlying infrastructure used by the vendor to run your application functions, there can be delays to your function starting. This is often referred to as a cold start. (This gitconnected.com article explains in more detail). - Vendor lock-in
There are differences between the different serverless ecosystems provided by each cloud vendor. It is highly likely that whichever one you choose you will have to make use of some vendor specific tools or features along the way. This will then become a hurdle you need to jump should you wish to change vendors. - Local testing and debugging can be problematic
Depending on which FaaS provider you use, it can be difficult or cumbersome for your developers to perform integration tests on an application.
So, given all of that, should you be using Serverless or not? As with many things in software development, that depends on your use case. If you are developing low latency trading applications, perhaps not. However, if you have an application with unpredictable and peaky loads, it might be the solution for you.
One thing is for sure, if you do adopt the serverless model, you must ensure that your (and your developers) understand the advantages and disadvantages of the model to ensure you get the most from it.
.png)
.png)
