Brief introduction:With any cloud-native technology, it’s no longer about making up for some capabilities, but more about bringing the capabilities of the cloud to my applications in a way that’s simpler and more efficient. Whether it’s the container, K8s, or Service Mesh, they all help the application itself to better use cloud services.
By Zhang Lei
What is cloud native?
Even though “cloud-native” has been around for a while, many people still have this question: what exactly is cloud-native? Or what exactly is the definition of cloud native?
In fact, when we come across many cloud-native open source technologies and products, we will gradually find that cloud native is not a very precise object in nature. In other words, there is no specific definition of cloud native, it is an evolving process. Rather than talk about the nature of the cloud’s native nature, let’s think of it as a set of visions.
So what is the content of this vision?
In the cloud era of the future, our software or applications are naturally born on the cloud and grow on the cloud. The reason for this phenomenon or fact is that cloud computing can help these software to reduce cost and increase efficiency the most, and release the most business value of the software itself. This is what Cloud Native really wants to do, so it’s not a specific technology, it’s not a specific method, it’s not a specific scientific research project.
The evolving cloud native
The figure below provides an intuitive illustration of how the overall shape of cloud native is evolving and developing.
Cloud Native is very focused on taking advantage of the features of the cloud, so its core methodology and core concepts are all around how to make our software and applications take advantage of the features of the cloud. So what are the characteristics of the cloud? For example, the cloud can be infinitely flexible, the cloud resources can be delivered quickly, and the cloud usage can be paid by the volume. These are very essential features of the cloud.
Around these features of the cloud, cloud native has developed a set of basic methodologies and concepts. For example, you may have heard of immutable infrastructure, where when my application is deployed in the cloud, assuming that the application carrier is immutable, AND I can delete it or replace it at any time, it’s very easy to update my application. If you want to upgrade an application, you can simply delete the old one and launch the new one, rather than having to dynamically change a configuration in the application or even dynamically change the code to implement it. So immutable infrastructure is a very typical methodology based on leveraging the cloud’s rapid resource delivery capabilities.
For another example, cloud native emphasizes a high degree of automation, self-operation and maintenance, and even self-healing. In fact, it also hopes that the software itself can make better use of the features of the cloud. Because cloud ability is very strong, the clouds can provide all kinds of operational ability, so the application or software may from the development, to consider cloud can actually provide many capabilities to the application layer, and is not to say that developing the application first, then to think about how to use the cloud’s ability to operations, it is to build out the cloud native applications.
For example, it’s also obvious that cloud native apps don’t matter what language or framework they’re written in. Because the cloud itself is an infrastructure capability, it should not and will not be locked in a language or framework. It is also the hope that all software in the world will be able to take advantage of the capabilities of the cloud, rather than the fact that the cloud only serves one language.
These are some of the most important concepts that cloud native presents in the context of the cloud. These concepts themselves are mapped into a series of systems, or architectural ideas, in our technical studies. For example, as mentioned earlier in immutable infrastructure, you can delete an old instance of an application and replace it with a new instance. How to implement such a set of methods? It depends on container technology. Container technology essentially provides container images. A container image is a self-contained version of an application’s runtime environment, including the application itself, and can be replaced at any time with a new version. This actually represents a very good implementation of immutable infrastructure for containers.
So does that mean that there will be a technology in the future that will be better able to implement immutable infrastructure? It’s possible, and the technology is certainly cloud-native. While there may be a new technology in the future to implement immutable infrastructure, or better yet immutable infrastructure, such a technology must also be at the core of cloud native. Similarly, the Sidecar architecture that we emphasize in cloud native today is to connect middleware capabilities to the business container in a way called Sidecar container, instead of customising the business itself and integrating middleware to solve the problem. This is a framework that is intended to practice the language independent, framework independent methodology that we emphasize. The characteristic of this architecture is that the middleware capabilities no longer need to be embedded in the business code itself in a language or framework, so both Sidecar and container can implement such a set of methods.
This is a series of technologies and architectures derived from the cloud native methodology, and these technical architectures are ultimately used in the cloud native ecosystem as open source technical projects. For example, the container mentioned above will have projects on Docker, and the Sidecar and self-maintenance ideas we mentioned will eventually be implemented through Kubernetes.
Service Mesh, for example, is a more recent hotspot, which essentially helps you build middleware capabilities, but does it in a language-neutral way like Sidecar. For example, eBPF and WASM, which are already popular in our future or now, are actually practicing some idea and some architecture behind the cloud native system, in an open source way to meet the needs of users. And it is because of this series of open source projects that we can say that when our users get this kind of open source project and get this kind of technology, they can really practice the cloud-native concept, so as to achieve the essential effects of the two clouds we mentioned earlier:
The first is to improve efficiency, such as r&d efficiency, delivery efficiency, operational efficiency. For example, my application itself implements the idea of immutable infrastructure through the container, so its delivery can be very simple, I just need to do the mirror, deliver the mirror and it can run everywhere; Another example is our operation and maintenance. When your software itself has realized self-operation and maintenance, the difficulty and cost of its operation and maintenance must be reduced. Therefore, we must be able to improve the efficiency with the help of the cloud.
The second is to reduce costs, including resource costs, including labor costs. For example, through Kubernetes or through the container project, my application can better and more integrated with cloud services, through cloud services to reduce the cost of operation and maintenance and human investment, these are obvious cost reduction. For example my application through the cloud native realized on the cloud, and through the cloud native architecture, can be very fast delivery and update mode, make the whole application resources is also low cost, it is also through the cloud native technology, to allow applications to better use of cloud a kind of very good reflect the essence of ability and practice.
In general, you will find that this set of cloud native methods is actually a very perfect closed loop. First, you should constantly look at and explore how to use the features of cloud to help users improve efficiency and reduce costs, and then summarize and precipitate this series of methods or ideas into the concept and methodology of cloud native. Then through a series of corresponding architecture and corresponding open source projects will be implemented, and finally users can use these technologies, so as to achieve the essential purpose of releasing the dividend of cloud computing.
So the cloud doesn’t have a specific definition, it’s really a self-evolving set of theories plus best practices.
Today’s cloud is native
While today’s cloud natives may be built around containers and Kubernetes, projects like this actually help us practice the essential ideas behind a lot of cloud primitives, including immutable infrastructure, automation, and more. Today, Kubernetes is considered the universal control plane of the cloud age. Some people call it an operating system, which means that all your operations can be unified on the cloud with Kubernetes.
1. “Android” of Kubernetes project
The Kubernetes project’s role may become more like that of an Android. For example, Kubernetes today is actually becoming ubiquitous. It’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere, it’s everywhere. Even the air conditioner might have an Android.
More importantly, what is the essence of Kubernetes? It’s the software that delivers and manages it. For example, if I use Kubernetes, I must have deployed something on it, such as AI services or Taobao. The essence of the user’s purpose is to use this thing to manage the software. In fact, Kubernetes itself exposes a series of formatted abstractions, such as Deployment, Service and Ingress, so that I can manage and deliver my application. For it launched a set of standardized interface, for example, through the CNI can docking ali cloud network docking since research network plug-in, so it is essentially a layer, namely a control plane, access to a large number of infrastructure, and the things they exposed became my applications needed some ability, let me be able to use these skills to management applications.
So this is a trend that if you go further and further, you’ll find that it’s very similar to Android. For example, Android doesn’t actually pay for the phone itself, but it does pay for the app in the app market. The value of Android is that it abstractions, wraps, and encapsulates the user’s phone into a set of apis that apps can use, so the value of Android is exactly the same as Kubernetes is today.
In the future, we will see Kubernetes not only appear in a variety of different places, but more importantly, it will provide users with a complete set of capabilities throughout the lifecycle of application development, operation, and delivery. At the same time, in order to be able to better deliver the software, we will find that there will be a lot of projects in the future that will specifically help you solve the problem of software delivery on K8s. At the same time, our old PaaS are going to be gone because the power has been taken over by Kubernetes, and there’s going to be more of these open, scalable PaaS that will allow you to deliver and manage software better and easier, like pea pods on Android. It’s easy to manage software. For this trend, I call it the “Android” of Kubernetes.
2. “Operatorization” of applications and capabilities
Another trend is that in today’s cloud-native ecosystem, both my applications and my capabilities will evolve in a very automated direction, which I call “operatorization.”
Operator is one of the core ideas in Kubernetes. It means that any application and the capabilities it needs can be defined as a Kubernetes API object that allows you to use the capabilities of the cloud through a mechanism called Controller. And let you plug into all kinds of infrastructure. As a direct result of this operaterization, my application itself was highly automated, including self-healing, robustness, reliability, and deterministic performance, all of which could be handed over to Kubernetes today. My users, or the owner of my app, don’t have to worry about that anymore.
So this is another trend that we see today in the context of K8s Android, which is that the capabilities required by my application itself and business will continue to evolve in the direction of automation. This is also very consistent with the concept of cloud native, because the stronger the automation and self-healing ability of your application, the more you can connect with the cloud, the lower the cost of manual recording, and the less time. More importantly, I can connect my automation ability with the cloud, so that the cloud can help me solve all the problems.
3. Further “sinking” of application middleware capability
There is also a tendency for the middleware capabilities that we need for the application itself to sink. What used to be centralized middleware has evolved over the years into a microservice architecture.
The microservices architecture is essentially taking the old set of centralized middleware and putting it in business code, and you need to bring it in. In general, a heavy client or library is provided for you to use, which is a typical way to use middleware in our microservices era. But in today’s world of cloud nativists, is there a mechanism like Sidecar?
Middleware today is actually used a lot by Sidecar, so my application itself doesn’t need to introduce a library, or introduce a specific framework to do a lot of things, I don’t even need to be aware of it. For example, if I’m going to do traffic segmentation today, I don’t need to say I’m going to introduce a library into my application to do it, but I’m going to leave it to my infrastructure, to the cloud.
The application interacts with the cloud through a Sidecar. The Sidecar is used to proxy the incoming and outgoing traffic of the application. Therefore, the cloud can easily adjust and divide the traffic through such a proxy.
Today, middleware capability is sinking in such a way that it will lead to a very clear trend that middleware is no longer relevant to the business, no longer relevant to the language in which the program is written, and no longer dependent on the framework. Its implementation with the K8s container system will be very close to the integration. In addition, I will rely more on Sidecar, so the corresponding Sidecar management ability is gradually to improve the requirements. We can summarize it as a further sinking of application middleware capabilities.
Native cloud services emerge in an endless stream
In addition, with the continuous development of the cloud native system, we will see cloud services in a large number of, frequently close to the cloud native ecosystem, and even bring some revolutionary impact.
Today, ali cloud cloud native database, for example, it is actually based on cloud native mentioned the core ideas, such as unlimited flexibility, highly extensible, puts forward a new database schema, makes the database itself is very easy to expand, be able to cope with very high, very strict traffic and vast amounts of data processing requirements, Meet the demands of database use in today’s modern Internet applications.
For ali cloud infrastructure, it can bring us the utmost resources use efficiency, reduce loss, the performance of many layers of virtualization and let the container itself is flexible, easily to operational deployment and management, and through safe container, through stronger security boundary, ensure the container, the isolation between the isolation is enough. The ability to bring extreme physical levels of network storage and computing performance to the container is very important, and is a very typical example of our application using cloud computing services through the concept of cloud native.
Amazon Cloud, for example, makes it easier or more direct for the chip itself to adapt to the way container applications are used. Because a container may be only a very independent or very modular a process running, then I can use the core of the chip to fit such a business, my the power of infrastructure to the stronger, the ability to the limit, at the same time ensure that such interference between core is very few, more adapt to the use of the container, the application of micro service mode.
For example, Amazon Cloud technology recently launched a cloud native application deployment engine, which can deploy any such cloud service or container service in the same way as we do. This is a very typical product that can help us use the capabilities of the cloud to improve the efficiency of application management, delivery and maintenance.
So whether we look at these products or look at the so-called open source projects, when we want to think about such a question, say my cloud product is not the so-called cloud native, cloud native technology, is actually very simple. Just judge it can help my application to take advantage of cloud computing to the greatest extent authors effect, can release maximum business value through this way, this is a technical judgment, or a product is to locate it for cloud native a very core of a standard, rather than say to see the product’s container or not.
Alibaba Cloud original biochemistry
Going back to the example of Alibaba itself, we can look at the fact that today Alibaba’s infrastructure is based on a whole set of technologies like Kubernetes containers, accomplishing what we call cloud protobiology. When we really look back at such a thing, we will find that cloud native itself has brought some very important changes to Alibaba itself.
First of all, we have achieved a good separation of concerns through the cloud native idea mentioned above, and the research and development is more focused on business. Through the cloud native this standard mode of delivery, we also put forward like cloud native standard delivery specification, sustainable delivery to standardization and modularization, user experience and flexibility, thus greatly improve r&d efficiency of the business, let them fully focused on their own business, don’t have to come into contact with the complex infrastructure, This is the biggest value cloud native brings to business r&d.
Again for example of a large number of business operations and SRE, the agile operations provided by the cloud native system efficient operation of the concept, and its technical implementation, including speaking in front of the lightweight container immutable, infrastructure, highly automated application itself and operational way, to be able to let us today’s software becomes extremely simple, extremely efficient operations, Especially compared with the traditional way before, a way based on automation based on the container, can enhance our operations and high degree of automation, much less human intervention, improve our operating concurrent degree, the implementation of the true sense of the so-called complex to system, leave simple for users, this is our today’s cloud native system.
Not to mention that today after container, such as Taobao, the application to do horizontal expansion and upgrade is very fast, very efficient, rather than say that upgrade Taobao, your mobile app will die, in the cloud native era, this will not happen.
Another example is for infrastructure, the power of The Dragon bare metal that Ali uses today, together with our secure containers, can help us greatly improve the resource efficiency of today’s data centers, which we call improved resource efficiency. In particular, it allows us to deploy secure containers at very high densities, leveraging economies of scale and reducing resource fragmentation. Depending on the shape of your workload, you can confidently fill in the fragments of resources, and with Dragonmetal we can make sure that we can do that, and still have very high business efficiency, without any interference with each other. These are all in today’s cloud native environment, the infrastructure that can give us a very important a change, even said to such an organization of alibaba, with the introduction of cloud native technology and development, also has brought a great change, let alibaba technology stack, standardization and opening up, to be able to seamlessly integrate with ecology, Also can reduce the research and development cost, so that the reliability of the whole system and research and development efficiency have a very good improvement.
On the other hand, alibaba’s technology is rapidly moving into the open source community as it standardizes its infrastructure. Today Alibaba has the most open source projects in CNCF, far ahead of any vendor or other organization. Here is a key reason is that alibaba is the seamless docking with ecological technology today, so we were able to actively to participate in the open source of such a broader ecological, ali’s open source technology output, even said that the lead and the impact on the development of the industry ecological process, this is alibaba cloud after the original biochemical, What we see is a real change.
conclusion
六四事件
If we look back at the cloud native concept we talked about today, we can see that it is actually an architecture to technology to product evolution process. From the perspective of architecture, cloud Native believes that software is naturally born on the cloud and is longer than the cloud to maximize the utilization of the capabilities of the cloud. On the other hand, unlike traditional models, cloud native allows developers to enjoy the benefits of leading its software and applications to the constant modernization.
Around this architecture and philosophy, we have a range of technologies, some of which are open source, some of which are self-developed, but the logic and thinking behind it is highly consistent. Around the infrastructure, application architecture, development, operation and maintenance delivery scenarios, cloud native technology makes the system more reliable, resilient, and fault tolerant, and the components are loosely coupled, easily managed, and observable, so as to fully expose the capabilities of the cloud. Cloud native can release the maximum potential of cloud, in fact, it is often inseparable from the essence of cloud native philosophy and technology support, represented by these concepts and architecture, such as containers, immutable infrastructure, they are actually an efficient means for us to cloud native inside.
And around these means, we have such a variety of cloud-native products supported by the concept of cloud native, including cloud native database, cloud native service products, middleware, function computing, containers and a series of open standards, to be able to elastic, to take advantage of the value of the cloud, A range of products that enable development operations and application delivery personnel to use applications better served by the cloud itself can be very distinct from traditional cloud computing service offerings.
As a result, we will see the future cloud evolve more towards Service, SaaS, and Service, and less towards infrastructure, because our real user concern is whether its application can give full play to the business value.
The whole evolution of the future, it’s actually accompanied by a very important point, which is that the cloud is getting richer and richer, and that’s very important. In the past, our entire software architecture itself required a lot of, say, traditional middleware, or even some microservice frameworks or PaaS, to help us manage software better. The reason behind this was that the cloud or infrastructure was not strong enough. For example, I want a blue-green release capability today, and a lot of clouds don’t have that capability for a long time, so you have to have some kind of middleware or some kind of framework to solve that for you, and today that’s not the case. Today, our cloud can manage almost any application you can imagine, and in fact, the cloud’s capabilities almost exceed most of the requirements of our software architecture today. So in this case, I don’t necessarily need an extra layer, either traditional middleware, or traditional such a microservice framework or PaaS, to help bridge the gap between the requirements of the software and the infrastructure.
As the gap narrowed, a variety of cloud-native technologies began to emerge. So any cloud-native technology, it’s no longer about making up for some capability, but more about bringing the capabilities of the cloud to my applications in a way that’s simpler and more efficient. Whether it’s the container, K8s, or Service Mesh, they all help the application itself to better use cloud services. Or using the infrastructure capabilities behind the cloud, such as K8s, which allows applications to very unimaginably and minimalist access to my cloud’s storage and network, using cloud computing capabilities; Service Mesh allows you to use the cloud’s flow control capabilities as microservice governance in a completely non-intrusive way like Sidecar.
The focus of our entire cloud computing development, including cloud native, must be the same in the future. It is very important to continuously, continuously and fully release the infrastructure capabilities of cloud computing, from the development and delivery of software to the entire lifecycle. Because in the future, the cloud will become more and more powerful, and with such a trend, we will see that the cloud native will gradually lead the entire cloud computing ecology.
Copyright Notice:The content of this article is voluntarily contributed by real-name registered users of Ali Cloud, and the copyright belongs to the original author. Ali Cloud developer community does not own the copyright, and does not bear the corresponding legal responsibility. For specific rules, please refer to the “AliYun Developer Community User Service Agreement” and “AliYun Developer Community Intellectual Property Protection Guidelines”. If you find any suspected plagiarized content in this community, please fill in the infringement complaint form to report. Once verified, the community will immediately delete the suspected infringing content.