What is the Serverless Architecture

According to 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 also cause some controversy.

  1. With the development of demand and technology, some Serverless computing services in other forms than FaaS have emerged in the industry, such as Google CloudRun. Aliyun has launched Serverless application engine service oriented to applications. These services also provide flexible scalability and pay-per-use charging mode. With the form of Serverless service, it can be said to further expand the camp of Serverless computing.
  2. In order to solve the impact of cold start, FaaS such as Ali Cloud function calculation and AWS Lambda have also launched reservation functions.
  3. Other Serverful back-end services have also launched Serverless products, such as AWS Serverless Aurora and Ali Cloud Serverless HBase service.

Therefore, the boundaries of Serverless are somewhat blurred, but cloud services are evolving in the Direction of Serverless. How can an obscure thing guide us to solve a business problem? Serverless has a fundamental philosophy that maximizes user focus on business logic. Other features such as server indifference, automatic resiliency, pay-as-you-go, and so on serve this purpose. Serverless’s philosophy allows us to better solve the real problems we need to solve with limited resources, and we can do more in business because we do fewer things and let others do them.

Noted Serverless practitioner Ben Kehoe describes the Serverless native mind this way:

  1. What is my business?Copy the code
  2. Will this make my business stand out?Copy the code
  3. If not, why should I do it instead of letting someone else solve the problem?Copy the code
  4. There is no need to solve technical problems before solving business problems.Copy the code

When practicing the Serverless architecture, the most important mental focus is not on which popular services and technologies to choose and which technical challenges to solve, but on keeping the business logic in mind, which makes it easier to choose the right technologies and services and figure out how to design the application architecture.Serverless architecture has computing, data storage and message communication technologies. We can measure the advantages and disadvantages of the architecture from the perspectives of operation and maintenance, security, reliability, scalability and cost. This article introduces some common business scenarios and explores how to use the Serverless architecture to support them. To make this discussion less abstract, some concrete technical implementations are presented below as references, but the ideas of these architectures are general and can be implemented with other similar products.

Two, static site

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

1. Its pages are static display information.

2. Its pages are not updated frequently.

3, uncertain traffic.

Architecture evolution

The transition from cloud down to cloud, and from managed servers to Serverless (i.e., Serverless), as shown in the figure, has brought huge benefits to developers. For example, the first two schemes need budget, expansion, implementation of high availability, self-monitoring, etc., while the business logic of the Developers of China Yellow Pages just wants to show information and let the world know about China. This is in line with the Serverless native mind, which allows developers to maximize their focus on business logic.

  1. Buy a server in the IDC room hosting, running the site.
  2. Load balancing services and multiple servers were purchased to address high availability.
  3. Using static site mode, the webmaster directly supports the site by object storage service (such as OSS), and uses CDN as cache.

In the traditional architecture mode, the website is deployed on the server, and then the server is hosted in the computer room, and then the user or client uses a computer browser to access the website. The drawback of serverful service is that if the site has problems and the server is no longer available, in order to maintain the high availability of the site, a load balancer and two reserve servers are mounted, which is the architecture of serverful service. Serverless architecture for developers, it just needs to publish its static pages directly to the object store, which itself is a Serverless file storage service that can store static pages, images, audio, video, and so on, with unlimited scalability.

The Serverless architecture has advantages that no other solution can match:

• There is no need to manage servers, such as OS security patch upgrades, failure upgrades, high availability, these cloud services (OSS, CDN) all help. • There is no need to estimate resources and consider future extensions because OSS is inherently elastic and using CDN allows for lower latency, lower cost, and higher availability. • Pay for the resources actually used, including storage fees and request fees, not request fees when there is no request. • Security: Such a system can’t even see the server, doesn’t need to log in over SSH, and leaves DDoS attacks to the cloud.Static is a good thing, and caching is a common technique in software development, although the joke is that computer technology has only two hardest things to do, invalidating caching and naming. But it also shows the importance of caching, which, when used properly, can greatly improve system performance.

For example, when many Android apps need to be released to channels such as Xiaomi App Store and Huawei App Store, developers prefer to pack a parent package and store it in the object store, rather than doing repeated work such as channel package maintenance. For the user, it is only necessary to maintain a mother package and then maintain a simple dynamic calculation. In fact, CDN can not only back to the object storage, but also back to the dynamic backend, such as API gateway, function calculation, load balancer, etc. Not only CDN can use this type of cache, but also can use Redis, as well as in-process cache.

3. Monomer and microservice

Why singleton and microservices? Because static sites may only address the need to present information, but as business requirements become more complex, dynamic sites become necessary. Such as:

  • It is unrealistic to use static page to manage commodity information in Taobao’s commodity page. There are a large number of goods, and the information of goods on and off shelves is updated frequently, and the page of goods is complicated.
  • Netease, Sina portal, real-time news updates, comments, likes, forwarding, etc

Static pages and sites are suitable for scenarios with less content and low update frequency. On the contrary, for example, a commodity detail page of Taobao is shown in the picture. It is not realistic to use the pages of static sites for the following reasons:

1. There are tons of goods.

2. Frequent updates

3. Dynamic information comes from a wide range of sources, such as basic information, price, freight, sales volume, inventory, comments, etc., which change in real time.

The Serverless native mind mentioned above helps us focus on the business. Such as:

  1. Do you need to buy your own server to install databases, implement high availability, manage backups, upgrade versions, etc., or do you need to hand these over to a hosted service such as RDS? Whether Serverless database services, such as table storage and Serverless HBase, can be flexibly expanded or reduced based on usage.
  2. Do individual applications need to purchase their own servers to run, or can they be handed over to managed services such as functional computing and Serverless application engines?
  3. Whether functions can be used to implement lightweight microservices depends on the load balancing, automatic scaling, pay-on-demand, system monitoring capabilities provided by function computing.
  4. Whether microservice applications based on Spring Cloud, Dubbo, HSF and others need to purchase their own servers to deploy applications, manage service discovery, load balancing, elastic scaling, fusing, system monitoring, etc., or they can be entrusted to Serverless application engine services.

The architecture evolution has gone through the process from Serverful single architecture to Serverful microservice architecture and then to Serverless microservice architecture. With the development of business and the increasing size of the organization, it is generally necessary to split the logic of a single application into multiple execution units. For example, the comment information, sales information and distribution information on the product page can all correspond to a single micro-service. The architecture on the right introduces API gateways, functional computing, or SAE to implement the computing layer, exchanging a lot of work for cloud services. The benefits of the Microservice architecture Serverless are a high degree of autonomy for each cell, loose coupling between cells, and ease of development (such as using different technologies), deployment, and scaling.

However, this architecture also introduces some problems of distributed system, such as load balancing of communication between services, failure handling, distributed transactions and so on. Organizations at different stages and sizes can choose the right approach to solve their primary business problems.

In fact, although there is a lot of information on the product page here, 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 product aggregation service, multiple internal microservices are uniformly presented externally. 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 from different clients. In reality, such requirements are common, 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?

Backend for fronted. This is favored by front-end developers. Serverless technology has made this architecture popular because front-end engineers can write BFF directly from a business perspective. Without managing server-related headaches for front-end engineers.

4. Event triggering

This section illustrates how the Serverless architecture solves the problem by introducing a specific business scenario: the event-triggering class scenario. Dynamic page generation mentioned is synchronization request is completed, there is a common scene, which request processing usually takes a long time or more resources, such as user reviews of the images and video content management, involving how to upload pictures and processing images (thumbnail, watermark, audit, etc.), video processing played so as to adapt to different client demand, etc. For example, the business scene in this figure is a buyer’s show. When the buyer completes the transaction and wants to post comments on pictures or videos, after the buyer completes the transaction, the back-end service will watermark the picture, zoom in and verify it. Video also needs to be converted and reviewed in multiple formats, because it needs to be adapted to different terminals.

This kind of business characteristic is actually cpu-intensive and takes a long time to execute each task, so we may have some technical architecture evolution for this kind of business.

For example, Douyin, as we are familiar with, is a business scenario where users upload videos. In the tiktok backend, videos need to be uniformly processed, such as watermarking, transcoding to different bit rates or length and width resolution to suit different mobile phones. This business settlement is CPU intensive. There’s also a lot of bandwidth pressure. You just keep adding bandwidth, you keep adding machines, and as a result, the cost of operation and maintenance keeps going up; The second problem is that there are peaks and troughs, such as eight o ‘clock in the morning subway time lunch hour and 1 clock or at 8 o ‘clock, traffic may be very high, if your business needs 1000 machines, but in the morning, the 1000 machines may be used, so that it can cause some waste of resources, You also have to deal with operations and maintenance monitoring, flexibility expansion, capacity expansion and so on.Extending the evolution of the architecture further, event triggering is a very important feature of FaaS. The Pub-Sub event-driven model is not a new concept, but before Serverless, event producers, consumers, and hubs in between were the responsibility of the user. Like the second architecture in the previous architectural evolution. Serverless lets producers send events, and the value of maintaining connection hubs is taken out of user responsibility and focused on consumer logic. The function computing service also integrates with other cloud service Event sources, making it easier to use common modes such as Pub/Sub, Event stream mode, Event Sourcing mode in your business.

5. Service arrangement

The previous product page is complex, but all operations are read operations, and the aggregate service API is stateless and synchronous. Let’s 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 on Ele. me, it involves an order process. This order process is much more complex than a product 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 reserves are enough, then the inventory is reduced by 1, and then the wechat or Alipay service is connected to pay the deduction. After the order comes down, logistics should be arranged for distribution, and logistics details should be checked and SMS notification should be carried out.And in this code logic you’re going to write all kinds of retry logic. If it fails, we roll back what was done, and more if the user cancels the order. For example, the money should be returned to the user. This scenario is very complicated. We can look at how this process is developed. For example, after the user places an order in the first step, it actually goes to the order service, which generates the order number; And then it comes down to who the buyer is, who the seller is. The second step is to send the message to the message bus to which the other services (shipping service, inventory service, payment service) subscribe.

On the other hand, its observability and descriptiveness are not good, and on the second hand, its reusability is poor. If the developer becomes a service for another process, then the whole set has to be rewritten.In this Serverless architecture, individual services are directly independent and do not transmit information through events. Instead, individual business services are scheduled by a centralized coordinator service, and business logic and state are maintained by the centralized coordinator. After placing an order from the gateway layer, a function execution is triggered for the function calculation, and the logic of the function execution triggers the execution of a workflow. For example, the figure on the right is actually written by the user, and this process is workflow.

For example, the first step to place an order, the second step to pay, pay successful will be how, how should fail to pay. The entire order is the execution of the process on the right. And each execution of the process can be traced. You can think of it as being an organizer and then calling other cloud services.

So in this architecture, we can see that for developers, there is no need to do message bus, do logical processing, maintain data consistency and so on. He just needs to focus on his business logic, write the services that each process calls, and write the choreographed processes.

  • You write a lot of code to implement things like choreography logic, state maintenance, and error retries that are hard to reuse by other applications.
  • Maintain the infrastructure that runs the choreographer application to ensure high availability and scalability of the choreographer application.
  • Consider state persistence to support multi-step long-running processes and ensure transactional processes.

If you rely directly on services on the cloud, such as Ali Cloud’s Serverless workflow service, these things can be handed over to the platform. Users are back to focusing only on business logic. On the right is the process definition, and we can see that this implements the effect of the previous event-based Saga pattern, with the complexity of the process greatly reduced.

Serverless technology will undoubtedly take on more responsibility for allowing users to build applications faster and better. Serverless architecture can cover a lot of scenarios. Here we just introduce the architecture of Web site front-end and back-end, microservices, event triggering, service orchestration and other scenarios. Less is more To entrust the work to reliable platforms (such as cloud vendors), so that developers can focus more on their core business value, is the concept that Serverless has been advocating.

​

​