Serverless architecture pattern and evolution

Introduction to Serverless architecture has computing, data storage, and message communication from the use of technology. We can measure the advantages and disadvantages of the architecture from the perspectives of operation and maintenance, security, reliability, scalability, and cost. This article will introduce some common business scenarios and discuss how to use Serverless architecture to support these scenarios.

Serverless architecture

According to the CNCF's definition of Serverless computing, the Serverless architecture should be a design that uses FaaS (function as a service) and BaaS (back-end service) services to solve problems. This definition makes our understanding of Serverless a little clearer, but it may It also caused some controversy.

1. With the development of demand and technology, some serverless computing services other than FaaS have emerged in the industry, such as Google CloudRun. Alibaba Cloud has launched application-oriented serverless application engine services. These services also provide elastic scalability and The charging model of using billing has the form of serverless service, which can be said to further expand the camp of serverless computing.

2. In order to solve the impact of cold start, FaaS types such as Alibaba Cloud's function computing and AWS's Lambda have also introduced reservation functions.

3. In addition, some server-based back-end services have also launched Serverless products, such as AWS Serverless Aurora and Alibaba Cloud Serverless HBase services.

Therefore, the boundaries of serverless are somewhat blurred, but cloud services are constantly evolving in the direction of serverless. How does a vague thing guide us to solve business problems? Serverless has one of the most fundamental concepts: to maximize users' focus on business logic. Other features such as not caring about the server, automatic flexibility, billing according to usage, etc. are all served to realize this concept. The concept of Serverless allows us to better use limited resources to solve the problems that really need to be solved. It is precisely because we do less things and let others do these things, we can do more in business.

The famous Serverless practitioner Ben Kehoe described Serverless original mind follows:

1. What is my business?

2. Will doing this make my business outstanding?

3. If not, why should I do this instead of letting someone else solve the problem?

4. There is no need to solve technical problems before solving business problems.

When practicing serverless architecture, the most important mind is not to choose which popular services and technologies to overcome and which technical problems to overcome, but to always keep in mind to focus on business logic, which makes it easier for us to choose suitable technologies and services and clarify how to design application architectures.

The serverless architecture has computing, data storage, and message communication in terms of use technology. We can measure the advantages and disadvantages of the architecture from the perspectives of operation and maintenance, security, reliability, scalability, and cost. This article will introduce some common business scenarios and discuss how to use Serverless architecture to support these scenarios. In order to make this discussion not too abstract, the following will introduce some specific technical implementations as a reference, but the ideas of these architectures are general and can be implemented with other similar products.

Static site

The business requirements of a static site are relatively simple, and it is equivalent to a site for information display. For example, early websites were all displayed statically, as shown in the Chinese Yellow Pages in 1997. It was actually a single-layer page. Its characteristics can be divided into three points:

1. Its page is a static display of information.

2. The page is not updated frequently.

3. Not sure about the number of visits.

Architecture evolution

The transition from cloud to cloud and from management server to serverless (ie Serverless) shown in the figure has brought huge benefits to developers. For example, the first two solutions require budgeting, expansion, high availability, self-monitoring, etc. However, the business logic of Chinese Yellow Pages developers just wanted to simply display information and let the world understand China. It coincides with the original mind of Serverless, which allows developers to maximize their focus on business logic.

1. Buy a server and place it in the IDC computer room for hosting and running the site.
2. In order to solve the problem of high availability, I bought a load balancing service and multiple servers.
3. With the static site method, the site owner directly supports the site by an object storage service (such as OSS) and uses CDN for caching.

To develop a website under the traditional architecture mode, the website will be deployed on the server, and then the server will be hosted in the computer room, and then the user or the client will use the computer browser to access the website. Its disadvantage is that if there is a problem with this website, the server is no longer available. In order to maintain the high availability of this website, another load balancer and two reserve servers will be linked. This is the architecture of the Serverful service. Serverless architecture for developers, it only needs to publish its static pages directly to object storage, and object storage itself is a serverless file storage service, which can store static pages, pictures, audio, video, etc., and Achieve unlimited expansion.

Serverless architecture has advantages that other solutions can’t match:

• There is no need to manage servers, such as operating system security patch upgrades, fault upgrades, and high availability. These cloud services (OSS, CDN) all help.
• There is no need to estimate resources and consider future expansion, because OSS itself is flexible, and the use of CDN makes the system less delay, lower cost, and higher availability.
• Pay according to the resources actually used, including storage fees and request fees. Request fees are not charged when there is no request.
• Security: Such a system can't even see the server and does not need to log in through SSH. DDOS attacks are also resolved by cloud services.

Static is a good thing, and caching is also a technology often used in software development. Although there is a joke that computer technology has only two hardest things, invalidating caches and naming them. But this also reflects the importance of caching, as long as it is used properly, it can greatly improve the performance of the system.

For example, many Android apps currently need to be released to various channel vendors such as Xiaomi App Store and Huawei App Store. Developers prefer to package a master package and store it in the object store instead of repeatedly performing channel package maintenance. Wait for repetitive work. For users, only need to maintain a parent package, and then maintain a simple dynamic calculation. In fact, CDN can not only return to object storage, but also return to dynamic backends, such as API gateways, function computing, load balancers, etc. There are not only CDNs that can use this type of caching, but also Redis and in-process ’S cache.

Monoliths and microservices

Why are there monoliths and microservices? For a static site, it may only solve some needs for displaying information, but as the complexity of business requirements increases, a dynamic site is needed. for example:

• On Taobao's product pages, it is unrealistic to use static pages to manage product information. There are a large number of products, frequent updates of product listings and off-shelf information, and complex product pages.
• Netease and Sina portal sites, real-time news is constantly updated, comments, likes, forwarding, etc.

Static pages and sites are suitable for scenarios where the content is less updated and the frequency of updates is low. On the contrary, for example, a product detail page on Taobao in the picture, it is not realistic to use static site pages for the following reasons:

1. The commodities are massive.

2. Frequent updates

3. There are a wide range of dynamic information sources, such as basic information, prices, freight, sales, inventory, comments, etc., which change in real time.

The Serverless native mind mentioned above helps us focus on business. for example:

1. Do you need to purchase your own server to install the database to achieve high availability, manage backups, upgrade versions, etc., or you can leave these things to managed services such as RDS; whether you can use Serverless database services such as table storage, Serverless HBase, etc., to achieve flexibility according to use Expansion and shrinkage and payment.
2. Does a single application need to purchase a server to run it, or it can be handed over to hosting services, such as function computing and serverless application engines.
3. Whether it is possible to implement lightweight microservices through functions, rely on the capabilities of load balancing, auto-scaling, pay-as-you-go, and system monitoring provided by function computing.
4. Do microservice applications based on Spring Cloud, Dubbo, HSF, etc. need to purchase servers to deploy applications, manage service discovery, load balancing, elastic scaling, fuse, system monitoring, etc., or can these tasks be handed over to serverless application engine services.

Regarding the evolution of the architecture, it has gone through the process of Serverful monolithic architecture to Serverful microservice architecture and then to Serverless microservice architecture. With the development of business, the scale of the organization continues to increase. At this time, it is generally necessary to split the logic in a single application into multiple execution units. For example, the comment information on the product page, sales information, and distribution information can all correspond to A single microservice; and the architecture on the right introduces an API gateway, function computing or SAE to implement the computing layer, and a large amount of work is exchanged for cloud services. The advantage of the serverless microservice architecture is that each unit can be highly autonomous, the units are loosely coupled, and it is easy to develop (for example, use different technologies), deploy, and expand.

However, this architecture also introduces some problems of distributed systems, such as load balancing of communication between services, failure handling, distributed transactions, etc. Organizations of different sizes at different stages can choose a suitable method that can solve the primary business problems it faces.

In fact, although the product page here has a lot of information, it is still relatively simple, mainly because it only involves the read operation. This diagram shows the interaction of multiple microservices within the system. By providing a commodity aggregation service, multiple internal microservices are presented to the outside in a unified manner. The microservices here can be implemented through SAE or functions.

Another extension is that the business requirements we started did not mention the need to support the access of different clients. In reality, this requirement is common, and the information required by different clients may be different. For example, mobile phones can make relevant recommendations based on location information. How can mobile clients and different browsers benefit from the Serverless architecture?

This involves another word, BFF, backend for fronted, which is a backend customized for the front end. This is highly regarded by front-end development engineers. Serverless technology makes this architecture popular because front-end engineers can write directly from a business perspective. BFF, without the need to manage the server-related things that make front-end engineers more headaches.

Event trigger

This section introduces a specific business scenario: for the event-triggered scenario, it explains how the Serverless architecture solves the problem. The dynamic page generation mentioned above is completed by synchronous requests. There is also a common scenario in which request processing usually takes a long time or more resources, such as image and video content management in user comments, involving how to upload images and processing Picture (thumbnail, watermark, review, etc.), video processing to adapt to different client playback needs. For example, the business scenario in the picture is a buyer show. When the buyer completes the transaction and wants to post a comment on a picture or video, after the buyer is finished, the back-end service needs to add a watermark to the picture, then zoom and review; the video is also Need to do a variety of format conversion and audit, because it needs to adapt to a variety of different terminals.

This kind of business feature is actually very CPU intensive, and the execution time of each task is generally longer. Therefore, for this kind of business, we may have some technological architecture evolution.

For example, the familiar Douyin is a business scenario where users upload videos. At the back end of Douyin, the video needs to be processed uniformly: for example, watermarking, transcoding into various bit rates or length and width resolutions to suit different mobile phones. The establishment of this business consumes CPU computing resources very much. At the same time, bandwidth pressure is also great. At this time, you can only increase bandwidth and machines continuously, and the result is that operation and maintenance costs continue to increase; the second problem is that there will be peaks and valleys, such as the subway time at 8 o'clock in the morning and 1 minute for dinner at noon. Or at 8 o'clock in the evening, the business volume may be very high. If your business requires 1,000 machines, but in the early morning, these 1,000 machines may not be used, which will cause some waste of resources. At the same time, you It is also necessary to handle operations and maintenance monitoring, expansion of flexibility, expansion and contraction, and other tasks.

Extending the evolution of the architecture, the ability to trigger events is a very important feature of FaaS. This Pub-Sub event-driven model is not a new concept, but before the popularity of Serverless, event producers, consumers, and interconnection hubs in between All users are responsible, just like the second architecture in the previous architecture evolution. Serverless allows producers to send events and maintain connection hubs are omitted from the user's responsibilities, and only need to pay attention to the logic of consumers, which is the value of Serverless. The function computing service also integrates other cloud service event sources, allowing you to use some common modes in your business more conveniently, such as Pub/Sub, event flow mode, and event sourcing mode.

Service Orchestration

Although the previous product page is complicated, all operations are read operations, and the aggregation service API is stateless and synchronous. Let's take a look at one of the core scenarios in e-commerce-the order process.

For example, if a user makes a purchase on Taobao, or places an order for takeaway when Ele.me, it all involves an order process. This order process is more complicated than merchandise display. Because in the order process, it has to keep more things. For example, when a user places an order, the first step is to check the inventory. If the inventory is sufficient, the inventory will be reduced by 1, and then we will connect to WeChat or Alipay to pay for the deduction. After the order is down, we need to arrange logistics. Delivery, but also check the details of the logistics and send SMS notifications and so on.

At the same time, you have to write various retry logics in these code logics. If it fails in the end, we have to roll back what has been done. If the user cancels the order, then more rollbacks are needed. For example, if the money has to be returned to the user, this scenario is very complicated. We can see how this process is issued. For example, after the user places an order in the first step, he actually goes to this order service, which will generate an order number; then it will involve who the buyer is and who the seller is. In the second step, we will send the message to the message bus, and these other services (delivery service, inventory service, payment service) are subscribed to the message bus.

On the other hand, its observability and descriptibility are not good, and secondly, its reusability is poor in layout. If the developer changed the service of another process, then this set would have to be rewritten.

In this serverless architecture, each service is directly independent and does not pass information through events. Instead, there is a centralized coordinator service to schedule a single business service, and the business logic and status are maintained by the centralized coordinator. After placing an order from the gateway layer, a function execution of the function calculation is triggered, and the logic of the function execution will trigger the execution of a workflow. For example, the picture on the right is actually written by the user. This process is the workflow.

For example, the first step is to place an order, and the second step is to pay. What will happen if the payment is successful, and what will happen if the payment fails. The entire order is equivalent to the execution of the process on the right. The execution of each process can be traced. You can understand that he is an organizer, and then call other cloud services.

So in this architecture, we can see that for developers, there is no need to do a message bus, engage in logical processing, and maintain data consistency. He only needs to focus on his business logic, write the services invoked by each process, and write these orchestrated processes.

• Write a lot of code to implement functions such as orchestration logic, state maintenance, and error retry, and these implementations are difficult to reuse by other applications.
• Maintain the infrastructure for running orchestration applications to ensure high availability and scalability of orchestration applications.
• Consider state persistence to support multi-step long-running processes and ensure the transactional nature of the process.

If you directly rely on services on the cloud, such as Alibaba Cloud's Serverless workflow service, these things can be done by the platform. Users are back to the state where they only need to focus on business logic. The picture on the right is the process definition. We can see that this achieves the effect of the previous event-based Saga mode, and the complexity of the process is greatly simplified.

Serverless technology will undoubtedly take on more responsibilities, allowing users to build applications faster and better. There are many scenarios that can be covered by using the Serverless architecture. Here is just an introduction to the architecture of several scenarios such as the front-end and back-end of the Web site, microservices, event triggering, and service orchestration. Less is more handing things over to reliable platforms (such as cloud vendors) to allow developers to focus more on their core business values is a philosophy that Serverless has always advocated.

This article is compiled from "ServerlessLive Series", the course viewing address: https://developer.aliyun.com/live/247330

and reply "924" to get the Serverless series classroom lecturer PPT!

Copyright Notice: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users, and the copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.