One of the biggest buzzwords in the software industry right now is Serverless Architecture. Unfortunately, there is a little ambiguity about what the term Serverless actually means though. In this article we will examine the two different (but also overlapping) definitions of Serverless.
The term Serverless was first used in the industry to describe an application whose backend logic is mostly maintained by a 3rd party “cloud” provider. The client application is usually a rich Single-Page Application (SPA) or Mobile Client. These clients talk through the 3rd party APIs to the cloud hosted backends.
The benefit to this architecture is that the developers don’t have to write or maintain any of the backend logic. They can just plug their client in and immediately get access to a wide range of features. Some of these Backend-as-a-Service (BaaS) providers focus on one particular service (like authentication). Other providers offer a more complete solution.
There are downsides to using a BaaS solution though. The first is a lack of control over the backend code of your application. This is not a complete problem though with the introduction of our second form of Serverless which we will discuss shortly. Another issue with BaaS is that it can be more expensive when you grow your product past your first 1000 users. It’s cheap to start with, but once you get enough users it can get pricy and it’s difficult to swap out backends on a live application.
Serverless has also been applied to a newer application model called Functions-as-a-Service (FaaS). These functions are run in a stateless container hosted on 3rd party infrastructure. The most popular FaaS provider is AWS Lambda.
The major benefits to this model are the increased control over the backend code and the cost compared to BaaS. Since we are writing the code that gets executed inside the FaaS container, we have full control over the source code, unlike with a BaaS. And since we are managing a lot more of the application ourself, our direct costs will decrease (although development costs will go up!). FaaS also allows us to scale much more than a BaaS (or even traditional hosted SaaS solutions). Ten’s of millions of users without a major rewrite from the launch code is not unheard of!
The downsides really start to present themselves when we talk about development costs. A full Serverless Stack will contain more technologies in it than traditional application stacks. This means we either need a lot of specialist developers or our current developers need to learn a lot more of the stack themselves. We also need to write a lot of our own functionality since there aren’t many existing frameworks like in a traditional development stack.
What Serverless is Not
When talking to people about FaaS, I have been asked a very specific question: “How is this different than, say, Heroku?” Heroku, and services like it, are Platform-as-a-Service (PaaS) providers. You use them to provision new compute power to run your applications similar to how FaaS provisions new compute power to run your code. Are they the same?
In short, no! PaaS allows you to spin up new compute power, but the speed it spins up is the deciding factor. It can take minutes to scale up Heroku dynos to meet a surging traffic demand. Whereas with serverless it usually takes less than 20ms to spin up a new container to handle another request. Serverless applications scale on a per-request basis in near-real-time. PaaS scales to meet larger traffic patterns, but it can take minutes to get the new instances up.
Hopefully you have a much better understanding of Serverless now. There are two major forms that it can take, and you can mix and match each form to meet your needs. Using a BaaS to handle authentication and then FaaS to handle your other requests is a common Serverless architecture. We will cover Serverless Architectures in future articles to be sure to sign up for the newsletter to get those!