Code Running on Ionized Particles, or WTF is Serverless

We often say that technology is a cycle of concepts. I don’t think so. It’s just that bad ideas are hard to kill, and are rebranded on a regular basis, hyped with marketing bullshit. Today, we will talk about Serverless(TM).

Serverless is quite interesting. In the case of a serverless application there is a server or probably many servers running code. So the « server » we are trying to suppress here is definitely not the hardware we use to power the application. Sorry for those who think we can run a node.js application live in the air, floating to the wind of electrons and running without CPU, RAM, disks… The question is: what is the thing we positively want to suppress on the serverless world if it’s not the server?

Serverless as a Major Performance Tradeoff

What is Serverless then? it’s a function as a service hosting model, where we just upload a small piece of code and sometimes data on a service and get an instant ops-free ability to answer on a URL with the previously uploaded code. And there is the response. There is no server boot, installation, management, routing… Everything is automated. Developers just code, publish code and code is started to respond on a sandboxed environment, its lifecycle bound to the request life.

Destroying context on each HTTP request is, on the vast majority of cases, a very bad performance and stability idea

I do not get this fascination for the request-bound lifecycle of application environment. It’s not the first time it’s shown as a great achievement, there was a myth of short lived containers on a single request… Let me explain my thoughts: the vast majority of applications I see today are made to accept connections from Internet (using HTTP mainly but some others protocols too) and get some data from a database, compute then serve. So, the ability to reach the database quickly is the main performances focus. Latency is still a thing (tell that to DBaaS vendors that don't let you run your code next to the data…). Connecting to the database involves a vast quantity of TCP protocols. And there is the point: establishing a TCP connection is LONG, SLOW and in many cases the most time consuming part of the request.

So, we want to keep the database connection between several web request, and keep the TCP pool awake. We don’t want to destroy the pool on every web requests. And the database server will also work better on stable connections, be much easier to monitor and audit. It’s all built on this paradigm. And yes, I also keep my TCP connections open when I’m working on databases with HTTP based API. Take a look at what we did with warp10.rs, the Rust client we wrote for warp10. Anyway, destroying context on each HTTP request is, in the vast majority of cases, a very bad performance and stability idea.

Better Server Management already happened without Serverless

Some years ago, the consensus around the 12 factors applications made most applications able to launch themselves and able to take care of their lifecycle. The model was in reaction to « application servers ». Because this model is really difficult to scale and it makes business logic and configuration spliced in many environments, and not only in one place. With serverless you actually use an application server. A closed source application server with a strong locking model, all the code produced will lock you to the provider, and the inter-portability will be an illusion, something like JEE application server portability. Except that this one, you can’t install it on your server, even for a bigger price.

Making it easy to deploy and provide sustainability to your application is really important to help developers focus on their value, innovation and to provide a quick feedback loop. The serverless name is not about removing the hardware server, but the server management, the time consuming coordination of managing how a server works. I agree. This is why we created Clever Cloud. it’s to provide application sustainability; the ability to easily deploy and be sure that the future is managed: updates, monitoring, self healing, scalability, security, backups…

The whole server management has to be a commodity, it’s what we deliver at Clever Cloud. And I think it has to be compatible with most applications, new or legacy, and should not impact the application architecture or portability . IT automation is a great idea to help people just send the code and leave the management to software. It solves timing and synchronization constraints between people, gives them the ability to innovate, build, and adapt to the software market more easily than before. Because when someone says "I like serverless", what they say is: I do not want to hear about servers and the all ops stuff, I have work to do.

Conclusion

When you create code, just be sure you are not writing it on someone else's paper, it will hurt sooner or later.

The software industry is quite young, about 30 to 40 years old. Yet massive companies emerged quickly: billion dollar businesses bringing huge social changes. What does it mean to be a developer today, and how did that job evolve these last few years? I think we need to picture this as a global shift within the evolution of productivity.

Image Source: Disney