Key Points
- For several years now, we have been promised that serverless computing would usher in a new era without a specific operating system for running applications. We were told that such a structure would solve many scalability issues. In reality, it's quite the opposite.
- Although many view serverless technology as a new idea, its roots can be traced back to 2006, with the emergence of Zimki PaaS and Google App Engine ā both utilize a serverless architecture.
- There are four reasons why the serverless revolution has hit a dead end: from limited programming language support to performance issues.
- Serverless computing is not without its merits. Far from it. However, it should not be seen as a direct replacement for servers. For some applications, they can be a useful tool.
The server is dead, long live the server!
This is the rallying cry of the proponents of the serverless revolution. A quick glance at industry press over the last few years makes it easy to conclude that the traditional server model is dead and that in a few years, we will all be using serverless architectures.
As anyone in the industry knows, and as we also pointed out in our article on , this is not the case. Despite numerous articles touting the benefits of , it has yet to come to fruition. In fact, , that this revolution may have stalled.
Some of the promises for serverless models have undoubtedly been realized, but not all. Far from it.
In this article, I would like to examine the reasons for this state. Why the lack of flexibility in serverless models still poses a barrier to their wider adoption, even though they remain useful in specific, well-defined circumstances.
What proponents of serverless computing promised
Before delving into the issues with serverless computing, let's take a look at what they were supposed to deliver. were numerous and ā at times ā very ambitious.
For those unfamiliar with the term, here is a brief definition. Serverless computing defines an architecture where applications (or parts of applications) run on demand in execution environments that are typically hosted remotely. Additionally, serverless systems can be hosted on-premises. Over the past few years, building resilient serverless systems has been a primary concern for system administrators and SaaS companies, as this architecture purportedly offers several key advantages over the traditional client-server model:
- Serverless models do not require users to maintain their own operating systems or even create applications compatible with specific OS. Instead, developers write shared code, upload it to a serverless platform, and observe its execution.
- Resources in serverless frameworks are typically billed by the minute (or even seconds). This means clients only pay for the time when their code is actually running. This is a significant benefit compared to traditional cloud VMs, where machines sit idle most of the time yet still incur costs.
- The scalability issue has also been addressed. Resources in serverless frameworks are allocated dynamically, enabling the system to easily handle unexpected spikes in demand.
In short, serverless models provide flexible, cost-effective, scalable solutions. It's surprising we didn't come up with this idea sooner.
Is this really a new idea?
In fact, the concept is not new. The idea of allowing users to pay only for the time their code is actually running has existed since it was introduced within in 2006, and around the same time, Google App Engine offered a very similar solution.
What we now call the 'serverless' model is actually older than many technologies currently referred to as 'cloud-native', which provide almost the same functionality. As noted, serverless models are essentially just an extension of the SaaS business model that has been around for several decades.
It should also be acknowledged that the serverless model is not a FaaS architecture, although there is a connection between them. FaaS is essentially the compute-oriented part of the serverless architecture, but it does not represent the entire system.
So what's all the fuss about? Well, as internet penetration in developing countries continues to rapidly rise, the demand for computing resources is also growing. For example, in many countries with rapidly growing e-commerce sectors, there is simply no computing infrastructure for applications on those platforms. This is where paid serverless platforms come into play.
Challenges of Serverless Models
The catch is that serverless models have... issues. Donāt get me wrong: Iām not saying they are bad in themselves or that they donāt provide significant value for some companies in certain circumstances. But the main claim of the 'revolution' ā that serverless architecture will quickly replace traditional architectures ā will never be realized.
Here's why.
Limited Programming Language Support
Most serverless platforms only allow applications written in specific languages to run. This seriously limits the flexibility and adaptability of these systems.
It is believed that serverless platforms support most major languages. AWS Lambda and Azure Functions also provide a shell for running applications and functions in unsupported languages, although this often incurs performance costs. So for most organizations, this limitation usually isnāt a big deal. But hereās the thing. It is assumed that one of the advantages of serverless models is that obscure, rarely used programs can be executed more cheaply because you only pay for their runtime. And obscure, rarely used programs are often written in... obscure, rarely used programming languages.
This undermines one of the key benefits of the serverless model.
Vendor Lock-in
The second problem with serverless platforms, or at least how they are implemented today, is that they often do not resemble each other at the operational level. There is practically no standardization in writing functions, deployment, and management. This means that migrating functions from one platform to another takes an extraordinarily long time.
The hardest part of transitioning to a serverless model is not the computing functions, which are usually just snippets of code, but how applications are connected to external systems like object storage, identity management, and queues. Functions can be moved, but the rest of the application cannot. This is a stark contrast to the promised cheap and flexible platforms.
Some claim that serverless models are new and there hasn't been time to standardize their operation. But they are not as new as I mentioned above, and many other cloud technologies, like containers, have already become much more user-friendly thanks to the development and widespread adoption of good standards.
Performance
Measuring the computational performance of serverless platforms is difficult, partially because vendors strive to keep information secret. Most claim that functions on remote, serverless platforms operate just as quickly as on on-premises servers, with the exception of a few inevitable latency issues.
However, individual facts suggest otherwise. Functions that were previously not run on a specific platform or had not been executed for some time require some time to initialize. This is likely because their code was moved to some less accessible data storage, although ā much like with benchmarks ā most vendors will not inform you about data relocation.
Of course, there are several ways to work around this. One of them is to optimize functions for any cloud language that your serverless platform operates on, but this somewhat undermines the claim that these platforms are 'flexible.'
Another approach is to ensure regular execution of performance-critical programs so that they remain 'fresh.' This second approach, of course, somewhat contradicts the claim that serverless platforms are more cost-effective since you pay only for the runtime of your programs. Cloud providers have implemented new ways to reduce cold starts, but many of them require 'scale to one,' which undermines the original value of FaaS.
The issue of 'cold start' can be partially addressed by running serverless systems on your own, but this incurs its own costs and remains a niche option for resource-rich teams.
You cannot run entire applications
Finally, perhaps the most important reason that serverless architectures will not replace traditional models anytime soon: they generally cannot run whole applications.
To be more precise, it is not cost-effective. Your successful monolith is probably not worth transforming into a set of forty functions connected by eight gateways, forty queues, and a dozen database instances. For this reason, serverless is better suited for new developments. Practically no existing application (architecture) can be transferred. You can migrate, but you will have to start from scratch.
This means that in the vast majority of cases, serverless platforms are used as a complement to on-premise servers for tasks that require heavy computation. This sets them apart significantly from the other two forms of cloud technologiesācontainers and virtual machinesāwhich offer a holistic way to perform remote computations. This illustrates one of the challenges of transitioning from microservices to serverless systems.
Of course, this isn't always a problem. The ability to periodically utilize massive computing resources without investing in your own hardware can provide real and lasting benefits for many organizations. However, when some applications are on internal servers while others are on serverless cloud architectures, management reaches a new level of complexity.
Long live the revolution?
Despite all these complaints, I am not against serverless solutions per se. I swear. Developers just need to understandāespecially if they are exploring serverless models for the first timeāthat this technology is not a direct replacement for servers. Instead, check out our tips and resources on and decide how best to implement this model.
Source: habr.com
