Serverless is not about the physical absence of servers. This is not a container killer or a fleeting trend. This is a new approach to building systems in the cloud. In today's article, we will touch on the architecture of Serverless applications, see what role the Serverless service provider and open-source projects play. In the end, let's talk about the use of Serverless.
I want to write the server part of the application (yes, at least an online store). It can be a chat, a content publishing service, or a load balancer. In any case, there will be a lot of headaches: you will have to prepare the infrastructure, determine the application dependencies, think about the host operating system. Then you will need to update small components that do not affect the operation of the rest of the monolith. Well, let's not forget about scaling under load.
But what if we take ephemeral containers in which the required dependencies are already pre-installed, and the containers themselves are isolated from each other and from the host OS? Let's break the monolith into microservices, each of which can be updated and scaled independently of the others. By placing the code in such a container, I can run it on any infrastructure. Already better.
What if you don't want to set up containers? I do not want to think about scaling the application. I don't want to pay for the downtime of running containers when the load on the service is minimal. I want to write code. Focus on business logic and bring products to market at the speed of light.
Such thoughts led me to serverless computing. Serverless in this case means not the physical absence of servers, but the absence of infrastructure management headaches.
The idea is that the application logic is broken down into independent functions. They have an event structure. Each of the functions performs one "micro-task". All that is required from the developer is to load the functions into the console provided by the cloud provider and correlate them with event sources. The code will be executed on demand in an automatically provisioned container, and I will only pay for the execution time.
Let's see how the application development process will look like now.
From the side of the developer
Earlier, we started talking about an application for an online store. In the traditional approach, the main logic of the system is performed by a monolithic application. And the server with the application is constantly running, even if there is no load.
To move to serverless, we break the application into microtasks. We write our own function for each of them. Functions are independent of each other and do not store state information (stateless). They may even be written in different languages. If one of them "falls", the application will not stop entirely. The application architecture will look like this:
The division into functions in Serverless is similar to working with microservices. But a microservice can perform multiple tasks, while a function should ideally perform one task. Let's imagine that the task is to collect statistics and display them at the request of the user. In the microservice approach, the task is performed by one service with two entry points: for writing and for reading. In serverless computing, these will be two different functions that are not related to each other. The developer saves computing resources if, for example, statistics are updated more often than they are uploaded.
Serverless functions must be performed within a short period of time (timeout), which is determined by the service provider. For example, AWS timeout is 15 minutes. This means that long-lived functions (long-lived) will have to be changed to suit the requirements - this is what Serverless differs from other technologies that are popular today (containers and Platform as a Service).
Assign an event to each function. An event is a trigger for an action:
Event
The action that the function performs
Product image uploaded to storage
Compress image and upload to catalog
The address of the physical store was updated in the database
Upload new location to maps
The customer pays for the goods
Start payment processing
Events can be HTTP requests, streaming data, message queues, and so on. Event sources are the change or occurrence of data. In addition, functions can be run on a timer.
The architecture was worked out, and the application almost became serverless. Next we go to the service provider.
From the provider side
Typically, serverless computing is offered by cloud service providers. They are called differently: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions.
We will use the service through the console or personal account of the provider. The function code can be loaded in one of the following ways:
- write code in built-in editors through the web console,
- download archive with code,
- work with public or private git repositories.
Here we set up events that call the function. Different providers may have different sets of events.
The provider built and automated the Function as a Service (FaaS) system on its infrastructure:
- The function code goes into the storage on the provider's side.
- When an event occurs, containers with the prepared environment are automatically deployed on the server. Each function instance has its own isolated container.
- From the store, the function is sent to the container, calculated, and returns the result.
- The number of parallel events is growing - the number of containers is growing. The system automatically scales. If users do not access the feature, it will be disabled.
- The provider sets the idle time of containers - if during this time the functions do not appear in the container, it is destroyed.
Thus, we get Serverless out of the box. We will pay for the service according to the pay-as-you-go model and only for those functions that are used, and only for the time when they were used.
To familiarize developers with the service, providers offer up to 12 months of free testing, but limit total compute time, requests per month, money, or power consumption.
The main advantage of working with a provider is the ability not to worry about the infrastructure (servers, virtual machines, containers). For its part, the provider can implement FaaS both on its own developments and using open-source tools. We will talk about them further.
From the side of open source
The open-source community has been actively working on Serverless tools for the last couple of years. Among other things, the largest market players contribute to the development of serverless platforms:
- Google offers developers its open-source tool - . IBM, RedHat, Pivotal and SAP participated in its development;
- IBM worked on the Serverless platform , which then became an Apache Foundation project;
- Microsoft partially opened the platform code .
Developments are also underway in the direction of serverless frameworks. и are deployed inside pre-prepared Kubernetes clusters, works with both Kubernetes and Docker Swarm. The framework acts as a kind of controller - upon request, it prepares a runtime environment inside the cluster, then launches a function there.
Frameworks leave room for configuring the tool to suit your needs. So, in Kubeless, the developer can set the timeout for the function execution (the default value is 180 seconds). Fission, in an attempt to solve the problem of a cold start, suggests keeping some of the containers running all the time (although this entails costs for idle resources). And OpenFaaS offers a set of triggers for every taste and color: HTTP, Kafka, Redis, MQTT, Cron, AWS SQS, NATs and others.
Instructions for getting started can be found in the official framework documentation. Working with them requires a little more skill than when working with a provider - this is at least the ability to run a Kubernetes cluster through the CLI. At most, include other open-source tools (for example, the Kafka queue manager).
Regardless of how we work with Serverless - through a provider or using open-source, we will get a number of advantages and disadvantages of the Serverless approach.
In terms of advantages and disadvantages
Serverless develops the ideas of a container infrastructure and a microservice approach, in which teams can work in a multilingual mode without being tied to one platform. Building a system is simplified, and fixing errors becomes easier. Microservice architecture allows you to add new functionality to the system much faster than in the case of a monolithic application.
Serverless reduces development time even more allowing the developer to focus solely on the business logic of the application and writing code. As a result, the time to market for developments is reduced.
As a bonus, we get automatic scaling under load, We only pay for the resources we use and only when they are used.
Like any technology, Serverless has its drawbacks.
For example, such a disadvantage may be the cold start time (up to 1 second on average for languages such as JavaScript, Python, Go, Java, Ruby).
On the one hand, in fact, the cold start time depends on many variables: the language in which the function is written, the number of libraries, the amount of code, communication with additional resources (the same databases or authentication servers). Since the developer controls these variables, he can reduce the start time. But on the other hand, the developer cannot control the launch time of the container - everything here depends on the provider.
A cold start can turn into a warm start when a function reuses a container launched by a previous event. This situation will arise in three cases:
- if clients often use the service and the number of calls to the function grows;
- if the provider, platform or framework allows you to keep some containers running all the time;
- if the developer runs the functions on a timer (say every 3 minutes).
For many applications, a cold start is not a problem. Here you need to build on the type and tasks of the service. A start delay of a second is not always critical for a business application, but can become critical for medical services. Probably, in this case, the serverless approach is no longer suitable.
The next disadvantage of Serverless is the short lifetime of the function (the timeout for which the function must be executed).
But, if you have to work with long-lived tasks, you can use a hybrid architecture - combine Serverless with another technology.
Not all systems will be able to work according to the Serverless scheme.
Some applications will still store data and state at run time. Some architectures will remain monolithic and some features will be long-lived. However (like cloud technologies and then containers), Serverless is a technology with a great future.
In this vein, I would like to smoothly move on to the issue of using the Serverless approach.
From the side of application
For 2018, the percentage of use of Serverless . Among the companies that have already implemented the technology in their services are such market giants as Twitter, PayPal, Netflix, T-Mobile, Coca-Cola. At the same time, you need to understand that Serverless is not a panacea, but a tool for solving a certain range of tasks:
- Reduce downtime resources. No need to constantly keep a virtual machine for services that have few calls.
- Process data on the fly. Compress pictures, crop backgrounds, change video encoding, work with IoT sensors, perform mathematical operations.
- “Glue” other services together. Git repository with internal programs, Slack chatbot with Jira and calendar.
- Balance the load. Let's dwell here in more detail.
Let's say there is a service that comes to 50 people. Under it is a virtual machine with weak hardware. Periodically, the load on the service increases at times. Then weak iron can not cope.
You can include a balancer in the system that will distribute the load, say, to three virtual machines. At this stage, we cannot accurately predict the load, so we keep a certain amount of resources running “in reserve”. And we overpay for downtime.
In such a situation, we can optimize the system through a hybrid approach: we leave one virtual machine behind the load balancer and link to the Serverless Endpoint with functions. If the load exceeds the threshold, the load balancer launches instances of functions that take over part of the request processing.
Thus, Serverless can be used where you have to process a large number of requests not too often, but intensively. In this case, running several functions for 15 minutes is more profitable than keeping a virtual machine or server all the time.
With all the advantages of serverless computing, before implementation, first of all, it is worth evaluating the application logic and understanding what tasks Serverless can solve in a particular case.
Serverless and Selectel
At Selectel we are already through our control panel. Now we are building our own FaaS platform. We want developers to be able to solve their problems with Serverless through a convenient, flexible interface.
If you have any ideas what an ideal FaaS platform should be and how you would like to use Serverless in your projects, please share them in the comments. We will take into account your wishes when developing the platform.
Materials used in the article:
Source: habr.com