What exactly is the overwhelming "cloud native"?

📄

Text｜ togettoyou

Currently mainly responsible for the research and development of cloud native service management platform

Daily commitment to Go and cloud native fields

This article 3164 word reading 5 minutes

▼

cloud native seems to be a clichéd concept, and related articles emerge endlessly.

I am currently responsible for the research and development of cloud native service management platform (mainly managing various cloud native infrastructure, platform services and third-party hosted applications), but even so, I often find it difficult to be concise when asked what cloud native is It’s clear to others that I often ask myself, what exactly is cloud native, and what am I doing.

PART. 1 What exactly is cloud native

Cloud Native is a compound word, namely Cloud Native .

Pivotal (acquired by VMware) official website What is cloud native? [1] mentioned in the article that cloud native is a method of building and running applications, cloud native development integrates DevOps, continuous delivery, microservices and The concept of the container is in .

CNCF (Cloud Native Computing Foundation) the definition of cloud native V1.0 in 1618a54c0e4cd6 cncf/toc

cloud native technology is beneficial for organizations to build and run flexible and scalable applications in new dynamic environments such as public cloud, private cloud, and hybrid cloud. Representative cloud native technologies include containers, service grids, microservices, immutable infrastructure, and declarative APIs.

These technologies can build a loosely coupled system that is fault-tolerant, easy to manage, and easy to observe. Combined with reliable automation, cloud native technology enables engineers to easily make frequent and predictable major changes to the system.

Cloud Native Computing Foundation (CNCF) is committed to fostering and maintaining a vendor-neutral open source ecosystem to promote cloud native technologies. We democratize the most cutting-edge models to make these innovations available to the public.

Combined with the official definition, my personal understanding of cloud native is simple and concise: cloud native is not a specific technology, but a collection of ideas to help quickly build and run applications, which covers a whole set of technologies. System (containers, service mesh, microservices, immutable infrastructure and declarative API), also contains the management points of application development (DevOps, continuous delivery, Conway's law [3]), as long as it meets this Applications of similar ideas can be called cloud native applications.

PART. 2 Cloud Native Technology System

A set of cloud-native technology systems are actually closely related, which starts with the gradual evolution of the software architecture.

That is: monomer -> microservices -> microservices based on K8s -> service mesh

Monolithic architecture integrates all functions into one project. In the early stage of project development, application development is relatively simple, even if large-scale changes, testing, and deployment of applications are required, even horizontal expansion. After running multiple instances, a load balancer can be done.

As time goes by, a successful application will inevitably become more and more bloated, the code base will swell, and the cost of team management will continue to increase, that is, as the saying goes, it will fall into a single hell. In the face of monolithic hell, it is difficult for developers to understand all the code, the development speed becomes slow, the deployment cycle becomes longer, and horizontal expansion will also encounter challenges, because the resource requirements of different modules in the application are conflicting with each other, and some may need to be Larger memory, some may require high-performance CPU, as a single application, it must meet these requirements.

When a problem arises, there will naturally be a solution to that problem. The architecture one of the cloud-native technology systems, is the solution to the single hell. Since the monolithic application integrates all the functions into a project to compile and deploy, now only need to separate each function (usually according to business capability or according to subdomain , the subdomains are divided around Organize services), treat each split module as a separate service and deploy independently (services are usually communicated through REST+JSON or gRPC+ProtoBuf ), so that each service can provide the entire application together Function.

But microservices are not a silver bullet. After the introduction of microservice architecture, distributed systems have also brought various complexity. Business-independent infrastructure levels such as configuration centers, service discovery, gateways, and load balancing require developers to implement them at the business level.

For example, a common architecture solution (Figure source 1618a54c0e4eed Phoenix architecture [4]) requires developers to introduce various components by themselves:

After the project development is completed, the deployment process is ultimately required. The early traditional approach was to deploy the application directly to the server, but the server’s system and environment variables will continue to change, and even new applications will be installed. The conflicts of other applications cause the application itself to change with the change of the user's system environment. To solve this problem, the slogan of the infrastructure

The first stage is to deploy the service as a virtual machine, and deploy the service packaged as a virtual machine image to the production environment. Each service instance is a virtual machine.
In the second stage, in order to reduce overhead, the service is deployed as the container , and deployed as a container image packaged service in the production environment, so that each service instance is a container.

Immutable infrastructure:

Once an instance of any infrastructure is created, it becomes read-only. If you need to modify or upgrade it, you need to replace the old one with a new instance. Container mirroring is a concrete realization of immutable infrastructure.

Now containers have become a good partner for microservices. Service instances are isolated and resources can be easily controlled. However, managing hundreds of containers is too cumbersome. As a result, the container orchestration tool came out again, Kubernetes currently basically unifies the container orchestration market, and realizes the automatic deployment, expansion and contraction and maintenance of container clusters. But Kubernetes is not limited to container orchestration. In the above microservice architecture, developers need to solve a series of business-independent infrastructure problems at the application level. Now Kubernetes can solve most of them, as shown in the figure (Figure source Phoenix architecture [5]):

The coding method of Kubernetes is actually a declarative API (referring to the tool by describing the target state that you want to achieve, and then the tool internally calculates how to make the thing reach the target state).

, immutable infrastructure, and declarative APIs in the cloud native technology system. There is also a 1618a54c0e50c0 service mesh .

The development step by step is to business and the infrastructure , so that developers can quickly develop their own businesses without worrying about the underlying infrastructure. The service grid also wants to do this, hoping to sink more business-unrelated functions into the infrastructure, so-called microservice 2.0.

The core of the service grid is to separate the client SDK and run as a separate process as a Proxy component. Each service is additionally deployed with this Proxy component. All outbound and inbound traffic is processed and forwarded through this component. This component is called Sidecar (sidecar application).

Sidecar is only responsible for network communication, and a component is needed to uniformly manage all Sidecar configurations. In the service grid, the part responsible for configuration management is called the control plane, and the part responsible for network communication is called the data plane. The data plane and the control plane together constitute the basic architecture of the service grid.

I heard that one step further is serverless.

``Key Points of Cloud Native Management''

DevOps (a combination of Development and Operations) is a collective term for a set of processes, methods, and systems used to promote communication, collaboration, and integration between development (application/software engineering), technical operations, and quality assurance (QA) departments.

--Baidu Encyclopedia

The two core concepts of DevOps are CI (Continuous Integration) and CD (Continuous Delivery/Deployment).

"End"

Thanks for reading here. This article roughly describes the connection between cloud native as a kind of thought and its technical system. If there is any mistake, please feel free to discuss and correct it!

「Reference Materials」

[1] What is cloud native?:

https://tanzu.vmware.com/cloud-native

[2 ] cncf/toc:

https://github.com/cncf/toc/blob/main/DEFINITION.md

[3] Conway's Law:

https://zh.wikipedia.org/zhmy/%E5%BA%B7%E5%A8%81%E5%AE%9A%E5%BE%8B

[4] Phoenix Architecture:

http://icyfenix.cn/exploration/projects/microservice_arch_springcloud.html

[5] Phoenix Architecture:

http://icyfenix.cn/exploration/projects/microservice_arch_kubernetes.html

Recommended reading this week