{"id":33935,"date":"2019-10-31T21:55:27","date_gmt":"2019-10-31T18:55:27","guid":{"rendered":"https:\/\/prohoster.info\/blog\/serverless-po-stoechkam\/"},"modified":"2019-10-31T21:55:27","modified_gmt":"2019-10-31T18:55:27","slug":"serverless-po-stoechkam","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/administrirovanie\/serverless-po-stoechkam","title":{"rendered":"Serverless in racks","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Serverless
\nServerless is not about the physical absence of servers. It is not a 'killer' of containers, nor a fleeting trend. It is a new approach to building systems in the cloud. In today's article, we will touch on the architecture of Serverless applications, look at the role of the Serverless service provider, and open-source projects. Finally, we will discuss the issues of applying Serverless.
\n<\/a><\/noindex>
\nI want to write the backend of an application (even an online store). It could be a chat, a content publishing service, or a load balancer. In any case, there will be a lot of headaches: I'll have to prepare the infrastructure, define the application's dependencies, and think about the host's operating system. Then I\u2019ll need to update small components that do not affect the rest of the monolith. And let's not forget about scaling under load.<\/p>\n

What if we take ephemeral containers, in which the required dependencies are already preinstalled, and the containers are isolated from each other and the host OS? We can 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 will be able to run it on any infrastructure. That's much better. <\/p>\n

But what if I don't want to configure containers? I don\u2019t want to think about scaling the application. I don\u2019t want to pay for idle running containers when the load on the service is minimal. I just want to write code. To focus on business logic and release products to market at lightning speed. <\/p>\n

Such thoughts led me to serverless computing. Serverless in this case means not the physical absence of servers, but the absence of headaches over infrastructure management.<\/em><\/p>\n

The idea is that the application's logic is broken down into independent functions. They have an event-driven structure. Each function performs a single 'micro-task'. All that is required from the developer is to upload the functions to the console provided by the cloud provider and link them to event sources. The code will be executed on demand in an automatically prepared container, and I will only pay for execution time. <\/p>\n

Let's figure out what the application development process will look like now.<\/p>\n

From the developer's perspective<\/h2>\n

\nEarlier, we started talking about an application for an online store. In the traditional approach, the core logic of the system is handled by a monolithic application. And the server with the application is running constantly, even when there is no load.<\/p>\n

To transition to serverless, we break the application down into micro-tasks.<\/strong> For each of them, we write its own function. These functions are independent of each other and do not store any state information (stateless). They can even be written in different languages. If one of them \u201cfails,\u201d the entire application will not stop. The architecture of the application will look like this:<\/p>\n

\"Serverless
\nSplitting into functions in Serverless is similar to working with microservices. However, a microservice can perform multiple tasks, while a function ideally should perform only one. Let\u2019s imagine we have a task to collect statistics and display them upon user request. In a microservice approach, this task is handled by one service with two entry points: one for writing and one for reading. In serverless computing, these will be two separate, unconnected functions. The developer saves computational resources, for example, if statistics are updated more frequently than they are retrieved. <\/p>\n

Serverless functions must execute within a short time frame (timeout) defined by the service provider. For example, AWS has a timeout of 15 minutes. This means that long-lived functions will need to be modified to meet these requirements \u2014 this is what differentiates Serverless from other popular technologies today (containers and Platform as a Service).<\/p>\n

We assign an event to each function.<\/strong> An event is a trigger for an action:<\/p>\n

Event<\/strong>
\nThe action performed by the function<\/strong><\/p>\n

An image of a product has been uploaded to the storage
\nCompress the image and upload it to the directory<\/p>\n

The address of the physical store has been updated in the database
\nLoad the new location into the maps<\/p>\n

The client pays for the product
\nInitiate the payment processing<\/p>\n

Events can consist of HTTP requests, streaming data, message queues, and so forth. The sources of events are data changes or new data appearances. Additionally, functions can be triggered by a timer.<\/p>\n

The architecture has been developed, and the application is almost serverless. Next, we move on to the service provider.<\/p>\n

From the service provider's side<\/h2>\n

\nTypically, serverless computing is offered by cloud service providers. They are called differently: Azure Functions, AWS Lambda, Google Cloud Functions, IBM Cloud Functions. <\/p>\n

We will use the service through the provider's console or personal account. The function code can be uploaded in one of the following ways:<\/p>\n