Serverless Computing

Anyone running a website or an app needs computers that do the work in the background. Such computers are called servers. In the past, you had to buy them yourself or rent them permanently from a company. Serverless computing turns this around: you simply send your own program to a provider, and the provider takes care of everything else. The program is started when someone calls it, and then shut down again afterwards. The name is misleading, because servers are of course still involved. They are simply no longer visible to the developer.

Paying by the millisecond instead of by the month

The most important difference is billing. A rented server costs the same amount every month, even at night when nobody is using the app. With the serverless model, you only pay for the time the program is actually computing. Billing is often done in increments of a few milliseconds. If nobody visits for three days, running it costs practically nothing.

The second advantage is scaling, meaning growing along with high load. If a hundred thousand people suddenly open an app at the same time, the provider automatically starts a hundred thousand copies of the program. Nobody has to get up at night and add more machines. For small teams, this is a huge lever: they can offer services for which they would previously have needed their own IT department.

However, there is a price to pay. You bind yourself strongly to a particular provider, because that provider’s building blocks are embedded throughout your own code. Switching later is then expensive. Experts call this lock-in, meaning being locked in.

What happens when a function is called

The developer writes small, self-contained pieces of code called functions. A function does exactly one thing: resize an uploaded image, write an order to a database, send an email. The developer uploads this function to the provider. In doing so, they define which event should trigger it, such as a click on a button or a newly stored photo.

When the event occurs, the provider looks for a free machine, packs the function into an isolated environment, and executes it. Afterwards, this environment is torn down again. You can think of it like renting a hotel room for two minutes instead of permanently keeping an apartment. That’s why a function is also not allowed to remember anything permanently. Anything that needs to be stored has to go into a database or a storage service outside the function.

A well-known problem is called cold start. If a function hasn’t been called for a long time, its environment first has to be rebuilt. Depending on the case, this costs anywhere from a few hundred milliseconds to a few seconds. For an image upload, that doesn’t matter, but for a game with fast reactions, it does. In addition, functions are limited in time, often to 15 minutes. Long computing tasks therefore don’t fit this model.

From the weather app to the AI query

The best-known offerings are AWS Lambda from Amazon, Azure Functions from Microsoft, and Cloud Functions from Google. Many services people use every day work with these in the background. When an app sends a push notification or converts an uploaded video into several resolutions, such a function is often behind it.

The term also comes up in the field of AI. Providers are increasingly selling access to language models in a serverless way: you pay per request and don’t have to rent graphics cards. Large training runs, on the other hand, still run on permanently booked machines, because they have to compute continuously for days.

In financial news, you’ll usually encounter serverless computing as part of the cloud business of Amazon, Microsoft, and Google. Analysts watch this closely, because usage-based billing makes revenues more volatile than classic rental contracts. If the number of calls grows, revenue grows immediately along with it. If customers cut back, revenue falls just as quickly.