1. What Is Cloud Native

Cloud native is a rapidly evolving field.

In 2013, Pivotal proposed the concept of cloud native and has continued to interpret it. Below is Pivotal’s description of the characteristics of cloud-native architecture:

• 2015: 12-Factor, microservices-oriented, anti-fragile
• 2017: Observability, modularity, replaceability, disposability
• 2019: DevOps, continuous delivery, microservices, containers

Many people’s first encounter with cloud native may have been through the CNCF. CNCF projects and the landscape are focal points you cannot avoid in cloud native; below is the CNCF’s description of the characteristics of cloud native:

• 2015: Containerization, microservices, orchestration and scheduling
• 2018: Immutable infrastructure, declarative API, service mesh

These definitions basically outline the skeleton of cloud native. Below are some of my own thoughts on cloud native:

With the rapid development of the internet, the scale, number, and complexity of businesses grew sharply, and R&D-related frameworks came in wave after wave — yet the operations field saw no major change: people kept writing shell and Ansible, and being able to build pages with Django was already considered pretty good.

The turning point came from Docker’s popularization of container technology, after which Kubernetes unified the field of container orchestration. People realized that Kubernetes is a consensus operating system, building a unified control plane on top of distributed resources — comparable to Linux. Cloud native, meanwhile, is more about drawing a line between itself and traditional architecture. Previously you had to log in to a machine to make changes; now it is immutable infrastructure. Previously it was a procedural series of actions; now it is a declarative description. Previously it was monolithic services; now it is microservices. These new characteristics let businesses iterate faster, be more stable and robust, and be accessed more reliably, which in turn drives cloud native further forward.

2. What Is DevOps

Cloud native is inseparable from DevOps, and everyone has a different definition of DevOps in their own mind. DevOps is a generalized concept covering the whole process from requirements to release, taking over the entire R&D workflow. But to understand DevOps you only need to remember one phrase: end-to-end value delivery.

The traditional way of working is more like a big factory, where each person only delivers the part they are responsible for. As shown above, if a process has three steps A, B, and C, then three people are needed, each responsible for one. Once any link fails, it affects the entire delivery.

DevOps advocates value-oriented delivery: only when A4, B6, and C4 are all completed and delivered to the user does the output become meaningful. Therefore, DevOps values team collaboration and the rapid delivery of complete artifacts, and rejects half-finished products.

From the developer committing code, building images, running code scans, executing unit tests, and producing artifacts, to finally deploying to production — this is an end-to-end delivery process. For such a highly repetitive process, we usually need certain tools to get it done, namely CICD tools.

3. Integrating a DevOps Platform under Cloud Native

3.1 How to Develop a CICD Tool

First, consider a question: how do you design a CICD tool? By defining a set of DSL semantics.

We can divide the DSL into two parts: Outer DSL and Inner DSL. The Inner DSL is the CICD engine, used to execute the concrete logic, such as Jenkins and GitLab CI. The other part, the Outer DSL, is used to let users describe the CICD process, such as Groovy in Jenkins or Yaml in GitLab CI.

Encapsulate complexity at the bottom layer and provide services to the upper layer. The Inner DSL implements the parsing of the process and provides functionality closely tied to CICD, which users do not need to pay much attention to. The Outer DSL is used to express the user’s intent, is easy to learn and master, and offers expressiveness tailored to CICD scenarios.

3.2 Operators Connect Everything

In the cloud-native context, we usually extend things using the Operator pattern. That is, using CRDs to define the Schema fields, storing object data as CRs, and, after the Informer watches for changes, continuously Reconciling through the Controller until the desired state is reached.

This pattern can be described from two angles.

• Declarative, which is one of the characteristics of cloud native. If you need to set a component’s replica count to 3, the traditional approach is +1, +1, +1. But under Kubernetes, you only need to declare that the replica count is 3, and the system completes the +1, +1, +1 process for the user. The Operator turns the traditional procedural approach into a declarative one.

• Replacing manual work. The Operator literally means “one who operates”, which already states its role clearly: to replace human labor. The Operator incorporates knowledge from the operations field, hard-coding human skills into program code, and, by reading CR data, performs the specified operations to achieve the same effect as manual operations.

Operators can connect to any external component and replace the manual operations process — for example, deploying a Redis cluster or integrating with Jenkins.

3.3 DevOps Operator

Survey data from China shows that more than 50% of users use Jenkins as their CICD engine. Therefore, KubeSphere DevOps also chose Jenkins.

In KubeSphere DevOps, we made the following abstractions for it.

Below is a schematic of the processing flow:

Through the frontend page, we write the CR object into Etcd, and then continuously watch and use the Controller to sync the data to Jenkins. The user triggers Jenkins’ execution operations through the page; Jenkins creates a Pod in Kubernetes as an Agent to build images, and finally publishes to the environment.

In the platform, we have built-in Python, Go, Nodejs, and Java build clients. Other types of Agents can also be added easily, either built-in or defined via Yaml.

4. Challenges and Outlook

• DevOps is tightly coupled with Jenkins

Although we use the Operator to automate the management of DevOps-related data and operations, take a look at the description of the following Pipeline object.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

apiVersion: devops.kubesphere.io/v1alpha3
kind: Pipeline
metadata:
  annotations:
    kubesphere.io/creator: admin
  creationTimestamp: "2021-03-24T20:04:22Z"
  finalizers:
    - pipeline.finalizers.kubesphere.io
  generation: 2
  name: test
  namespace: testxxs9t
  resourceVersion: "41074824"
  selfLink: /apis/devops.kubesphere.io/v1alpha3/namespaces/testxxs9t/pipelines/test
  uid: 22fad924-8f13-400c-a249-7c792ce9ea68
spec:
  pipeline:
    discarder:
      days_to_keep: "7"
      num_to_keep: "10"
    jenkinsfile: echo "hello"
    name: test
  type: pipeline
status: {}

As can be seen from the Yaml, the relevant fields under Spec are tightly related to Jenkins, which is actually very unfavorable for extensibility. If we later need to integrate other workflow engines, we would essentially have to rewrite a whole set of Operators.

• CRD == DataBase?

Equating CRD with a DataBase can indeed help developers write code logic quickly, but the lack of abstraction and design will lead to disaster. Overturning and refactoring is not the hardest part; the hard part is doing it on a highway while guaranteeing a smooth switchover. Data migration is the challenging part of this process. When designing, you need to consider the data migration problem.

• A Unified Outer DSL

Finally, what I look forward to more is a general abstraction model that can integrate with mainstream CICD tools. Users could connect to various workflow engines by defining the Stage and Context in the execution flow, while at the bottom layer only a single set of Interface needs to be implemented.