Some unobvious Serverless benefits for DevOps
Before you, with the permission of the author, my rather free retelling of the article by DevOps-engineer Paul Hammant , in which he very simply describes not very obvious Serverless advantages from the point of view of DevOps, as well as the security of working with the application backend.
To begin with, Paul gives a diagram of how the processes are running in Serverless and what is the fundamental difference between this approach and the traditional architecture of the work of front-end applications with backend. In the diagram, the author hints at how the famous answer to the “Main Question of Life, the Universe, and All That” was obtained from Douglas Adams's Guide to Hitchhikers in the Galaxy.
')
The key fact for the author is that the Serverless functions have no domain names, no TCP / IP addresses, and even no ports are listening. This is true at least for Serverless cloud users, those who create backends based on these functions. Inside the Serverless platform, all this is definitely present, but users of the system are not visible.
All routing is done only on the basis of some logical names. It turns out that to run my Serverless zipCodeService function that decodes an address into an index, I need to know, in fact, only the address and a link to its API, which the Serverless platform itself automatically generates for me and kindly. Such a beautiful design allows you to have completely independent from each other functions for the execution of a particular application logic, which do not overlap and do not interfere with each other, and the cost of each functionality, each request, each screen can be calculated separately. These functions can even use different programming languages. And all within a single application!
At the same time, if we are talking about the same function, then Serverless allows us to create many such functions for each developer, separate CI processes, testing, styling, and production. At the same time, we clearly know who, when and in what amounts took advantage of its function and can clearly divide our costs of their implementation among individual consumers. Discipline, is not it?
In addition to all the other Serverless benefits, dropping the name: port scheme is one and the key benefits for DevOps. Although two processes on the same server still cannot listen on the same port, this is not important for us, since we share these processes using the simplest method - by name. And we can call the functions as you please, limited only by your own imagination, unlike ports, where there are strict limitations.
Also in Serverless, we do not operate on such things as sockets, at least when referring to Serverless functions and data exchange between them.
As with the use of docker containers, we do not think about the processes, why they fell and how to recover them. But, unlike the docker, we do not need to think about the docker processes and orchestration processes of containers. No need to think about setting up and supporting Kubernetes.
On the one hand, it is obvious that not everything becomes so rosy with the transition to Serverless, and the transition itself will not always be easy. On the other - why waste your time and use intermediate options in the form of a docker, if you can immediately go to the next level?
As in practice, to proceed to the next level, we previously described:
Serverless todo application with authorization and pictures
Serverless Telegram bot
Further there will be more guides!
Make your ideas come app on our serverless Swifty platform
To begin with, Paul gives a diagram of how the processes are running in Serverless and what is the fundamental difference between this approach and the traditional architecture of the work of front-end applications with backend. In the diagram, the author hints at how the famous answer to the “Main Question of Life, the Universe, and All That” was obtained from Douglas Adams's Guide to Hitchhikers in the Galaxy.
')
Ports, processes and all that.
The key fact for the author is that the Serverless functions have no domain names, no TCP / IP addresses, and even no ports are listening. This is true at least for Serverless cloud users, those who create backends based on these functions. Inside the Serverless platform, all this is definitely present, but users of the system are not visible.
All routing is done only on the basis of some logical names. It turns out that to run my Serverless zipCodeService function that decodes an address into an index, I need to know, in fact, only the address and a link to its API, which the Serverless platform itself automatically generates for me and kindly. Such a beautiful design allows you to have completely independent from each other functions for the execution of a particular application logic, which do not overlap and do not interfere with each other, and the cost of each functionality, each request, each screen can be calculated separately. These functions can even use different programming languages. And all within a single application!
At the same time, if we are talking about the same function, then Serverless allows us to create many such functions for each developer, separate CI processes, testing, styling, and production. At the same time, we clearly know who, when and in what amounts took advantage of its function and can clearly divide our costs of their implementation among individual consumers. Discipline, is not it?
Key benefits for DevOps
In addition to all the other Serverless benefits, dropping the name: port scheme is one and the key benefits for DevOps. Although two processes on the same server still cannot listen on the same port, this is not important for us, since we share these processes using the simplest method - by name. And we can call the functions as you please, limited only by your own imagination, unlike ports, where there are strict limitations.
Also in Serverless, we do not operate on such things as sockets, at least when referring to Serverless functions and data exchange between them.
As with the use of docker containers, we do not think about the processes, why they fell and how to recover them. But, unlike the docker, we do not need to think about the docker processes and orchestration processes of containers. No need to think about setting up and supporting Kubernetes.
To be continued
On the one hand, it is obvious that not everything becomes so rosy with the transition to Serverless, and the transition itself will not always be easy. On the other - why waste your time and use intermediate options in the form of a docker, if you can immediately go to the next level?
As in practice, to proceed to the next level, we previously described:
Serverless todo application with authorization and pictures
Serverless Telegram bot
Further there will be more guides!
Make your ideas come app on our serverless Swifty platform
Source: https://habr.com/ru/post/433458/
All Articles