Traditionally, if you wanted to deploy an app to the web in some way, it usually involves finding a hosting provider like AWS where you can configure a server, maybe multiple servers or even clusters of servers to provide you everything you need for your application. You develop an application and deploy it to the servers you setup. More servers will be needed to host your database platform. Perhaps you even need additional servers for features such as message queues or event buses. Lets call this a “serverful” architecture
While it is perfectly possible to get all of this up and running, it does create some significant problems, which we will take a look at, but Serverless as an architectural pattern aims to replace all this need for servers with the exclusive use of fully managed services such as you find in the cloud.
For example, instead of setting up a web server and all the associated load balancing, auto scaling, updating and management required, you use a service such as API Gateway that can receive HTTP requests. Instead of setting up an application server to execute business logic on top of these requests, you use a service such as AWS Lambda.
But why bother? Isn't the serverful way good enough? Lets take a look at the advantages that Serverless development gives you
Handling load
One of the issues around traditional serverful architectures is that it is a little difficult to handle sudden spikes in load efficiently. Usually you need to rely on being able to predict these spikes. For example, if you know the marketing team sends a newsletter out to a lot of people in the morning, you can spin up enough servers to (hopefully) manage the expected load. But what about unexpected load? The last thing you want is to get a sudden flood of traffic because of a news article or social media influencer and not be able to take advantage of potential revenue because everything just falls over under the load.
The only reliable way to make accommodation for that in a serverful environment, is to set your minimum capacity high enough to hopefully handle the load until the automated systems can spin up additional infrastructure. However, this means that even at 2am, when load is at lowest, you have a costly amount of infrastructure deployed “just in case”, billing you by the hour.
On the flip side, fully managed services such as API Gateway, DynamoDB and AWS Lambda, bill on usage only. Have no traffic at 2am? You get billed nothing. Yet these services are, by default, able to handle large spikes of traffic at once with no delay in ramping up capacity and essentially scale down to zero instantly too. At no additional cost or effort from you.
Much lower management overhead
People may tell you “oh just spin up a virtual machine in the cloud” in order to serve your application over the web. That sounds easy enough when you know what you are doing. But there’s the rub. While anyone can Google around and create cloud infrastructure with virtual machines and containers, setting them up correctly in a secure way requires the right knowledge and skills.
And once setup, it doesn’t end there. Servers need to be maintained; operating system updates, application software updates, configuration updates to conform to newer best practices, efficiency improvements, security improvements. And your application needs may change over time, so your infrastructure will need to be adjusted, added to and expanded as you grow and as your application changes.dw
But this has some downsides:
- You need to have qualified personnel available to manage this infrastructure.
- Your developers will need to wait for changes to be made to infrastructure before deploying newer features.
- Skilled dev ops professionals are in short supply and expensive
- Still run the risk of mismanagement or something critical being overlooked. While this isn’t entirely removed by Serverless architectures, it is significantly reduced.
Because Serverless architectures do not rely on managing your own infrastructure, these problems just do not exist. Does your dev team need to deploy new features that use specialised AWS services? They can go ahead and do so with no need to wait for it all to be setup and configured.
Increased development agility
Serverless development combines the use of fully managed infrastructure from your cloud provider with some code to glue the interactions with these services together. This means that, instead of your engineering team having to wait around for the dev ops team to provision the right VM's and containerto use, they can just deploy their solutions as soon as they are ready. And because there is no need to concern yourself with load balancing, patches, upgrades and other maintenance tasks, you can just focus on moving forward and meeting and even exceeding your competitors.
Lower cost
We alluded to it before. Serverless architectures only bill for usage. The problem with any serverful architecture is that you need to have something up and running 24/7 that bills you per minute just in case, even if you aren’t serving any users at all.
On top of that, since the need to manage infrastructure is reduced or entirely eliminated, there are also the reduced costs around needing to have the right team to manage things. Total Cost of Ownership is not just the bill from the cloud provider but also the people needed to run things!
Conclusion
In general, Serverless architectures solve a lot of the issues related to building applications for the web and can provide the means to build solutions that are less time consuming to release, cost less, are scalable and require less maintenance over time.
