The way of Knative Serverless: How to realize application hosting without O&M and low cost?

Introduction: Serverless is undoubtedly the hottest cloud-native topic at present, so as business developers or operation and maintenance personnel, how should we view this matter? What is the relationship between cloud native and serverless? Through this sharing, we will unveil these mysterious veils one by one.
Author | Niu Qiulin (Winter Island) Alibaba Cloud Container Platform Technical Expert

Follow the "Alibaba Cloud Native" official account and reply to the keyword "1205" to watch the Knative-Demo demonstration video.

Introduction: Serverless is undoubtedly the hottest cloud-native topic at present, so as business developers or operation and maintenance personnel, how should we view this matter? What is the relationship between cloud native and serverless? Through this sharing, we will unveil these mysterious veils one by one.
Through this article you will learn:

How does Knative make common applications serverless?
Why is Knative a cloud-native application serverless orchestration engine?
Why Knative is composed of Tekton, Eventing and Serving modules, and how these three modules work together.
This article consists of four parts: first, let's take a look at what the core driving force of cloud is, and then look at what cloud native applications look like from this core driving force. Then let's take a look at what value Knative brings to the cloud nativeization of applications. Finally, let's experience these capabilities brought by Knative through a demo.

The core driver of the cloud
Before discussing cloud native, let's think about it first: why enterprises want to go to the cloud, why technicians need to learn cloud-oriented programming thinking, and how we should think about the cloud.

Let's first analyze the core driving force behind these things, and then start from this core driving force to see what the entire cloud native technology stack looks like.

social division of labor

Let's start with a hot pot meal. Although a hot pot meal is very simple, it will involve a lot of things, such as various vegetables, beef and mutton. Come to think of it, all of these things we eat regularly, but which of them have we grown or farmed ourselves? In fact, none of them. We sit in the office every day and go to the market or supermarket to buy these things on the way from get off work. We don’t know and don’t care about the specific production process of these things.

When I was a child, I grew up in the countryside of Inner Mongolia. Everyone knows that Inner Mongolia is very big. Every household in the village has a large garden. In summer, every household grows various vegetables in the garden, such as tomatoes, cucumbers, eggplants, peppers, etc. But in winter, due to the cold weather, there is no fresh vegetables at all. Everyone eats pickles, sauerkraut, or some dried vegetables dried in the autumn. We can find that an area is very susceptible to the influence of seasons. Although all kinds of vegetables can be grown in summer, there will be nothing in winter. But it is different now. Fresh vegetables can be easily bought anywhere in the country. This is actually the result of social division of labor and the result of cooperation between different regions and different roles through the market.

Now because there are professional people doing these things, most of us don't need to worry about how vegetables are grown. And what we engineers do with computers can in turn help those who grow vegetables through other channels.

The division of labor improves efficiency, which is the opening point of Adam Smith, the father of modern economics, in his classic book The Wealth of Nations more than 200 years ago. In fact, the operating mechanism of modern society also confirms this theory; I think it is also the fundamental reason why enterprises embrace cloud computing. Because everyone needs to "contract" some non-business core parts to professionals to complete, those parts that are strongly related to their own business are the core competitiveness of the enterprise.

Application to the cloud

Next, let's take a look at what parts an application is made of.

To provide services, an application must first need computing, storage and network resources to run the process. Of course, these are just running the process. If you want to undertake specific business, you need to rely on services such as databases; if you want to do a distributed architecture, you need to do microservice splitting. At this time, you need cache, registration center, and various message intermediates. piece of service.

The above situations are all part of how to run the program to undertake the business if the program already exists. Another part is how to turn the code into a bootable program, which is the CICD part. From the code to the application startup to the surrounding system support that the application depends on, the rest is related to the daily operation and maintenance:

such as log collection and analysis
such as monitoring and alerting
Although we originally just wanted to write an application to provide services for the business. But these support systems around the application are much higher than the consumption of the application itself. This is actually not the result we expected. Let the business team focus more on the business logic itself, rather than on these surrounding systems. This is what we want to see.

In fact, there are companies of a certain scale, and the internal organizational structure is basically composed of a basic platform team and multiple business teams. The basic platform team is responsible for providing the public capability support required by these applications, and the business team focuses more on business. Just use the capabilities of the underlying platform team directly. This is actually the embodiment of social division of labor in IT organizations. Professional people do professional things, and division of labor improves efficiency.

Now let's review the example of eating hot pot just now.

If time goes back 20 years, back to the winter in the north, we want to eat a hot pot with meat, vegetables, and enoki mushrooms, it is impossible, but now, we can buy these things anytime, anywhere, and all these They are all produced by professionals, and we cannot be self-sufficient with such abundant resources.

The same is true for a company. Although each enterprise has its own basic platform team, it is impossible to provide platform support as rich as the cloud due to scale or capital investment. If there is, it must also be a cloud vendor. Therefore, for the business, it is efficient to build all the peripheral systems related to the application using the initial cloud facilities, and contract these peripheral systems to cloud vendors. I understand that this is the background in which cloud native emerged.

Division of labor to improve efficiency is the fundamental driving force for everyone to use the cloud. The cloud-native concept is gradually formed and perfected in the process of cloud migration of major enterprises. This set of concepts is to coordinate the gradual formation of a unified standard for all participants to migrate to the cloud. This unified standard can well help enterprises migrate to the cloud and help cloud vendors release their cloud capabilities. From the perspective of cloud customers, this unified standard is to avoid cloud vendor lock-in. For example, Kubernetes is a very good unified consensus, because all cloud platforms support Kubernetes.

So what is the value of this standard? Why do cloud vendors and cloud-based enterprises actively participate in the "formulation" of this standard? This is actually a mutually beneficial outcome. Before talking about the role of this standard in detail, let's talk about the difference between the two resource allocation models.

Queue (first come, first served)
In this section, we take medical treatment as an example to illustrate.

To go to the hospital to see a doctor, you need to register in advance. The source of the doctor's number is a first-come, first-served resource allocation method. Especially in big cities such as Beijing, Shanghai and Guangzhou, the number one source of good doctors is even harder to find. If you want to ensure that you must get a doctor's consultation number, you must ensure that you queue up at the hospital earlier than others, and you can get the consultation number first if you queue up in advance. Let's now analyze what the value of the efforts of those who queue up early is worth.

For the parties in the queue: the efforts made by the parties are meaningful to them, and they have obtained the consultation number and have been rewarded;
There is no benefit to the other queuers. Those who come early get the medical number, which sends a signal to other people who are competing for the number source—the earlier they come, the more likely they are to get the number source. This may lead to more people coming to queue earlier, which is a vicious circle;
For doctors, it means nothing. Whoever sees a doctor is the same, and whoever gets this number doesn't make much difference to the doctor. In many cases, patients even ask for a plus sign, but the doctor is actually reluctant, because each additional sign source means that the doctor has to pay a little time to rest. For doctors, more rest time cannot be exchanged for more compensation, because this is a first-come, first-served queuing order, and the price of each number source is the same.
Have you found that the contribution made in the process of queuing is meaningful only to the parties in the queuing, and has no meaning to the doctors and other queuing people, and even brings about vicious competition, resulting in a huge waste of social resources. In the process of queuing, a lot of resources are lost in vain, without bringing any value to the society.

market economy
In this section, we take the purchase of a cloud server ECS as an example.

Assuming that Alibaba Cloud's ECS is currently the most cost-effective, everyone prefers to use Alibaba Cloud's ECS when going to the cloud. If the supply exceeds demand, the price of ECS may increase, and the price increase will lead to more cloud vendors supplying ECS. , eventually causing the price to fall back down. Let's analyze the relationship between who buys ECS and the cloud vendor that provides ECS in the process:

We found that the fact that a large number of customers purchase ECS itself is beneficial and harmless to customers who go to the cloud, because a large amount of demand will lead to more supply from cloud manufacturers, and the price cannot continue to rise. Therefore, the competitors of ECS requirements are not a zero-sum game, but a cooperative relationship. By making the cake bigger together, the entire supply chain will be more stable and cheaper. Just like I buy an iPhone, you also buy an iPhone, but we are not in a competitive relationship, and the more people who buy it, the better the quality of the iPhone will be;
A large number of ECS requirements will promote the maturity of ECS technology. For ECS provider cloud vendors, the more people buy their own services, the better, and there is a mutually reinforcing relationship between all customers and cloud vendors.
The price-based free transaction of the market economy can promote everyone's cooperation very efficiently, and the efforts of any party are valuable to other participants. Compared with the efforts of the people who arrive first in the hospital queue, they only generate value for themselves. In the free transaction method of the market economy, the contribution of each party optimizes the entire system, which is a part of the rational use and distribution of social resources. a very good way.

Does it feel too far away, what does this have to do with cloud computing? We continue to analyze the market economy, and we can see the close relationship with cloud computing.

Let's take a look at this scenario first: If cloud vendor A provides services with high cost performance, but one day cloud vendor B provides services with higher cost performance, will the customer immediately migrate the service to cloud vendor B? The answer is that customers want to migrate, but it is more difficult to migrate. Because the service standards provided by each cloud vendor are different, the process of service migration needs to adapt to a large number of differentiated underlying infrastructures, which brings huge costs to the migration and even offsets the high cost performance provided by cloud vendor B. So this kind of migration is usually rare.

Earlier, we analyzed the resource allocation method of the market economy, which is very beneficial to the optimal allocation of resources in all aspects of society. However, if cloud customers cannot flow between cloud vendors at low cost, it is actually difficult to choose cost-effective cloud vendors. Therefore, from the perspective of effectively allocating social resources, there is an urgent need for a system that allows customers to "flow" between different cloud vendors at low cost, and this is the meaning of cloud native.

If the applications that customers want to host on the cloud are like water, then the price of cloud services is the altitude. Where the altitude is low, the water flows naturally. Infinitely reducing the cost of migration is a very valuable thing for both customers and cloud vendors. Cloud native aims to connect cloud vendors and customers with standardized cloud service provision. This method reduces the cost of cloud migration and cross-cloud migration for customers, allowing customers to always maintain the ability to negotiate prices with cloud vendors; for cloud vendors, because the cost of cross-cloud migration for customers is low, as long as they can provide more cost-effective High cloud services can easily gather a large number of users.

Cloud native is constantly promoting a virtuous circle of the entire system: it not only allows customers to always have the ability to choose, but also allows excellent cloud vendors to quickly serve more customers. If customers' business services can be circulated among different cloud vendors at low cost like water, then the services provided by cloud vendors can be circulated among customers like currency. It's a win-win situation.

cloud native applications
After talking about the concept of cloud native, let's take a look at cloud native applications and how to view traditional application architecture in the context of cloud native?

cloud infrastructure

Whether it is an application on the cloud or an application under the cloud, the core elements of dependence have not changed, but the form of provision of these core elements has changed.

As shown in the figure above, there are a total of 7 core elements. Among these seven elements, the daily operation and maintenance is not strongly dependent. Although it has a great impact on the stability of the business, it is not the core link for the business to run. Blocks are all core links. So let's take a look at the position of the elements of these core links under the cloud-native architecture. Then analyze the basic paradigm of cloud-native applications.

Cloud native technology stack

Let's first look at the middleware on the far right, which contains database, Redis, and message middleware components. This part is actually called directly in the application code, and all the capabilities included here have standard protocols. For example, whether we use SQL Server or MySQL, we can use SQL specifications to operate in our program. In fact, this part has long been standardized.

As shown in the figure, the three core elements of computing, storage and networking have been unified by the Kubernetes layer. Many cloud services have realized serverless computing, storage and network resources, such as Alibaba Cloud's ECI and ASK (Aliyun Serverless Kubernetes). Then there are still two pieces of CICD and application hosting that are not standardized. This is what needs to be standardized at the application orchestration layer. In fact, serverless is not only serverless, but also the orchestration of the application itself, which is also the value of the application orchestration layer.

Cloud-native application serverless orchestration
Serverless Kubernetes already provides serverless support for Pods, but there are still many things that the application layer needs to do to make good use of this capability.

elasticity:
shrink to zero
burst traffic
grayscale release
How to Realize Grayscale Publishing
The relationship between grayscale publishing and elasticity

Traffic management

How to dynamically adjust the traffic ratio between v1 and v2 when grayscale is released
How traffic management and elasticity are related
How to cooperate with elasticity when there is burst traffic so that burst requests are not lost
We found that although basic resources can be applied dynamically, if the application is to achieve real-time elasticity, on-demand allocation, and pay-as-you-go capabilities, a layer of orchestration system is required to complete the adaptation of the application and Kubernetes. This adaptation is not only responsible for elasticity, but also has the ability to manage traffic and grayscale publishing at the same time.