“Application Architectures”: a little about serverless architectures
In IEEE 1471, the term “architecture” is defined as the basic organization of a system, describing the connections between the components of this system and the external environment, as well as defining the principles of its design and development. In one of the previous articles, we have already considered several types of software architectures . Today, we will turn our attention to the growing popularity of serverless architectures, since this is a fairly “hot” topic in the field of software solutions: special literature and frameworks are already emerging, conferences are being organized.
Serverless architecture means that developers no longer need to configure and administer servers running control programs for the entire system. And here the point is not that there are absolutely no servers, just the entire infrastructure is supported by third-party providers, and the necessary functionality is offered in the form of services responsible for authentication processes, message passing, and so on.
')
/ photo by John Voo CC
Serverless applications are widely used by third-party services that perform tasks that are usually solved by servers. Moreover, these services can represent entire ecosystems (for example, Azure and AWS) or be independent solutions (for example, Parse or Firebase).
One of the main tasks of server-side web applications is to control the cycle of requests and responses. Server-side controllers process input requests, launch necessary applications, and build responses. In the case of serverless architecture, server-side controllers are replaced by dynamic content generation processes.
Another significant part of server-side web applications is business logic, when the server is located code that performs the processing of requests throughout the application.
In serverless applications, special software components are activated only when a request arrives. After processing the request, the component “falls asleep”. This code is often located in a managed environment that takes care of the scalability of the code and monitors the life cycle.
Imagine a classic three-tier client-oriented system with server logic. This is a popular template for applications that interact with users (a typical example is a typical ecommerce application).
It [system] consists of a representation level, a logic level and a data level. The presentation layer is a component with which users interact directly (web page, application interface, etc.). The logic layer contains code for converting user actions that are performed at the first level, that is, is responsible for the behavior of the application. The data layer consists of a storage (which includes databases, caches, file systems, etc.) where the application data is located.
The structure is as follows:
In this case, all the logic is located on the server (authentication, navigation, search), because the client side can remain “stupid”. And here is one of the options for the structure of the same application when switching to serverless architecture:
This is a rather simplified version, but even here it can be seen that many changes have occurred. Authentication tasks are now solved by the BaaS service (BaaS - Backend-as-a-Service). Via the BaaS service, the database is also accessed, which is hosted “on the side”.
Part of the server logic was transferred to the client, in particular, he is now engaged in tracking the user session, page navigation, reading from the product database and displaying information. And FaaS-function (FaaS - Function-as-a-Service), which is stored on the server for security, is now responsible for processing the purchase database.
Consider another example. Suppose a user clicks on an ad banner. In this case, you need to quickly redirect the client to the target site, at the same time saving information about the perfect transition, to invoice the advertiser.
In this case, the traditional architecture might look like this: the ad server loads the page for the user, while simultaneously sending a message to the channel, which is asynchronously processed by the navigation service that updates the databases.
In the case of serverless architecture, the following scheme is obtained:
Here, the user application is replaced by a FaaS function that runs inside the event-driven context provided by the vendor. At the same time, the FaaS environment can process several clicks of users in parallel, creating copies of the function code.
The transfer of control of a part of the systems to a third party also creates its disadvantages. For example, this may result in some loss of control and, for example, unforeseen API upgrades. Also, splitting one application into several parts with various services woven into the structure leads to an increase in the “number of inflection points”, which may complicate the testing procedure.
On the other hand, the effect of economies of scale comes into force, for example, you pay less for managing the database, since the vendor maintains many more of the same type databases. Most of the benefits of this approach will appreciate the companies that have to deal with unstable patterns of traffic consumption. When using serverless architectures, server capacities will not be idle while waiting for surges of activity.
Also serverless systems are much easier to maintain. Third-party cloud services companies are making a lot of efforts to ensure their availability and scalability. Moreover, any optimization of the performance of a FaaS application automatically reduces transaction costs. For example, if the execution of an action took 1 second, and after making the changes, it took 200 ms, this will lead to a reduction in the cost of the service by 80% without changes in the infrastructure.
Most of the FaaS applications so far are normal applications wrapped in a new shell. The development teams are putting on new solutions and looking at how they will behave in the context of serverless platforms. The serverless approach is unlikely to become a panacea, and is unlikely to replace all existing architectures , but it can be said with confidence that this area will develop and push the software development sphere forward.
PS We, for our part, also offer some interesting materials from our corporate IaaS blog:
Serverless architecture means that developers no longer need to configure and administer servers running control programs for the entire system. And here the point is not that there are absolutely no servers, just the entire infrastructure is supported by third-party providers, and the necessary functionality is offered in the form of services responsible for authentication processes, message passing, and so on.
')
/ photo by John Voo CC
Serverless applications are widely used by third-party services that perform tasks that are usually solved by servers. Moreover, these services can represent entire ecosystems (for example, Azure and AWS) or be independent solutions (for example, Parse or Firebase).
One of the main tasks of server-side web applications is to control the cycle of requests and responses. Server-side controllers process input requests, launch necessary applications, and build responses. In the case of serverless architecture, server-side controllers are replaced by dynamic content generation processes.
Another significant part of server-side web applications is business logic, when the server is located code that performs the processing of requests throughout the application.
In serverless applications, special software components are activated only when a request arrives. After processing the request, the component “falls asleep”. This code is often located in a managed environment that takes care of the scalability of the code and monitors the life cycle.
A few examples
Imagine a classic three-tier client-oriented system with server logic. This is a popular template for applications that interact with users (a typical example is a typical ecommerce application).
It [system] consists of a representation level, a logic level and a data level. The presentation layer is a component with which users interact directly (web page, application interface, etc.). The logic layer contains code for converting user actions that are performed at the first level, that is, is responsible for the behavior of the application. The data layer consists of a storage (which includes databases, caches, file systems, etc.) where the application data is located.
The structure is as follows:
In this case, all the logic is located on the server (authentication, navigation, search), because the client side can remain “stupid”. And here is one of the options for the structure of the same application when switching to serverless architecture:
This is a rather simplified version, but even here it can be seen that many changes have occurred. Authentication tasks are now solved by the BaaS service (BaaS - Backend-as-a-Service). Via the BaaS service, the database is also accessed, which is hosted “on the side”.
Part of the server logic was transferred to the client, in particular, he is now engaged in tracking the user session, page navigation, reading from the product database and displaying information. And FaaS-function (FaaS - Function-as-a-Service), which is stored on the server for security, is now responsible for processing the purchase database.
Consider another example. Suppose a user clicks on an ad banner. In this case, you need to quickly redirect the client to the target site, at the same time saving information about the perfect transition, to invoice the advertiser.
In this case, the traditional architecture might look like this: the ad server loads the page for the user, while simultaneously sending a message to the channel, which is asynchronously processed by the navigation service that updates the databases.
In the case of serverless architecture, the following scheme is obtained:
Here, the user application is replaced by a FaaS function that runs inside the event-driven context provided by the vendor. At the same time, the FaaS environment can process several clicks of users in parallel, creating copies of the function code.
Pros and cons of serverless solutions
The transfer of control of a part of the systems to a third party also creates its disadvantages. For example, this may result in some loss of control and, for example, unforeseen API upgrades. Also, splitting one application into several parts with various services woven into the structure leads to an increase in the “number of inflection points”, which may complicate the testing procedure.
On the other hand, the effect of economies of scale comes into force, for example, you pay less for managing the database, since the vendor maintains many more of the same type databases. Most of the benefits of this approach will appreciate the companies that have to deal with unstable patterns of traffic consumption. When using serverless architectures, server capacities will not be idle while waiting for surges of activity.
Also serverless systems are much easier to maintain. Third-party cloud services companies are making a lot of efforts to ensure their availability and scalability. Moreover, any optimization of the performance of a FaaS application automatically reduces transaction costs. For example, if the execution of an action took 1 second, and after making the changes, it took 200 ms, this will lead to a reduction in the cost of the service by 80% without changes in the infrastructure.
Conclusion
Most of the FaaS applications so far are normal applications wrapped in a new shell. The development teams are putting on new solutions and looking at how they will behave in the context of serverless platforms. The serverless approach is unlikely to become a panacea, and is unlikely to replace all existing architectures , but it can be said with confidence that this area will develop and push the software development sphere forward.
PS We, for our part, also offer some interesting materials from our corporate IaaS blog:
- The evolution of ERP-systems: the rejection of on-site-installations in favor of cloud and hybrid solutions
- Foreign or local data placement in the cloud: pitfalls
- Moving to the cloud: the transformation of technology and business
- The first Russian BaaS platform Scorocode located in the IaaS-cloud "IT-GRAD"
Source: https://habr.com/ru/post/309026/
All Articles