Continuously evolving cloud-native application delivery

Author of this article: Wu Haili-CODING R&D Director
Responsible for continuous deployment of product design, helping customers in multiple industries complete the design and final implementation of R&D efficiency.

What is cloud native

Cloud Native is the methodology and technical system that guides enterprise applications to the cloud, including application development, delivery, and runtime stages. , Cloud Native can be understood as:

• Cloud means that the application runs in the cloud instead of the traditional IDC;
• Native means that the application takes the cloud environment into consideration from the beginning of the design. The native is designed for the cloud, runs in the best posture on the cloud, and makes full use of the elasticity and agility of the cloud platform.

For the understanding of cloud native, various vendors have different definitions at different times:

• In 2013, Matt Stine of Pivotal first proposed the concept of cloud native "CloudNative";
• In 2015, Matt Stine defined several characteristics in line with cloud native architecture in the book "Migrating to Cloud Native Architecture": 12 factors, microservices, self-agile architecture, API-based collaboration, and vulnerability;
• In 2017, Pivotal's latest official website cloud native as 4 main points: DevOps + continuous delivery +
• In 2018, CNCF updated the definition of cloud native, adding service mesh "Service Mesh" and declarative API.

It can be briefly summarized as: Cloud Native = DevOps + Continuous Delivery + Micro Services + Agile Infrastructure + 12 Elements (The Twelve-Factor App) + Service Mesh (Service Mesh) ) + Declarative API.

The state of cloud-native application delivery

The main conclusions of " Continuous Delivery, June 2020 " issued by CNCF are as follows:

• Open source tools are difficult to meet enterprise-level release requirements
  In the release scenarios of medium and large enterprises, it is difficult to match open source tools. The general solution is to choose 2-4 types in the above picture, based on the enterprise's own scenarios, and in-depth customization to meet the needs.
• Helm is more than just a package management tool
  Although Helm's own positioning is to solve the installation package management of K8s applications, it is also widely used in release scenarios. It is not difficult to guess that the infrastructure is migrated from a single to microservices, and the delivery of applications is also divided into details Granular service delivery, but the value delivery of the enterprise to the end user needs to be carried by a complete application, and the value of a single microservice is 0. Therefore, considering the integrity of delivery, it is not surprising that Helm is widely used in publishing scenarios.
• Jenkins is gradually being replaced by
  Jenkins and its ecosystem (Jenkins X, Jenkins Blue Ocean) are still the main tools adopted in continuous delivery, but companies are gradually replacing them with new tools, such as Flux, which carries the concept of GitOps. Jenkins is located in continuous integration, and the scenario used for release is slightly weak. The following analysis is also made for the release of Jenkins.

Continuously evolving cloud-native application delivery

The core conclusion drawn from the CNCF research report is that the needs of enterprises have not been met, and the methodology and tool construction of continuous delivery are still undergoing continuous evolution. Let’s review the important methodology and related tools for the continuous evolution of cloud native applications.

Continue Delivery

Methodology: Continuous Delivery
continuous delivery advocates that applications are delivered to customers more frequently and faster , but faster does not mean a reduction in quality requirements, usually in the practice of continuous delivery, it will be supplemented by means of quality shift left, such as code review, Code scanning, unit testing, and automated testing ensure the reliability of application delivery.

Tools: Jenkins, Gitlab Ci, Tketon

Value: Through the introduction of continuous delivery, users can automate and visualize the deployment process through appeal tools. The usual continuous delivery pipeline is as follows. Use the "Deploy" phase: kubectrl apply or helm install to complete application deployment.

Core problem: To achieve continuous delivery through the appeal tool, the prerequisite is that the cluster key must be managed by the tool. Compared with the GitOps key, the cluster is not out of the cluster, which is relatively insecure; and the traceability and delivery cannot be achieved through versioning. Auditable, it is difficult to recover quickly when problems occur.

IAC

Methodology: IAC (Infrastructure and Code)
With the rapid development of cloud-native applications, enterprises have increasingly higher requirements for the delivery and change speed of cloud infrastructure. Relying on traditional manual methods to operate the cloud console to maintain the infrastructure has been unable to meet the needs of enterprises. uses abstract clouds. Infrastructure, and the way it is organized through code is IAC.

Tools: TIC, Terraform, Crossplane

Value: IAC arranges the cloud infrastructure through code and stores the orchestration code in the code warehouse to realize the version management of the infrastructure. Users can easily expand the infrastructure on which the application depends. For example, a game company will The application is deployed in Tencent Cloud Shanghai. Due to business needs, customers need to deploy the application to Tencent Cloud Guangzhou. With Terraform's capabilities, the infrastructure on which the application depends can be quickly migrated across availability zones:

Core problem: essentially depends on the openness and stability of the cloud OPEN API. . Cloud products are currently undergoing rapid evolution, which to a certain extent caused the lack of stability of IAC capabilities. At the same time, the maturity of IAC is limited to a single cloud vendor, and cross-cloud IAC still requires high manual conversion costs.

GitOps

Methodology: GitOps
GitOps is a model that implements continuous delivery. Its core idea is to store the declarative infrastructure and applications of the application system in the Git version control library, and implement changes to the application and infrastructure through changes to the version control library. .

Tools: ArgoCD, Flux

Value: The release of application and infrastructure changes through the version control library will reduce the complexity of the release to the Pull and Push operation of the version control library. GitOps realizes the acquisition of changed materials through the Operator installed in the K8s cluster. The cluster key does not need to be out of the cluster . The GitOps Operator only needs to obtain the product library credentials to obtain the product information of the application change. This also greatly simplifies the large-scale micro The change delivery process of service applications, because the perception of changed materials is automatically realized through Gitops' Pull mode. In addition, the Git warehouse is inherently capable of auditing "MR", traceable "commit log", and quick recovery " back to a certain version" 16107d03ae7c74, greatly improving the reliability of application release. Finally, GitOps realizes the final state control of the version library to the cluster through state control, and realizes the "what you see" of the yaml warehouse is the "getting" of the K8s cluster.

Core problem: The emergence of Gitops has greatly improved the efficiency and reliability of cloud-native delivery, but there are still two problems that have not been solved. First: the storage of keys. The positioning of the version warehouse determines that it is not suitable for storing keys; Second: Visualization. Although the version repository stores all changes in history, this information may be distributed in different branches, which is less readable.

OAM

Methodology: OAM (Open Application Model)
OAM attempts to provide a modeling language for cloud-native applications to separate the perspectives of R&D and O&M. , the complexity of K8s does not need to be transmitted to R&D. OAM provides modular, portable, and extensible feature components. , To support various complex application delivery scenarios, so as to achieve the agility and platform independence of cloud-native application delivery.

Tool: KubeVela

value:

• Application: cloud-native application modeling language to achieve separation of perspectives;
• Open: supports heterogeneous platforms, container runtimes, scheduling systems, cloud providers, and hardware configuration;
• Model: Modeling standards, independent of the underlying platform.

Summarize

The above methodology attempts to optimize cloud-native delivery from different dimensions, but use cloud-native architecture still need to customize based on open source tools to meet the enterprise-level cloud-native delivery requirements . It can be seen that the development of cloud-native delivery domains is far from the optimal solution. . For example, the environmental isolation and governance issues mentioned in the 12 elements of cloud native applications (The Twelve-Factor App) are still not well resolved. Therefore, we believe that more methodologies and tools will appear in the cloud-native application delivery domain in 2021, trying to solve the problem of enterprise-level cloud-native delivery. CODING, as a domestic one-stop DevOps head brand, will launch cloud-native application delivery tools in the second half of the year to serve enterprises to better implement cloud-native applications and achieve R&D efficiency upgrades.

Click to explore the cloud native journey in