CNCF TOC Committee Member Zhang Lei: What has the evolving cloud native brought us?

[[412417]]

What is cloud native?

Even though the term “cloud native” has been around for a while, many people still have this question: What exactly is cloud native? Or what is the exact definition of cloud native?

In fact, after we come into contact with many cloud-native open source technologies and products, we gradually discover a phenomenon - cloud-native is not actually a very definite object in essence. In other words, there is actually no specific definition of cloud-native, it refers to a constantly evolving process. Rather than talking about the essence of cloud-native, we should understand it as a set of visions.

So what is the content of this vision?

In the future cloud era, our software or applications are naturally born and grown on the cloud. The reason for this phenomenon or fact is that cloud computing can help these software reduce costs and improve efficiency to the greatest extent, and release the maximum business value of the software itself. This is what cloud native really wants to do, so it is not a specific technology, nor a specific method, nor a specific scientific research project.

Evolving Cloud Native

The following figure can intuitively explain how the overall form of cloud native evolves and develops.

Cloud native places great emphasis on utilizing the characteristics of the cloud, so its core methodology and core concepts are all about how to make our software and applications utilize the characteristics of the cloud. So what are the characteristics of the cloud? For example, the cloud is infinitely elastic, cloud resources can be delivered quickly, and the cloud usage method can be paid on a pay-as-you-go basis. These are the essential characteristics of the cloud.

Based on these cloud characteristics, cloud native has a set of most basic methodologies and concepts. For example, you may have heard of immutable infrastructure. When my application is deployed on the cloud, assuming that the application carrier is immutable, I can delete or replace it at any time, so it will be very easy to update my application. If you want to upgrade the application, you can directly delete the old one and launch the new one, instead of dynamically changing a certain configuration in the application or even dynamically changing the code to achieve it. Therefore, immutable infrastructure is a very typical methodology based on the rapid resource delivery capabilities of the cloud.

For example, cloud native emphasizes high automation, self-operation and maintenance, and even self-healing. In fact, it also hopes that the software itself can better utilize the characteristics of the cloud. Because the cloud is very powerful and can provide a variety of operation and maintenance capabilities, when developing applications or software, you should consider that the cloud can actually provide many capabilities to the application layer, rather than developing the application first and then thinking about how to use the cloud's capabilities for operation and maintenance. This will not build cloud native applications.

For example, cloud-native applications do not matter what language or framework they are written in. This is also an obvious feature. Because the cloud itself is an infrastructure capability, it should not and will not be locked in to a certain language or framework. It is also hoped that all software in the world can use the capabilities of the cloud, rather than saying that the cloud can only serve a certain language.

These are some very important concepts proposed by cloud native in the context of cloud. These concepts themselves will be mapped into a series of systems, or architectural ideas, in our technical research. For example, the immutable infrastructure mentioned earlier can delete an old instance of an application and replace it with a new instance. How to implement such a method? It depends on container technology. Container technology essentially provides container images. A container image is a self-contained operating environment for an application, including the application itself. This image version can be replaced at any time and a new version can be launched. This actually means that containers are a very good implementation of immutable infrastructure.

Does this mean that there will be a technology in the future that can better implement immutable infrastructure? This is very likely, and this technology is of course cloud native. When there may be a new technology in the future to implement immutable infrastructure, or to better implement immutable infrastructure, then such a technology must also belong to the core category of cloud native. Similarly, the Sidecar architecture that we emphasize today in cloud native is to connect the middleware capabilities to the business container through a method called Sidecar container, rather than customizing the business itself and integrating the middleware to solve the problem. This is actually an architecture proposed by the set of methodologies that we emphasize that are language-independent and framework-independent. The characteristic of this architecture is that the middleware capabilities no longer need to be embedded in the business code itself in the form of language or framework, so Sidecar plus container can implement such a set of methods.

This is a series of technologies and architectures that are constantly evolving behind the cloud-native methodology, and these technologies and architectures are often used as open source technology projects in the cloud-native ecosystem. For example, the containers mentioned above will have projects on Docker, and the ideas of Sidecar and self-operation and maintenance we mentioned will eventually be implemented by Kubernetes.

Another example is the recently popular Service Mesh, which essentially helps you build middleware capabilities, but it does so through a language-independent way such as Sidecar. Another example is the future or already popular eBPF and WASM, which are actually practicing a certain idea and architecture behind the cloud native system, and using open source to meet the user's usage scenarios. It is precisely because of this series of open source projects that we can say that when my users get such open source projects and such technologies, they can truly practice the cloud native concept, thereby achieving the essential effects brought by the two clouds we mentioned earlier:

The first is to improve efficiency, such as R&D efficiency, delivery efficiency, and operational efficiency. For example, if my application itself implements the concept of immutable infrastructure through containers, then its delivery can be very simple. I only need to make an image, and after delivering the image, it can run everywhere. For example, our operation and maintenance, when your software itself has achieved self-operation and maintenance, then its operation and maintenance difficulty and cost must be reduced, so we can definitely use the power of the cloud to improve efficiency.

The second is to reduce costs, which includes resource costs and labor costs. For example, through projects such as Kubernetes or containers, my application can better and more integrate cloud services, and reduce operation and maintenance costs and labor investment through cloud services. These are obvious cost reductions. For example, my application has been put on the cloud through cloud native, and through the cloud native architecture, it can quickly deliver and update resources, making the resource cost of the entire application very low. This is also a very good embodiment and practice of using cloud native technology to allow applications to better use the essential capabilities of the cloud.

In general, you will find that this set of cloud-native methods is actually a very complete closed loop. First, you keep looking and exploring how to use the characteristics of the cloud to help users improve efficiency and reduce costs. Then, summarize this series of methods or ideas into cloud-native concepts and methodologies, and then implement them through a series of corresponding architectures and corresponding open source projects. Finally, allow users to use these technologies, thereby achieving the essential purpose of releasing the dividends of cloud computing.

So there is no specific definition of cloud native. It is actually a combination of a constantly self-evolving theoretical system and best practices.

Today’s Cloud Native

Today's cloud native may be built around containers and Kubernetes, and such projects are actually helping us practice many of the essential ideas behind cloud native, including immutable infrastructure and automation. Today, Kubernetes is considered a universal control plane in the cloud era, and some people call it an operating system, which means that all your operations can be completed uniformly on the cloud with the help of Kubernetes.

1. Androidization of Kubernetes Project

The role of the Kubernetes project may become more and more like Android. For example, today's Kubernetes is actually becoming ubiquitous. There is Kubernetes in every place and every cloud layer. It is even very normal to deploy it on end users or in edge environments, just like Android. There is also an Android in our cars, in our TVs, and even in our air conditioners.

Operator is a core concept in Kubernetes. It means that any of my applications and the capabilities it needs can be defined as a Kubernetes API object. Through a mechanism called Controller, you can use the cloud capabilities and connect to various infrastructures. A direct result of this Operatorization is that my application itself is highly automated, including self-healing, robustness, reliability, and operational certainty, which can all be solved by Kubernetes today. My users or the owners of my applications no longer need to worry about these issues.

This is another trend we see today in the context of K8s Androidization, that is, the capabilities required by my application and business will continue to evolve in the direction of automation. This is also in line with the concept of cloud native, because the stronger your application automation and self-healing capabilities are, the more you can connect with the cloud, the lower the cost and time required for manual recording, and more importantly, connect my automation capabilities with the cloud, so that the cloud can help me solve all problems.

3. Application middleware capabilities are further “sunk”

Another trend is that the middleware capabilities required by our applications are sinking. In other words, the previous centralized middleware has actually evolved into a microservice architecture in the past few years.

Microservice architecture essentially disassembles the centralized middleware and puts it in the business code, and you need to import it to use it. Generally speaking, a heavier client or library will be provided for you to use. This is a typical way to use middleware in our microservice era. But today, with the increasing popularity of cloud native, is there a mechanism like Sidecar?

Today, middleware is actually used in large quantities through the Sidecar method, so my application itself does not need to introduce a library or a specific framework to do many things, and I don't even need to be aware of it. For example, if I want to split traffic today, I don't need to introduce such a library in the application to do it, but leave it completely to my infrastructure and the cloud.

The interaction between the application and the cloud is carried out through a bypass container called Sidecar, which proxies the inbound and outbound traffic required by the application itself. Therefore, the cloud can easily adjust and split the traffic through such a proxy. This is the very simple principle of Service Mesh.

Today, middleware capabilities are continuously sinking in this way, which will bring a very obvious trend, that is, middleware is no longer related to the business, no longer related to the programming language, and no longer needs to rely on any framework. Its implementation will be very closely integrated with the K8s containerization system. In addition, I will rely more on Sidecar, so the corresponding requirements for Sidecar management capabilities are also gradually increasing. We can summarize it as the further sinking of application middleware capabilities.

An endless stream of cloud-native services

In addition, with the continuous development of the entire cloud-native system, we will see that cloud services are moving closer to the cloud-native ecosystem in large quantities and frequently, and even bringing some revolutionary impacts.

For example, today's Alibaba Cloud cloud-native database is actually based on the core ideas and concepts mentioned in cloud native, such as infinite elasticity and high scalability. It proposes a new database architecture that makes the database itself very easy to expand and can cope with extremely high and extremely demanding traffic and massive data processing needs, meeting the database usage requirements of today's modern Internet applications.

Another example is Alibaba Cloud infrastructure, which can bring us extreme resource utilization efficiency, reduce the performance loss of many layers of virtualization, make the container itself elastic, and very easy to operate, deploy and manage. In addition, through secure containers and stronger security boundaries, we can ensure the isolation between containers, so that the isolation is sufficient. It can bring extreme physical-level network storage and computing performance to containers, which is very important and is also a very typical example of our application using cloud computing services through the concept of cloud native.

Another example is Amazon Web Services, which allows our chips to adapt to containerized applications more easily or directly. Because a container may only have a very independent or very modular process running, I can use the core of the chip to adapt to such a business, making the capabilities of my infrastructure stronger and more powerful, while ensuring that there is very little interference between cores, which is more suitable for the use of containerized microservice applications.

For example, Amazon Web Services recently launched a cloud-native application deployment engine that can deploy any cloud service or container service in the same way as we do. This is a very typical product that can help us use cloud capabilities to improve the efficiency of application management, delivery and operation.

So whether we are looking at these products or so-called open source projects, when we want to think about whether our cloud product is so-called cloud native or whether it is a cloud native technology, it is actually very simple. We just need to judge whether it can help our applications maximize the use of cloud computing to reduce costs and improve efficiency, and whether it can release the greatest business value in this way. This is a very core standard for judging whether a technology or a product is positioned as cloud native, rather than whether the product is a container or not.

Alibaba Cloud Native

Back to the example of Alibaba itself, we can see that today Alibaba's infrastructure has completed what we call cloud native based on a whole set of technologies such as Kubernetes containers. And when we really look back at this matter, we will find that cloud native itself has brought some very important changes to Alibaba itself.

First, for business R&D, we have achieved separation of concerns through the cloud-native concept mentioned above, so that R&D can focus more on business. Through the cloud-native standard delivery method, we have also proposed specifications such as cloud-native standard delivery to carry out sustainable delivery in a standardized and modular manner, taking into account user experience and flexibility, thereby greatly improving the R&D efficiency of the business, allowing them to focus entirely on their own business without having to touch complex infrastructure. This is the greatest value that cloud-native brings to business R&D.

For example, for a large number of business operations and SREs, the agile operations and efficient operations concepts provided by the cloud-native system, as well as its technical implementation, including the lightweight container immutability, infrastructure, highly automated applications themselves and operations and maintenance methods mentioned earlier, can make our software operations and maintenance today extremely simple and efficient. Especially compared with the previous traditional methods, a container-based and automated method can greatly improve our operation and maintenance automation level, greatly reduce manual intervention, and improve the concurrency of our operations. In a true sense, we can realize the so-called leaving complexity to the system and simplicity to the users. This is our cloud-native system today.

Not to mention that today, after containerization, for applications such as Taobao, horizontal expansion and upgrading are very quick and efficient. Instead of upgrading Taobao and your mobile application crashing, this will no longer happen in the cloud-native era.

Another example is the infrastructure. Through the strength of the Shenlong Bare Metal used by Alibaba today, plus our secure container, we can greatly improve the efficiency of resource use in today's data center. We call it improving resource efficiency. In particular, it can support us to deploy secure containers at a very high density, using economies of scale to reduce resource fragmentation. You can fill resource fragments with confidence according to the different forms of your workload. Because of Shenlong Metal, we can ensure that this still has extremely high business operation efficiency and will not interfere with each other. These are all very important changes that this infrastructure can bring to us in today's cloud-native environment. Even for an organization like Alibaba, with the introduction and development of cloud-native technology, it has also brought a very good change, making Alibaba's technology stack standardized and open, able to seamlessly integrate with the ecosystem, and can also reduce R&D costs, so that the reliability and R&D efficiency of the entire system have been greatly improved.

On the other hand, with the standardization of its own infrastructure, Alibaba's technology is rapidly entering the open source community. Today, Alibaba is the company with the most open source projects in CNCF, far ahead of any other manufacturer or other organizations. A key reason for this is that today Alibaba's technology is seamlessly connected to the ecosystem, so we can actively participate in such a broader open source ecosystem and export Alibaba's open source technology. It can even lead and influence the development of the entire industry ecosystem. This is a real change we have seen after Alibaba's cloud nativeization.

Summarize

If we review the concept of cloud native discussed today, we can find that it is actually a process of continuous evolution from architecture to technology to products. From an architectural perspective, cloud native believes that software is born and grows on the cloud, and can maximize the use of cloud capabilities; on the other hand, unlike traditional models, cloud native allows developers to enjoy dividends and can lead its software and applications to continue to modernize.

We have a series of technologies around this architecture and concept, some of which are open source and some are self-developed, but the logic and ideas behind them are highly consistent. In the scenarios of infrastructure, application architecture, development, operation and maintenance delivery, cloud native technology makes the system more reliable, elastic, and fault-tolerant, and the components are loosely coupled and easy to manage, with better observability, so as to fully demonstrate the capabilities of the cloud. Cloud native can unleash the maximum potential of the cloud, but it is often inseparable from the support of the cloud native essence of the concept and technology. These concepts and architectures, such as containers, immutable infrastructure, etc., are actually an efficient means for us to implement cloud native.

Based on these means, we have a variety of products supported by the cloud-native concept, including cloud-native databases, cloud-native service products, middleware, function computing, containers and other open standards. These products can be flexible, utilize the value of the cloud, and enable application R&D, operation and maintenance, and application delivery personnel to be better served by the cloud itself. These products are clearly different from the traditional cloud computing service providers.

Therefore, we will see that the cloud in the future will evolve more towards service, SaaS, and service-oriented approaches, and focus less on the infrastructure layer, because our real user focus is actually on whether its application can maximize the business value.

The entire evolution trend in the future is actually accompanied by a very important point, that is, the capabilities of the cloud are constantly becoming richer and richer, which is very important. The reason why our entire software architecture in the past needed a lot of traditional middleware, or even some microservice frameworks or PaaS, to help us better manage software is that the cloud or infrastructure capabilities are not strong enough. For example, I want a blue-green release capability today, and many clouds do not have this capability for a long time, so some middleware or framework must be used to help you solve it, but this is not the case today. Today, our cloud can almost achieve the management capabilities required by any application you can imagine, and it should even be said that the capabilities of the cloud have almost exceeded most of the requirements of our software architecture today. So in this case, I definitely no longer need an additional layer, whether it is traditional middleware, traditional microservice frameworks or PaaS, to help bridge the gap between software demands and infrastructure.

As this gap narrows, various cloud-native technologies begin to emerge. Therefore, any cloud-native technology is no longer a supplement to a certain capability, but rather it is more about exposing the cloud's capabilities to my application in a simpler and more efficient way. Whether it is containers, K8s or Service Mesh, they all help the application itself to better use cloud services in different links. In other words, they use the infrastructure capabilities behind the cloud. For example, K8s allows applications to enter my cloud's storage and network very simply and seamlessly, and use cloud computing capabilities; Service Mesh uses Sidecar, a completely non-invasive method, to allow you to use the cloud's traffic control capabilities for microservice governance.

The future development of our entire cloud computing, including the focus behind cloud native, must be the same. It is very important to continuously, continuously and fully release the infrastructure capabilities of cloud computing, to software R&D delivery and even the entire life cycle. Because the capabilities of the cloud will become stronger and stronger in the future, with such a trend, we will see that cloud native will gradually lead the entire cloud computing ecosystem.