Serverless architecture model and evolution

Serverless architecture

According to the CNCF 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 the problem. This definition has made our understanding of Serverless slightly clearer, but may also cause some controversy.

With the development of demand and technology, there have been some forms of Serverless computing services other than FaaS in the industry, such as Google CloudRun. Alibaba Cloud has launched application oriented Serverless application engine services. These services also provide elastic scalability and a pay-as-you-go model, with the form of Serverless services, which can be said to further expand the Serverless computing camp.

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

Other serverful 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 continue to evolve in the direction of Serverless. How can a vague thing guide us to solve business problems? Serverless has a fundamental philosophy: maximizing user focus on business logic. Other features such as server indifference, automatic resiliency, and billing by use all serve to achieve this philosophy. The concept of Serverless allows us to better use limited resources to solve real problems that need to be solved. It is precisely because we do less and let others do these things instead that we can do more in the business.

The famous Serverless practitioner Ben Kehoe describes the native mind of Serverless as follows:

What is my business?

Can doing this make my business outstanding?

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

4. There is no need to resolve technical issues before resolving business issues.

When practicing the Serverless architecture, the most important mental task is not to choose which popular services and technologies to tackle, but to always keep in mind and focus on business logic, making it easier for us to choose the appropriate technologies and services and clarify how to design the application architecture.

The Serverless architecture includes computing, data storage, and message communication in terms of usage 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 explore how to use the Serverless architecture to support these scenarios. In order to make this discussion less abstract, some specific technical implementations will be introduced below as a reference, but the ideas of these architectures are generic and can be implemented using other similar products.

Static site

The business requirements of a static site are relatively simple, and it is equivalent to a site for displaying information. For example, early websites were static displays, such as the 1997 China Yellow Pages, which were actually a single layer page. Its characteristics can be divided into three points:

1. Its page is a static display of information.

2. Its page updates are not frequent.

3. Uncertain access volume.

Evolution of architecture

The transformation shown in the figure from being off the cloud to being on the cloud, from managing servers to not managing servers (i.e., Serverless), has brought enormous benefits to developers. For example, the first two solutions require budgeting, expansion, high availability, and self monitoring. In those days, the business logic of Chinese Yellow Pages developers was simply to display information and let the world understand China. It coincides with the native mind of Serverless, which allows developers to maximize their focus on business logic.

1. Purchase a server and place it in the IDC room for hosting and running the site.

2. In order to solve the problem of high availability, we also purchased a load balancing service and multiple servers.

3. Using the static site method, the webmaster directly supports the site by an object storage service (such as OSS), and uses CDN as a cache.

Developing a website under the traditional architecture mode involves deploying the website on a server, then hosting the server to the computer room, and then users or clients access the website using a computer browser. The disadvantage is that if there is a problem with the website and the server is no longer available, in order to maintain the high availability of the website, a load balancing and two reserve servers will be attached, which is the architecture of the Serverful service. For developers, the Serverless architecture only needs to publish its static pages directly to object storage, which itself is a serverless file storage service that can store static page pages, images, audio, video, and so on, with unlimited expansion.

The Serverless architecture has advantages that other solutions cannot match:

• There is no need to manage servers, such as security patch upgrades, fault upgrades, and high availability of operating systems. These cloud services (OSS, CDN) all help.

• There is no need to estimate resources and consider future expansion because OSS itself is elastic, and using CDN makes system latency smaller, costs lower, and availability higher.

• Pay based on the actual resources used, including storage fees and request fees. If there are no requests, no request fees will be charged.

• Security: Such a system cannot even see the server and does not require SSH login. DDOS attacks are also handled 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 of the most difficult things, invalidating and naming caches. However, this also reflects the importance of caching, which can greatly improve system performance if used properly.

For example, many Android applications currently need to be released to various channel providers such as Store and Store. Developers prefer to package a master package and place it in object storage, rather than repeatedly perform repetitive tasks such as channel package maintenance. For users, they only need to maintain a parent package and then maintain a simple dynamic calculation. In fact, CDNs can not only be backsourced to object storage, but also can be backsourced to dynamic backends, such as API gateways, function calculations, and load balancers. There are not only CDNs that can use this type of cache, but also Redis, as well as in-process caching.

Monomer and microservice

Why are there monomers and microservices? For static sites, they may only address the need to display information, but as the complexity of business requirements increases, dynamic sites are needed. For example:

• It is unrealistic to use a static page method to manage product information on Taobao's product pages. There are a large number of products, frequent updates of product information on and off the shelf, and complex product pages.

• Netease and Sina portals, constantly updating real-time news, commenting, liking, forwarding, etc

Static pages and sites are suitable for scenarios where the content is low and the frequency of updates is low. Conversely, such as a product details page on Taobao shown in the figure, using static site pages is not realistic for the following reasons:

1. Goods are in huge quantities.

2. Frequent updates

3. Dynamic information comes from a wide range of sources, such as basic information, prices, freight, sales, inventory, comments, and so on, which change in real time.

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

1. Do you need to purchase your own server to install databases, achieve high availability, manage backups, upgrade versions, etc., or can you delegate these matters to managed services such as RDS; Is it possible to use table storage, Serverless HBase, and other Serverless database services to achieve elastic capacity expansion, scaling, and payment based on usage.

"Do individual applications need to purchase their own servers to run, or can they be handed over to managed services, such as function computing and Serverless application engines?".

Whether lightweight microservices can be implemented through functions, relying on the load balancing, automatic scaling, on-demand payment, system monitoring, and other capabilities provided by functional computing.

4. Whether microservice applications based on Spring Cloud, Dubbo, HSF, and other implementations need to purchase their own servers to deploy applications, manage service discovery, load balancing, elastic scaling, fuse, and system monitoring, or whether these tasks can be delegated to application engine services such as Serverless.

The evolution of architecture has undergone a process from Serverful monolithic architecture to Serverful microservice architecture and then to Serverless microservice architecture. With the development of business and the increasing size of organizations, it is generally necessary to divide the logic in a single application into multiple execution units. For example, the review information, sales information, and distribution information on the product page can all correspond to a single microservice; The architecture in the right figure introduces API gateways, functional computing, or SAE to implement the computing layer, exchanging a large amount of work for cloud services to complete. The advantage of Serverless as a microservice architecture is that each unit can be highly autonomous, loosely coupled, and easy to develop (such as using different technologies), deploy, and expand.

However, this architecture also introduces some issues in distributed systems, such as load balancing of inter service communication, failure handling, and distributed transactions. Organizations at different stages and sizes can choose appropriate ways to solve the primary business problems they face.

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

Another extension is that our initial business requirements did not mention the need to support access by different clients. This requirement is common in reality, and different clients may require different information. For example, mobile phones can make recommendations based on location information. How can mobile clients and different browsers benefit from the Serverless architecture?

This brings up another word: BFF, backend for fronted, which is a customized backend for the front-end, which is highly praised by front-end development engineers. Serverless technology has made this architecture widely popular, because front-end engineers can directly write BFF from a business perspective without having to manage server-related issues that make front-end engineers even more headache.

Event Triggering

This section describes how the Serverless architecture solves the problem by introducing a specific business scenario: an event triggered class scenario. The dynamic page generation mentioned above is accomplished by synchronous requests, and there is a common scenario where request processing typically requires a long time or more resources, such as image and video content management in user reviews, involving how to upload and process images (thumbnails, watermarks, reviews, etc.), and video processing to adapt to different client playback needs. For example, the business scenario in this image is a buyer show. When a buyer completes a transaction and wants to post a comment on an image or video, the back-end service needs to watermark the image, then zoom in and review it; Video also needs to be converted and reviewed in multiple formats, as it needs to be adapted to various terminals.

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

For example, the familiar Tiktok is the business scenario where users upload videos. At the back end of Tiktok, video also needs to be processed uniformly: such as adding watermark, transcoding to different bit rates or length width resolutions to adapt to different mobile phones. The establishment of this business consumes CPU computing resources. At the same time, the pressure on bandwidth is also great. At this time, you can only continuously add bandwidth and machines, and the result is that the cost of operation, maintenance, and maintenance continues to increase; The second problem is that there may be peaks and valleys. For example, at the subway time of 8 o'clock in the morning and at 1 o'clock for lunch or at 8 o'clock in the evening, the business volume may be very high. If your business requires 1000 machines, but in the early morning, these 1000 machines may not be used, which may cause some waste of resources. At the same time, you also need to handle operations and maintenance monitoring, flexibility expansion, capacity expansion, and other work.

Extending the architecture evolution a bit further, event triggering capability is a very important feature of FaaS. This Pub-Sub event driven model is not a new concept, but before the popularity of Serverless, the event producers, consumers, and intermediate connection hubs were all user responsible, just like the second architecture in the previous architecture evolution. Serverless allows producers to send events and maintain connection hubs, both of which are omitted from user responsibilities, and only needs to focus on consumer logic. This is the value of Serverless. Functional computing services also integrate other cloud service event sources, making it easier for you to use some common patterns in your business, such as Pub/Sub, event flow mode, and Event Sourcing mode.

Service Orchestration

Although the previous product page is complex, all operations are read operations, and the aggregation service API is stateless and synchronized. Let's take a look at a core scenario in e-commerce - the order process.

For example, when a user makes a purchase on Taobao, or places an order for takeout while hungry, it involves an order process. This order process is more complex than product presentation. Because in the order process, it needs to retain more things. For example, when a user places an order, the first step is to check the inventory. If the inventory is sufficient, then the inventory will be reduced by 1, and then the WeChat or Alipay service will be connected to pay the deduction. After the order is issued, the logistics will be arranged to deliver the goods. At the same time, the logistics details will be checked and SMS notification will be made.

At the same time, you need to write various retry logic in these code logic. If it ultimately fails, we need to roll back what has already been completed. If the user cancels the order, there are more things that need to be rolled back. For example, if the money needs to be returned to the user, this scenario is very complex. We can take a look at how this process is generated. For example, after the user places an order in the first step, they actually go to the order service, which will generate an order number; Then it involves who the buyer is and who the seller is. In the second step, we will send the message to the message bus. Other services (delivery service, inventory service, payment service) are subscribed to the message bus.

On the other hand, its observability and descriptiveness are not good. Secondly, in terms of layout, its reusability is poor. If a developer changes to a service for another process, this set will need to be rewritten.

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

For example, the first step is to place an order, the second step is to pay, what happens if the payment succeeds, and what happens 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 back. You can understand that he is an organizer and then calls other cloud services.

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

• Write a large amount of code to implement orchestration logic, state maintenance, and error retry functions, which 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 rely directly on cloud services, such as Alibaba Cloud's Serverless workflow service, these things can be left to the platform to do. The user has returned to a state where they only need to focus on business logic. The diagram on the right shows the process definition. We can see that this implements the effect of the previous event based Saga pattern, and the complexity of the process is greatly simplified.

Serverless technology will undoubtedly assume more responsibility and allow users to build applications faster and better. Using the Serverless architecture can cover many scenarios. Here, we only introduce the architecture of Web site front-end and back-end, microservices, event triggering, service orchestration, and other scenarios. "Less is more empowering reliable platforms (such as cloud vendors) to do things, allowing developers to focus more on their core business values, which is a concept that Serverless has always advocated.".