Wu Haili, Director of CODING Research and Development

Responsible for continuous deployment of product design, and help customers in various industries to complete the design and final implementation of R&D efficiency.

What is cloud native

Cloud Native is the methodology and technical system guiding the Cloud in enterprise applications, including the development, delivery, runtime and other stages of applications. Cloud Native can be understood as:

  • Cloud means that applications run in the Cloud, not traditional IDC;

  • Native means that the application is designed with the cloud environment in mind from the beginning, is designed for the cloud, and runs in the best posture on the cloud, making full use of the flexibility and agility of the cloud platform.

Different vendors have different definitions of cloud native at different times:

  • Matt Stine of Pivotal first proposed the concept of “CloudNative” in 2013;

  • In his 2015 book Migrating to Cloud Native Architecture, Matt Stine defines several characteristics that are consistent with cloud native architecture: 12 factors, microservices, self-agile architecture, API-based collaboration, vulnerability;

  • In 2017, Pivotal’s latest website offers four key points for cloud natively: DevOps + continuous delivery + microservices + containers;

  • In 2018, CNCF updated the definition of cloud native, adding a Service Mesh and declarative API.

It can be summed up simply as: Cloud Native = DevOps + Continuous Delivery + Micro Services + Agile Infrastructure + The Twelve-Factor App) + Service Mesh + declarative API

Status of cloud native application delivery

The main conclusions of “Continuous Delivery, June 2020” released by CNCF are as follows:

  • Open source tools are difficult to meet enterprise publishing requirements

    It is difficult for open source tools to match the release scenarios of medium – and large-sized enterprises. The general solution is to select the 2-4 types in the preceding figure and customize them to meet the requirements based on the enterprise’s own scenarios.

  • Helm is more than just a package management tool

Although Helm’s own orientation is to resolve K8s application installation package management, but also widely used to release the scene, actually it’s not hard to guess, on this infrastructure by the monomer migration to micro service, at the same time also will apply the delivery of segmentation for fine-grained service delivery, but the value of enterprise for the end user delivery, required by the complete application hosting, The value of a single microservice is zero, so it is not surprising that Helm is widely used in publishing scenarios for the integrity of delivery.

  • Jenkins is being replaced

Jenkins and its ecosystem (Jenkins X, Jenkins Blue Ocean) are still the main adopted tools for continuous delivery, but businesses are gradually replacing them with new tools such as Flux, which hosts the GitOps concept. Jenkins’ focus on continuous integration is a slightly weak release scenario, and the Jenkins release context is also analyzed.

Continuously evolving cloud native application delivery

The core conclusion of the CNCF survey is that enterprise needs are not being met, and that the methodology and tools for continuous delivery are still evolving. Let’s review the key methodologies and tools for continuous evolution of cloud native applications.

Continue Delivery

Methodology: Continuous delivery

Continuous delivery advocates that applications be delivered to customers more frequently and more quickly, but faster does not mean a reduction in quality requirements. In general, continuous delivery practices are complemented by means of quality left shift, such as code reviews, code scans, unit tests, and automated tests, to ensure the reliability of application delivery.

Tools: Jenkins, Gitlab Ci, Tketon

Value: With the introduction of continuous delivery, users can automate and visualize the deployment process through the appellate tool. The usual continuous delivery pipeline is as follows: The “Deploy” phase uses commands such as Kubectrl Apply or helm install to Deploy the application.

Core issues: Continuous delivery can be achieved through the appellate tool. The precondition is that the cluster key must be transferred to the tool for management. Compared with GitOps, the key cannot leave the cluster, so it is relatively insecure. In addition, the traceability and auditing of delivery cannot be realized through versioning, and problems are difficult to recover quickly.

IAC

Methodology: IAC (infrastructure and code)

With the rapid development of cloud native applications, enterprises have higher and higher requirements on the delivery and change speed of cloud infrastructure. Relying on the traditional manual way and operating the cloud console to maintain the infrastructure can no longer meet the needs of enterprises. By abstracting the cloud infrastructure and choreographing it through code, it is called IAC.

Tools: TIC, Terraform, Crossplane

Value: IAC will cloud infrastructure, choreography, through code and code stored in the warehouse, will be scheduled to implement the version management of infrastructure, the user can easily expand applications rely on infrastructure, such as a video game company to deploy applications in Shanghai tencent cloud, due to business needs, customers need to deploy applications to the cloud of tencent in guangzhou, Terraform’s ability to quickly migrate application-dependent infrastructure across availability zones:

Core issue: IAC’s capabilities are essentially dependent on the openness and stability of the cloud’s OPEN API, which is evolving rapidly, to some extent, causing IAC’s capabilities to be unstable. While IAC’s maturity is limited to a single cloud vendor, cross-cloud IAC still requires high labor conversion costs.

GitOps

Methodology: GitOps

GitOps is a model to achieve continuous delivery. The core idea of GitOps is to store the declarative infrastructure and applications of the application system in the Git version control repository, and to realize the changes of the application and infrastructure through the change of the version control repository.

Tools: ArgoCD, Flux

Value: Releasing application and infrastructure changes through the version-control repository reduces the complexity of releasing to the Pull and Push operations of the version-control repository. GitOps obtains the changed materials through the Operator installed in the K8s cluster. The cluster key does not need to go out of the cluster, and the GitOps Operator only needs to obtain the certificate of the product library to obtain the product information of application changes, which also greatly simplifies the change delivery process of large micro service applications. Because the perception of changing materials is automatically realized through the Pull mode of Gitops. In addition, Git repositories are endowed with the ability to audit “MR”, trace back “commit log”, and quickly recover “rollback to a certain version”, which greatly improves the reliability of application release. Finally, GitOps realizes the final state control of the repository to the cluster through the status control, so that the “see” of yamL warehouse is the “gain” of K8s cluster.

Core issues: The emergence of Gitops has greatly improved the efficiency and reliability of cloud native delivery, but there are still two issues that remain unresolved. First, the key storage problem. The location of the version repository determines that it is not suitable for storing keys. Second: visualization. Although the repository stores all changes in history, the information may be distributed on different branches, making it less readable.

OAM

Methodology: OAM (Open Application Model)

OAM trying to provide a cloud native applications of modeling language, in order to realize the research and development and operational separation, from the point of view of the complexity of K8s without passthrough to research and development, operations by providing the characteristics of modular, portable and extensible components, support a variety of complex application delivery scene, so as to realize the agility of cloud native application delivery and platform independence.

Tools: KubeVela

Value:

  • Application: Cloud native Application modeling language, achieving perspective separation;
  • Open: Support heterogeneous platforms, container runtimes, scheduling systems, cloud vendors, and hardware configurations;
  • Model: A modeling standard, independent of the underlying platform.

conclusion

The above methodology tries to optimize cloud native delivery from different dimensions. However, enterprises using cloud native architecture still need to customize based on open source tools to meet enterprise cloud native delivery requirements. Therefore, the development of cloud native delivery domain is far from the optimal solution. For example, The issues of environment isolation and governance mentioned in The Twelve-Factor App have not been well solved. As a result, we believe that 2021 will see more methodologies and tools emerge in the cloud native application delivery domain to try to address the enterprise cloud native delivery problem. As the head brand of one-stop DevOps in China, CODING will launch a cloud native application delivery tool in the second half of the year to better serve enterprises landing on the cloud native application and upgrade r&d efficiency.

Click to explore the depth of cloud native tour