Exploration of the definition of cloud-native

The concept of “cloud native” is mentioned, but how many people really understand this concept? Whenever I browse some communities (not least some professional technical communities) and see some friends discussing cloud-native related topics, I sometimes feel that there is still a little bit of a problem with their understanding of cloud-native.

Many people directly think that applications deployed in the cloud are called cloud-native applications. This is generally seen in groups that are new to cloud computing and cloud-native concepts. This is obviously a misconception, or “concept abuse”, and then there are insiders who know some containerization-related concepts, they think that cloud-native applications are built through container technology, deployed on a container orchestration platform like Kubernetes, to be cloud-native applications, which sounds like that, but it is still not rigorous enough, only from the implementation of cloud-native applications But the core concepts are still not explained, for example, what is the specific embodiment of Native in Cloud Native?

In fact, we can’t blame everyone for not understanding what cloud native is, in fact, even the group that first launched the concept of cloud native is also gradually figuring out.

Take a look at the CNCF’s original definition of cloud-native.

The CNCF defines “cloud-native” a little more narrowly, to mean using open source software stack to be containerized, where each part of the app is packaged in its own container, dynamically orchestrated so each part is actively scheduled and managed to optimize resource utilization, and microservices-oriented to increase the overall agility and maintainability of applications.

In short, the original definition of cloud-native is an application that meets the following characteristics.

  • Built with containerized technology.
  • Dynamic orchestration scheduling.
  • microservices-oriented.

Obviously, this is a relatively narrow definition, in fact, to put it bluntly is to talk about a container ecological technology, not really cloud-native.

Then, in 2017, Pivotal, one of the proponents of cloud native applications, outlined the definition of cloud native on its official website as DevOps, Continuous Delivery, Microservices, and Containers, which became the basic impression of Cloud Native for many people.

On June 11, 2018, CNCF gave a clear definition of Cloud Native, you can refer to Github, CNCF Cloud Native Definition v1.0, which has become the most familiar definition today, and the original text is as follows

Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.

These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.

The Cloud Native Computing Foundation seeks to drive adoption of this paradigm by fostering and sustaining an ecosystem of open source, vendor-neutral projects. We democratize state-of-the-art patterns to make these innovations accessible for everyone.

This definition simply contains these key points.

  • Elastic and scalable applications for cloud environments built on technologies such as containers, service grids, microservices, immutable infrastructure and declarative APIs.
  • loosely coupled systems that are highly fault-tolerant, easy to manage and easy to observe.
  • Cloud-native open source-based ecosystem that is neutral to the services provided by cloud vendors.

Note that there is a very important concept called immutable infrastructure. This concept seems to be confusing to people. In fact, it is very simple, the “immutable” in immutable infrastructure is very similar to the concept of Immutable Variable in programming, that is, it can not be changed after the assignment is done, such as the string in Go language, you should not think of stitching the string on the original string by “+”. The spliced string is actually a new string variable, not a change based on the old string, and such variables can be used safely in concurrent environments. For infrastructure immutability, the most basic means that the server running the service is not changed after the deployment is completed. To put it bluntly, the only way to change an old component is to replace it with a new resource instead of modifying it on the original component, which is called immutable infrastructure.

Reinterpretation of Cloud Native

Although the official definition is written here, I think there should be further analysis to make you understand it, so, combined with the previous official definition, let’s now re-introduce the concept of Cloud Native. Back to the phrase Cloud Native, let’s break it down and look at it.

Cloud

It is well understood that the cloud, that is, the cloud computing environment, which is the most basic condition, according to the official definition, should be public cloud, private cloud and hybrid cloud and other new dynamic environment, that is, the concept of cloud native will not limit you based on which specific cloud environment, in almost any kind of cloud environment, do not affect the cloud native application standards to achieve. The cloud can be seen essentially as an object that provides stable computing and storage resources, and to achieve this, things like virtualization, elastic scaling, high availability, high fault tolerance, and self-recovery are all essential attributes of the cloud. Cloud-native as a kind of cloud computing, this is the first layer of meaning possessed.

Native

Native means “aboriginal; indigenous”, and the most important characteristic of Native is that they live here originally and are highly adapted to this environment. It can be interpreted as two meanings, one is to limit it to late immigrants, and the other is to adapt to the environment, just like the Inuit living in the Arctic, only they can be called Native in the Arctic region, but if you are anyone else, even if you can resist the cold, you can’t be called Native.

Then it’s easy to understand what it means to be Native in Cloud Native. As a Cloud Native application, first of all, your application architecture is inherently designed for the cloud environment, both in terms of how services are invoked and the governance structure of the services. From an adaptability perspective, for example, a service deployed in a Pod is likely to go down as the Pod goes down, which is a very common and normal thing in a cloud environment because the scheduling of resources in a cloud environment is very flexible. But in a traditional environment, application downtime is a difficult thing to accept, so applications have to adapt to the cloud environment sometimes at another level. In other words, for some applications developed according to the traditional application model, tinkered with and packaged as images to run on Kubernetes, they are actually just some “pseudo Cloud Native”.

Summary

At this point, I believe the concept of Cloud Native has been discussed clearly. First of all, it is crucial to understand the official definition, we must know that the core technology support of Cloud Native is still containers and microservices, and the core environment is public, private and hybrid clouds. Then the key is back to the understanding of the words Cloud and Native.

Finally, we can re-run the concept that cloud-native refers to applications that follow agile development principles, use highly automated R&D tools, and are developed specifically for the characteristics of the cloud environment, which use automated, scalable, and highly available architecture, on which engineers can achieve efficient observation and management of the application, and can make improvements to the system through automated means.