“Serverless” is a vast topic. Here is a short introduction.
Roughly speaking, serverless allows for deploying source code or functions without having to maintain complex server architectures.
Serverless providers such as AWS (Amazon), Azure (Microsoft), or Google Cloud only allocate and charge the necessary resources to run your code.
However, they are abusing the language, as “serverless” does not mean there’s no server involved. Those services only abstract the infrastructure away from developers.
What “functions” mean in the serverless context?
“Functions” is a generic term I will use several times in this post. It refers to some code that is initialized either by an event or a request.
Back to basics. What is a server?
Let’s keep it simple by saying it’s a computer that always runs to provide services. This computer is not like the average computer. It has a super-boosted memory and high speed, but it’s still limited.
Whether the traffic is high or not, the server is the same, and the bill too. Besides, websites and applications rarely need full server capacity all the time. There are traffic peaks.
But anyway, you have to be ready for those peaks, which are difficult to predict. In both cases, maintenance can be expensive.
The serverless model has been more and more popular over the past years since it could be a way to solve all those problems.
The idea is to focus on your code and only pay for what you use without worrying about servers no matter high the demand is.
It’s not magic
You don’t send your code as-is in some container that runs automagically. Serverless is a whole new model for your application.
Roughly speaking again, you have to compose your app with functions, and the cloud provider will execute those functions.
It’s the reason why you often read the term “FaaS” in documentations and blog posts, which means “Functions as a Service”. It’s not just a slogan. It has many consequences for your application.
Don’t get me wrong. It’s pretty cool as you don’t need to maintain/update servers. Moreover, you don’t have to handle critical aspects such as storage, load balancing, or even network issues, which can be tricky and time-consuming, especially on a high-scale application.
In addition to this, web applications often start small but may suddenly become viral, even after months or years, and again, it’s pretty hard to predict.
Before we can see how it works, it’s essential to mention some inconveniences, as serverless does not come without consequences.
To my knowledge, it’s not impossible but still quite challenging to be “cloud-agnostic”, which is IMHO inconvenient. Every cloud provider has its specificities. The prices, features, and even the philosophy are not the same, so that you might become dependent on the platform.
Moreover, cloud features are not unlimited. There are limits everywhere, for example, in database queries or code execution time. Some tasks are impossible to run with a hard timeout limit.
It might get even worse with latency and performance issues as providers put limits everywhere.
As far as I know, AWS and Google Cloud are striking examples of that. I have very little knowledge of Azure services, but I guess it’s the same. Quotas are fair, but you cannot use serverless platforms for everything and anything.
Another significant inconvenience with serverless is the cold start phenomenon. Microsoft describes it like that:
an increase in latency for Functions which haven’t been called recently.
Source: Microsoft Azure
The problem is that when a container has not been called for a certain amount of time, it gets destroyed. So the next time it’s called, it takes a little more time to reinitialize.
This pattern is inevitable with the serverless model. Cloud platforms need to reallocate the “free” space to guarantee their “infinite scale” feature. In another perspective, it’s more secure as an attacker has significantly less time to achieve an exploit.
It indeed makes sense for the cloud platforms, but does it make sense for you?
Be cautious with the language you use. Starter times for Java or C# are not the same as for Python.
Of course, there are ways to mitigate the impact of cold starts, and platforms have constantly improved that point, but you should look at it if you care about latency.
How does serverless work?
Now that we are aware of some disadvantages and that our application needs to be a set of functions that run on the cloud, it’s time to go a little bit deeper.
The classic example is the HTTP request. The visitor sends an HTTP request, which triggers your function, which launches an action such as querying a database.
The difference with a traditional server is that it’s not triggered if not used, and if there’s a high demand for your function, it will autoscale to the load you have.
The user sends an HTTP request. A server that listens to client requests gets notified. Then the matching function is located, then the function executes in a container to send a response to the client-side.
In high demand, it will copy containers, which are kernel code plus your app. You only have to make sure your app execution time and memory usage are acceptable, and it will scale.
The containers are stateless. It’s like a new container every time, so your tasks are transient, and it doesn’t retain any stateful data from previously run instances.
It’s not necessarily bad but be aware of that.
It means that serverless is excellent if your application is asynchronous, like batch processing images.
Migrating any existing and complex application is not something I would recommend, especially if it’s a monolith. Still, if you have a small number of short tasks to run or your architecture involves microservices with a reasonable and predictable execution time, it can be worth it.
I’m not surprised people say serverless is the next big thing as it probably will be, but it has significant consequences whether you are a developer or a business owner.
As a developer, you cannot skip the concept of serverless, and you might even build and deploy great applications with it, but if it’s only hype, it’s a trap.
It’s always the business requirements that drive the architecture, not the contrary.