Author: Yin Da
background
Recently, the App Delivery TAG (Application Delivery Domain Group) under the Cloud Native Computing Foundation CNCF released the "White Paper on CNCF Platform Engineering", and KubeVela was included in the "Unified API Layer" project.
Original download link:
Back in 2019, Kubernetes gradually became the de facto standard for deploying and managing infrastructure. More and more platform engineers are starting to build platforms on top of Kubernetes and provide services to end users. Containerized deployment and declarative API greatly reduce the difficulty of complex system operations.
However, when there are thousands of workloads and related resources in the cluster, it is difficult for operators to identify logical relationships and manage them accurately and in line with business needs based on their internal relationships.
Meanwhile, tools like Helm or Kustomize have explored solutions for packaging and delivering Kubernetes resources. These have proven to be very effective, and clearly Helm Charts are now the most popular way to package and distribute artifacts in Kubernetes.
On the other hand, various projects are also starting to define applications. These attempts are not simply to package resources, but to seek solutions from a top-down perspective. Rather than grouping discrete objects for easier use, applications aim to bridge the cognitive gap between developers of business applications and the infrastructure. The Open Application Model **Open Application Model (OAM) [ 1] ** and its implementation for KubeVela started here.
Pic 1. OAM is proposed to bridge the gap between app developers and the use of underlying infrastructures
The Birth of the Application Model
The Open Application Model (OAM), backed by Microsoft and Alibaba Cloud, aims to provide a theoretical model of what cloud-native applications should look like. It was originally designed not to be tied to Kubernetes, and was intended to provide a unified interface for operational applications. OAM proposes the concept of components and properties to abstract the application architecture. This is a big change for native Kubernetes users, but for good reason.
In Kubernetes, resources such as Deployment or Service focus on implementation. Each resource type provides specific functionality. Some low-level functionality, such as running containers, goes to basic units like Pods. Some higher-level features, such as container orchestration, and the ability to handle rollbacks (such as Deployment or StatefulSet), are built on top of lower-level features. There is no doubt that the positioning of "a platform for platform builders" has achieved great success. But for application developers, the community is forcing them to become Kubernetes experts to make things work. Furthermore, a superficial understanding of low-level resources can actually lead to significant risks from incorrect operation.
components
OAM comes in from a significantly different perspective than traditional solutions. What is the real composition of the application? What do application developers need?
Something that runs the application. This is definitely the core part of the application. In Kubernetes, it could be Deployments, Pods, or something else. Outside of Kubernetes, it could be a Docker container, a virtual machine, or a cloud execution engine. 99.9% of application developers create a program and run it. OAM defines the entire content of a running application as a component. It's not just a set of resources. Without components, you have no way of knowing what the application is for.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: webserver-demo
spec:
components:
- name: hello-world
type: webserver # claim to deploy webserver component definition
properties: # setting parameter values
image: crccheck/hello-world
port: 8000 # this port will be automatically exposed to public
env:
- name: "foo"
value: "bar"
cpu: "100m"
Pic 2. Example of a component inside an OAM application
As microservices become more common, many application developers start breaking down monolithic programs into smaller pieces. Each operational part in the definition of OAM can be modeled as a component, and as a whole, they together form a complete OAM application. Their internal logical relationship is also drawn in the component.
characteristic
For the application to work properly, a few other things are required. For example, in Kubernetes we have Services, ConfigMaps, PersistentVolumeClaims, and many other resources that provide specific functionality to a Deployment. But these resources were created to meet certain technical needs rather than being purpose-driven. ConfigMap provides a way for Kubernetes users to store configuration data, but for containers to use that configuration, users need to add a volume section to the Deployment and set container parameters or environment variables.
If we change the perspective again and consider what application developers really want to do with these resources, we might come to the conclusion that many resources provide additional functionality to application components. Creating a Service or Ingress object is created to provide access to the application. Volumes in PersistentVolumeClaim and Deployment are created to provide storage. Third-party objects (such as ServiceMonitor in Prometheus) are used to provide observation rules. These auxiliary resources and modifications that provide functionality are defined as properties in OAM.
These traits cannot work independently. These functions are attached to components and used as decorations. Without it, the main purpose of the application will not change, but will be incomplete.
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
name: my-example-app
spec:
components:
- name: publicweb
type: web-ui
properties: # properties targeting component parameters.
image: example/web-ui:v1.0.2@sha256:verytrustworthyhash
param_1: "enabled" # param_1 is defined on the web-ui component
traits:
- type: ingress # ingress trait providing a public endpoint for the publicweb component of the application.
properties: # properties are defined by the trait CRD spec. This example assumes path and port.
path: /
port: 8080
- name: backend
type: company/test-backend # test-backend is referenced from other namespace
properties:
debug: "true" # debug is a parameter defined in the test-backend component.
traits:
- type: scaler # scaler trait to specify the number of replicas for the backend component
properties:
replicas: 4
Pic 3. Example of an OAM application containing two components with traits attached
More
Besides Components and Traits, there are other things that work for applications at different levels.
Each application may contain multiple atomic functional units, namely Component (component), and each Component may be modified by multiple Trait. If we want to define some application-level behavior or policy that does not have a clear one-to-one relationship with the running Component, more application definitions are required.
So far, OAM has not proposed a decisive solution to this part of modeling. Some concepts including Scope, Policy, Workflow, and Scope have been proposed to define the application scope. Policy is used to describe common policies and behaviors. Workflow focuses on the delivery aspects of the application. Some of them have been adopted by KubeVela, one of the Kubernetes-based OAM implementations, which can help us drive design through practice in the evolution of models.
From theory to practice
The Open Application Model specification provides conceptual guidance for platform builders who wish to model applications and build platforms from the perspective of application developers. Over the past few years, there have been various attempts by adopters including KubeVela, Crossplane, Verrazzano, and Intuit. Although the OAM specification was proposed to be infrastructure-agnostic, most current (functional) implementations so far are based on Kubernetes as the control plane.
Looking back at history, we have concluded that application modeling on Kubernetes is especially important. When applying the OAM specification to Kubernetes, KubeVela has done a lot of work to solve technical problems in various details. These issues can in turn fall into three distinct directions: abstraction, delivery, and management.
abstract
A component in OAM defines a running instance of an application. Different types of components are suitable for different types of running instances. In Kubernetes, it corresponds to different workload implementations, such as Deployment or StatefulSet. KubeVela declares these types as ComponentDefinition and introduces CUE for extensibility solutions. CUE is used to template Kubernetes resources, so platform builders can do arbitrary customizations.
Pic 4. KubeVela leverages CUE for templating Component and Trait
At the Trait level, the abstract method is similar to Component, that is, use TraitDefinition to declare different types. One of the main differences from Component is that certain types of Traits require modifications to the resources abstracted by the Component Definition. For example, to expose ports, we need to add Service object and expose ports in Deployment specification at the same time. CUE itself does not provide such a method, but KubeVela will extend CUE in some way to achieve this function. In addition to static rendering, KubeVela's abstraction layer also has runtime awareness. This means that the rendering logic can change depending on the runtime environment, just like the version of Kubernetes it is currently running on. This is especially useful when KubeVela is used as a unified control plane across clusters.
Pic 5. In traditional system, application developer needs to deal with version upgrades across clusters
In short, similar to the Go Template used by Helm Chart or configuration simplification through Kustomization, the implementation of the abstraction layer in KubeVela is functionally fully included. On the other hand, KubeVela bases these abstractions on ComponentDefinitions and TraitDefinitions for better reuse. This gives platform builders more granular options than templating the entire application directly with Helm Charts. This in turn provides a clearer division of responsibilities between platform engineers and business developers: platform engineers are responsible for X-Definitions, and business developers are responsible for applications.
Pic 6. KubeVela leaves the abstraction implementation to platform engineers and lets app developers to use predefined types of Components and Traits to compose Applications
deliver
The abstraction layer mainly solves the problems of building, packaging and distributing applications. Things get more complicated when it comes to delivering applications and working with them as a unified whole. The application as a whole is considered as the basic unit of delivery in KubeVela. The relationships between different components within an application can determine how those components are delivered, and these relationships are indicated in the dependsOn field.
Delivery of applications sometimes involves more than resource scheduling, such as manual review of high-risk deliveries to production environments, notifications when automated deliveries are complete, differentiated deliveries across multiple clusters, and more. In order to allow users to customize the delivery process, KubeVela adds Workflow to the application model, where WorkflowStepDefinition uses CUE to define atomic execution units.
Pic 7. KubeVela provides a consistent, programmable, declarative workflow to orchestrate app delivery process
Some users may encounter multiple associated applications for delivery, KubeVela even provides a higher-level solution for this, called Pipeline. At the same time, whether the application model should be designed together with the delivery is also a matter of debate. Independent delivery tools like Tekton, Argo Workflow have been developed over the years. Other CI tools like Jenkins or GitHub Actions are also evolving to support various delivery scenarios. KubeVela has taken an extremely forward-looking step in bringing application models and delivery processes together, as it believes this approach is the best practice for putting application models into production use. But the OAM specification is in no rush to add things like workflow, because answers to theoretical modeling still need a broader discussion.
manage
The application model is not just for delivery, the end-state-oriented capabilities of declarative APIs apply as well. Therefore, in practice, the application model is also used for KubeVela's consistency comparison. KubeVela ensures no deviation from the desired state after the successful completion of the delivery process, which is in line with Kubernetes' ultimate state-oriented philosophy.
Pic 8. KubeVela constantly ensures there's no configuration drift for the delivered application
In addition, KubeVela embeds many other management operations, including version management, permission control, resource sharing, and garbage collection. These functions are currently not included in the OAM specification, but are considered part of future OAM specifications.
In general, in order to meet the various needs of application applications on Kubernetes, KubeVela has been making continuous attempts outside the OAM specification and exploring more possible application operation methods.
If you are interested in more technical details, please refer to **this blog [ 2] **.
future
Many people have questioned why OAM's Github repository seems to be inactive. For those who mainly care about production practice and model usage, the answer is that KubeVela as an OAM implementation has been developing at a high speed, and the number of users adopting KubeVela has been increasing, and KubeVela has just become a CNCF incubation project, which also means that the OAM model Adopters have been increasing rapidly.
As for the theoretical model, KubeVela is still waiting for more feedback and evidence from industrial production practices. We do not want to introduce changes to the specification too quickly and cause problems with the stability of the specification. Our plan is that after KubeVela's practices are widely adopted and gradually stabilized, we will propose additional concepts, such as workflows or policies, to the OAM specification. We hope that with the help of the CNCF Foundation, more and more people will join the community, making the deployment and operation and maintenance of modern applications easier, more efficient, and more reliable.
Finally, I would like to make a preview. In KubeCon + CloudNativeCon Europe 2023, which will be held from April 17th to 21st, there will be three sharing sessions around KubeVela. Everyone is welcome to lock in in advance to learn about KubeVela's latest technology upgrades, community dynamics and corporate practices:
（*TimeZone:Europe/Amsterdam)
- Wednesday, April 19 • 15:25 - 16:00 ：Building a Platform Engineering Fabric with the Kube API at Autodesk - Jesse Sanford & Greg Haynes, Autodesk
- Thursday, April 20 • 16:30 - 18:00 ：Tutorial: Deploying Cloud-Native Applications Using Kubevela and OAM - Daniel Higuero, Napptive
- Friday April 21 • 11:00 - 11:35 ：Challenges of Modern Application Delivery: A Retrospection of KubeVela Highlight Technologies - Jianbo Sun & Da Yin, Alibaba Cloud
English original address: https://www.cncf.io/blog/2023/03/31/kubevela-the-road-to-cloud-native-application-and-platform-engineering/
You can learn more about KubeVela and the details of the OAM project through the following materials:
- Project code base: https://github.com/kubevela/kubevela Welcome to Star/Watch/Fork!
- Project official homepage and documentation: kubevela.io, since version 1.1, Chinese and English documents have been provided, and developers are welcome to translate more language documents.
- Project DingTalk Group: 23310022; Slack: CNCF #kubevela Channel
- Join the WeChat group: Please add the following maintainer WeChat account first, indicating that you have entered the KubeVela user group:
Related Links:
[1] Open Application Model（OAM）
[2] This blog
https://kubevela.net/blog/2022/11/29/retro-2022
Click here to view KubeVela project official website