Shulou(Shulou.com)06/01 Report--

This article will explain in detail how to deeply interpret the Serverless architecture and platform choice. The content of the article is of high quality, so the editor will share it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

At the Serverless product level, from the earliest AWS Lambda, to Azure Functions, Goolge Functions, Google CloudRun, and then to domestic Aliyun Serverless Kubernetes, Serverless application engine, functional computing, etc., computing-oriented Serverless cloud infrastructure is becoming more and more abundant.

The emergence of new concepts and new products does not appear out of thin air, they are born to solve the current problems. As practitioners' understanding of the problem domain becomes more and more clear and profound, the method of dealing with the problem will be iterated step by step, and solutions closer to the nature of the problem will emerge. If you do not understand the solution from the problem domain, it is easy to fall into two extremes, namely, "it can solve all problems" and "it is too advanced to understand".

Serverless from the Perspective of Daily iterations

Figure 1

The figure above is a commonly used project iteration model whose goal is to meet customer needs. In this model, the project team meets the customer's needs through passive iteration, and gradually deeply understands the nature of the customer's needs, and adopts a better solution with the customer through active iteration or solves the problem from the root. Each demand feedback will deepen the understanding of customer needs and provide services that better meet the needs. Each bug feedback will deepen the understanding of the solution and provide a more stable service.

After the model is launched, the day-to-day core issues focus on how to accelerate iterations.

If you want to solve the problem of iterative acceleration, you need to understand what are the constraints. The following is the development model seen from a development perspective:

Figure 2

Although different development languages and architectures will be used in practical applications, there are common problems at each stage, such as:

Figure 3

In addition to solving the above common problems, we also need to provide standardized solutions to reduce developers' learning and use costs, and shorten the time from idea to launch.

If you analyze the time spent at different stages of the above process, you will find that throughout the life cycle of the project:

Deployment & operation and maintenance will take up much more time and energy than development and testing.

The time and effort of general logic will be close to or even exceed that of business logic.

In order to speed up the iteration, you need to solve the time-consuming and energy-intensive parts in turn, as shown in figure 4:

Figure 4

From left to right, reduce the cost of "deployment-operation and maintenance" by delegating different levels of operation and maintenance work. After reducing the cost of operation and maintenance, the cost is reduced at the level of "general logic". The two combine to focus more deeply on the business in the iterative process. This process is also a process from Cloud Hosting to Cloud Native, fully enjoying the technology dividends brought by cloud natives.

Because the software design architecture and deployment architecture are highly coupled with the environment at that time, in the face of new concepts, services and products, the technology used in the iterative process of stock application needs to be adjusted accordingly, that is, the way of development and deployment needs to be modified. When developing and deploying new applications, the application of new ideas has a certain learning and practical cost.

Therefore, the above process can not be achieved overnight, it is necessary to select matching services and products according to the current pain point priority of the business, and carry out technical pre-research in advance according to future planning, and select suitable services and products in different stages.

Introduction to Serverless

Wikipedia has a more complete definition of Serverless:

Serverless computing is a cloud computing execution model in which the cloud provider runs the server, and dynamically manages the allocation of machine resources. Pricing is based on the actual amount of resources consumed by an application, rather than on pre-purchased units of capacity.

Serverless computing is a cloud computing execution model in which cloud vendors provide servers on which programs run and dynamically manage the allocation of machine resources. Cloud vendors set prices based on the actual amount of resources consumed by the application, rather than the capacity purchased in advance by the user.

Under this calculation model, it will bring the following benefits to users:

Serverless computing can simplify the process of deploying code into production. Scaling, capacity planning and maintenance operations may be hidden from the developer or operator. Serverless code can be used in conjunction with code deployed in traditional styles, such as microservices. Alternatively, applications can be written to be purely serverless and use no provisioned servers at all.

Serverless computing can simplify the process of deploying code to production environment, and scale-up, capacity planning and operation and maintenance operations can be transparent to developers. Serverless code can be used in conjunction with code deployed in traditional ways, such as microservices, or developers can write applications in a serverless computing mode without having to configure the server in advance.

The concept is essentially an abstraction of the problem domain and a summary of the characteristics of the problem domain. By understanding the concept through features, we can avoid focusing on the text description rather than the value of the concept itself.

From the user's point of view, we can abstract the following characteristics of Serverless:

Free operation and maintenance (server operation and maintenance, capacity management, auto scaling, etc.)

Pay by the amount of resources used

In companies of a certain size, if there is a strict distinction between the roles of development and operation and maintenance, this form of computing already exists and is not a new thing. However, the current technology trend is to reduce the cost of the business on the technology side by taking advantage of the scale and technology dividend advantages of the cloud, and to feed the business back through the technology dividend. Therefore, the discussion of Serverless in the industry is focused on the Serverless capabilities of services and products on the cloud.

Serverless development model

Martin Fowler's article fully expounds the Serverless development model from an architectural point of view. Here is a simple summary. The core revolves around three points:

Event-driven development model

Automatic elastic stretching

OpenAPI

Serverless development adopts Event-driven model, and designs the architecture around the production and response of Event such as HTTP/HTTPS request, time, message and so on. In this model, the production and processing process of Event is the core, and the whole service process is driven by Event, and the attention is focused on the whole processing process. The deeper the understanding of the business, the more the Event type and business will match, and the more effective the interaction between technology and business will be.

The Event-driven model changes the concept of service residency from required to optional, and can better cope with changes in the number of business requests, such as automatic auto scaling. At the same time, the service is not resident, which can reduce the required resource cost and maintenance cost, and accelerate the project iteration.

Through the two pictures of the article, we can more intuitively understand:

Figure 5

Figure 5 is the current common development model. The Click Processor service is a resident service that responds to all click requests from users. In a production environment, multiple instances are usually deployed, and resident is a key feature. Daily operation and maintenance focus on ensuring the stability of resident services.

Figure 6

Figure 6 shows the Event-driven development model, focusing on the generation and response of Event, and whether the response service is resident or not is optional.

The conceptual difference between Serverless and PaaS (Platform as a Service) and CaaS (Container as a Service) focuses on whether automatic elastic scaling is the core feature of the concept at the beginning of its birth.

Combined with the development model of Event-driven, automatic auto scaling in Serverless scenarios needs to be more transparent to developers, and the focus of developers' development process on processing capacity has changed from static to dynamic, so as to better deal with the uncertainty of business requests after launch.

On the development side, the delivery can be mirrored or packaged at the language level (such as war/jar in Java), with the platform responsible for runtime-related work. We can further adopt the concept of FaaS, rely on the platform or standardized FaaS solution, only provide business logic functions, and the platform is responsible for runtime matters such as request entry, request invocation and automatic auto scaling.

No matter which delivery method, you can use the concept of BaaS on the cloud to implement part of the logic through the cloud platform or third-party OpenAPI, such as rights management, middleware management, etc., and pay more attention to the business level in the development process.

Serverless service model

The Serverless service model focuses on cloud vendors' support for Serverless computing forms. The main differences between different services and products are mainly focused on the understanding and satisfaction of Serverless features:

Free operation and maintenance (server operation and maintenance, capacity management, auto scaling, etc.)

Pay by the amount of resources used

In the dimension of free operation and maintenance, the most basic thing is to eliminate the cost of server operation and maintenance, and developers can apply for resources according to quantity. At the conventional operation and maintenance level, such as capacity management, auto scaling, traffic management, log / monitoring / alarm, different services and products will be satisfied in an appropriate way according to their own positioning and target customer characteristics.

In terms of billing patterns, on the one hand, cloud manufacturers will determine the charging dimensions according to their own positioning, such as resources, quantity of requests, etc., on the other hand, they will also determine the granularity of charging according to the current technical capabilities.

According to the above analysis, different Serverless service models of cloud vendors are not static, but will continue to iterate along with product positioning, target customer characteristics, and technical capabilities, and grow with customers.

The Serverless service model needs to meet the actual needs. Going back to figure 4, the cloud vendor's Serverless service model can be divided into the following categories:

Resource instance platform

Dispatching platform

Application management platform

Business logic management platform

To sum up, that is:

Figure 7

Industry Serverless products

At present, cloud manufacturers at home and abroad provide Serverless products with different dimensions. Here is a simple summary:

Figure 8

Resource instance platform

Foreign AWS Fargate / Azure ACI and domestic Aliyun ECI / Huawei CCI have great influence and provide container group services to users. The container group as a whole provides a concept similar to that of Pod in Kubernetes. Users can create container groups directly through OpenAPI calls, without having to purchase and configure the server before deploying the service, and delegate the capacity management OPS work related to resources. Users can use the resource instance platform as a resource pool with sufficient capacity, apply for fine-grained resources at the container group level, and manage the capacity at the application level with dynamic capacity expansion.

In general, in a production environment, users usually do not directly use such resource management services, but with the help of application orchestration services to make such services transparent and focus on the application orchestration dimension.

Dispatching platform

Kubernetes is the de facto standard for container scheduling. Foreign AWS EKS and domestic Aliyun Serverless Kubernetes host Kubernetes Master components on the one hand, and provide Kubernetes Node layer services with the help of resource management services, such as VirtualKubelet + AWS Fargate or VirtualKubelet + Aliyun ECI.

For users who expect to use Kubernetes capabilities directly, and want low-cost operation and maintenance Kubernetes, and do not keep the resource pool, this kind of products are more suitable for the demand.

Application management platform

Foreign Google GAE / CloudRun and domestic Aliyun Serverless application engine further turn OPS into services, such as release management (packaging / grayscale / batch / rollback / version control, etc.), log / monitoring / alarm, traffic management, auto scaling, etc., so that users can further focus on business needs and low-cost operation and maintenance.

For users who expect zero-cost transformation of stock applications, low learning costs, and minimize operation and maintenance work, this kind of platform has a high matching degree with the demand. However, due to the operation and maintenance work at the application management level, there is no standardized plan in the industry, and there will be personalized requirements for different projects, so it is necessary to strengthen communication in the process of adopting such products, constantly feedback to the platform, and run-in Serverless platform and its own business through co-construction.

Business logic management platform

Foreign AWS Lambda / Azure Functions / Google Functions, domestic Ali Cloud function Computing / Tencent Cloud function / Huawei function workflow, etc., further make the general logic in the development process transparent on the basis of application management, and users only need to care about the implementation of business logic. This process can be compared to the unit test writing process in the development process, the input and output are universal, and there are differences only in the processing logic. This kind of Serverless product is also the most discussed form in the industry, which represents the industry's abstraction of the ideal development process, which can further speed up the iterative process and shorten the time from idea to launch. This kind of Serverless products are more closely integrated with other types of products of the cloud platform, and use the services of the cloud platform to achieve general logic in the form of BaaS, such as storage, caching, etc., which has a certain implicit demand for the product richness of the cloud platform.

The processing process is less dependent on external or partial computing scenarios, such as front-end, multimedia processing, etc., using this kind of Serverless products is relatively low cost and easy to use. With the increasing abstraction of services and components, more and more business scenarios will be applicable, and users' operation and maintenance work will be more transparent. At the same time, they can directly enjoy the best practices of the industry in the development process. The stability, performance, throughput and other aspects of the service can be maximized with the help of the platform.

Type selection

To sum up, when selecting Serverless products, users need to sort out the stages and pain points of the current business technology, determine the demand for cloud solutions, and then select services and cloud products that are suitable for the current stage according to the product form of cloud vendors.

The key point of the correspondence is to understand whether cloud product positioning can meet business needs for a long time, such as:

Does the current stage of business technology match the positioning of cloud products?

Whether the rapid iteration of the business will be limited by the development of the cloud product itself

What is the stability of cloud products?

Can cloud products continue to bring technology dividends to the business?

At the same time, we also need to know whether cloud products can be accompanied by business development, focusing on the needs of the business for technology, which are the limitations caused by the positioning of cloud products, and which are the limitations brought by the current technical implementation of cloud products.

If the limitations of cloud product positioning, then you need to consider the use of cloud products that better match the positioning of business needs. If the current technology is limited, then there is an opportunity to grow together with cloud products and give timely feedback to cloud products, so that cloud products can better meet their business needs.

In addition, at the business level, we also need to pay attention to the richness of cloud vendors' own service types. The richer and larger the cloud manufacturers' own services, the more economies of scale they will produce, which in turn will bring more abundant technical dividends and cost advantages to the business.

Fortunately, cloud products usually have a wealth of documentation and a corresponding user base, so that they can face product managers and R & D directly, feedback their needs in a timely manner, and cooperate with the concept of co-building.

Serverless is essentially a problem domain, which abstracts the problems that are not the core of the business but affect the business iteration in the R & D process, and puts forward the corresponding solutions. This concept does not come into being suddenly, and people have more or less applied its concept to their daily work, but with the tide of cloud computing, Serverless services and products on the cloud are more systematic and competitive, and can continue to provide services that better meet business needs in the face of problem areas based on scale advantages and rich product lines.

The concept of Serverless is not only flourishing in the centralized cloud, but also gradually developing at the edge, which makes the operation of the service more extensive, better meet the business's own customers, and provide lower latency and stable services.

This article attempts to start from the daily process of the project and development, to help readers understand the concept of Serverless from the perspective of daily practice, and choose appropriate Serverless services and products according to their stage. At the same time, the author is responsible for the underlying R & D work in Aliyun Serverless application engine, trying to transfer the concept of co-building between cloud products and users from the internal perspective of cloud products, so as to better deliver and create value through collaboration.

On how to deeply interpret the Serverless architecture and platform choices to share here, I hope that the above content can be of some help to you, can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.