Each serverless platform has servers.

For the past few years, we have increasingly heard the term “Serverless” in relation to cloud services. Moreover, in Europe our own Voximplant is often called “Serverless Telephony for Developers”. But we have servers, and many! Where does this strange name come from and what exactly do those who use it mean? In order to summarize and gather information about Serverless in one place, the organization with the long name Cloud Native Computing Foundation devoted an official document to it, Swapnil Bhartiya carefully studied it and wrote an interesting article (he has been writing interesting articles about linux and open source for 15 years ), and we adapted the translation for Habr. By the way, once again updating the holivar "why translate for Habr." First, in Russian, if the translation is adequate, read faster and less cognitively stressful. Even with very good English. Physiology, nothing personal. Secondly, if someone decided to translate the article, then it is most likely worth it. If you are not an expert in something, you can safely skip over 100 articles published on an interesting topic over the past month, and see only those two that were translated for Habr.

“Serverless computing” or “Function as a Service” (FaaS) are new terms that our industry has come up with, known for their love of inventing new terms as technology develops. But what does it mean? What is "serverless computing"?

Before turning to the definition, I want to take a little history lesson from Sirish Raghuram, the CEO and co-founder of Platform9. This will shed light on the evolution of serverless.

In the 90s, we created applications and ran them on hardware. Then came the virtual machines, which allowed to run many independent applications on the same machine. But you still ran an isolated copy of the operating system to run each application. With the advent of containers, this duplication has disappeared, making process isolation quick and flexible.

The Serverless concept, namely “Function-as-service”, continues this approach, removing the steps of “building, deploying and running an application”. All this machinery is hiding from the developer and there is no longer any need to think about container deployment using Kubernetes.

What is Serverless?

There is no single definition. To help the developers, the Cloudless Native Computing Foundation (CNCF) Serverless Working Group has released an official document describing what it is.
')
In accordance with this document, “Serverless” refers to the concept of creating and launching applications without the need to configure the server part (from the translator: including such a “server part” as a description of the docker container or heroku deployment). As part of this concept, the application is divided into functions that are placed on the cloud platform and are executed, scaled and paid for there depending on the current load.

Ken Owens, a CNCF member of the Technical Oversight Committee, defines the main task of Serverless as “helping users build and run applications without having to manage individual servers and scale them.”

Chris Aniszczyk, COO at CNCF, believes that Serverless is a natural evolution of cloud services. CNCF helps promote Serverless by providing communication between technology-using companies and helping to create a single standard.

This is not about "no servers"

Do not let yourself be misled by the translation of "Serverless" as "without servers." Of course there are servers. As stated in one of the quotes above - they are "hidden." But not disappeared.

The obvious advantage of the Serverless approach is that developers may not worry about technical details that do not add value to the solution they create (from the translator: if the value is that the solution provides the minimum cost, then you need not “Serverless”, but raise and customize your cluster). Developers may stop worrying about deploying servers and focus on the code that benefits. Time is money. Especially the time that is not spent on infrastructure management DevOps tasks. Developers do not need to invent a scaling architecture themselves so that their solution will experience peak hours of workload; this happens automatically. Since providers of “Serverless” solutions take money only during the execution of functions (or in a minute of conversation, as we are at Voximplant), the cost of cloud infrastructure is reduced and there is no need to pay for “flashing lights” equipment waiting for the peak load.

But after all, these servers flashing with lights should be somewhere!

In the case of public clouds, such as the Google Cloud Platform, AWS and Microsoft Azure, cloud owners use its resources to support the right amount of FaaS servers. In the case of private clouds or data centers, this is done by a separate DevOps team, allowing developers to not bother with servers and write code that is useful, and not infrastructure. Division of labor!

For this reason, many companies, such as Suse, are moving away from the term “Serverless” and are beginning to use the term “FaaS”. After all, they offer solutions with which serverless servers are created.

With "Serverless" sorted out. What are the "Functions"? A new future for working with applications?

Pink pull, or Event-Driven Computing

Many see Serverless as an umbrella term describing FaaS and a bunch of other things. By definition, CNCF, FaaS organizes the operation of the application as a function call in response to events or HTTP requests. As written in the official document, “developers organize the application code as a set of functions that are executed in response to events or HTTP requests. Developers put small code fragments in FaaS, and these fragments are discretely executed, providing automatic scaling based on load, without the need for developers to manage servers or any other low-level infrastructure. ”

Does this mean that FaaS is a new silver bullet for developing and deploying applications? Does not look like it. At least for the moment. FaaS solves problems for a number of use cases, and this series is gradually expanding. A good scenario for FaaS is “calling the code in response to an event that occurred.”

Consider an example: a user takes a photo on his phone and uploads it to the cloud. A lot of different things happen during the download process: “exif” data is read, a small picture is made for previewing, the content is analyzed using machine learning, and information about the image is recorded in the database. All these functions are generated by a single image loading event. They stop their work after handling the event. And this is exactly what FaaS does well: quickly run the code to perform all these tasks and disappear just as quickly.

This was one example. As another one, we can consider the Internet of Things device, in which the motion sensor triggers an event, instructing the camera to start recording and then sending it to the right person. The climate control system can start the fan in response to changes in temperature. These are a few examples from the set when the event model is well suited as a basis. But, of course, this model of work is not suitable for all applications.

CNCF has already analyzed us and suggests that FaaS be considered as a suitable solution in the following cases:

• asynchronous and well-parallel tasks;
• "Floating" load with random peaks;
• the lack of a saved state and requirements for an instant “cold start”;
• rapidly changing requirements when you need to test and throw out a lot of ideas.

Why should this bother us?

“Serverless” with FaaS at the ready - new technologies and paradigms. Just like virtual machines and containers, FaaS solutions can change the rules of the game again. Now the technology is only evolving, but it has a good potential to quickly go beyond simple solutions and the use cases described above.

Common sense suggests that companies that rely on cloud computing make sense to include Serverless in their development strategy. IT is always like this: if you want a competitive advantage, try to use the latest technologies.

It's time to add a little “Serverless” to our servers.

Question Habru

Colleagues, what do you think, what written term will settle down? "Serverless"? "Serverles"? "Serverless"? Or something different?