BizWorks application platform based on KubeVela practice


author: Jing Liming


The cooperation between BizWorks and KubeVela began with version 1.0.5. BizWorks completed the verification of key technologies on version 1.0.5 and expanded BizWorks’ application deployment and operation and maintenance capabilities on the basis of version 1.2.5. Through more than a year of in-depth cooperation, BizWorks has solved some pain points and appeals through KubeVela. At the same time, it has also accumulated some practices based on the functions and features of KubeVela. This article will describe how to explore and practice the cloud-native era by introducing the usage scenarios of BizWorks in KubeVela. The landing of the continuous delivery capability of the new generation PaaS platform.

Introduction to BizWorks

BizWorks( is an integrated development and operation platform for Alibaba Cloud’s native applications, with built-in best technical practices for the construction of Alibaba’s business platform. The products mainly include: business modeling platform, business application platform, exercise stress testing platform, capability operation platform, integrated operation and operation and maintenance platform. The product capabilities provided by BizWorks (Figure 1-1) are generally applicable to the efficient development of enterprise cloud-native applications and the accumulation and reuse of enterprise business capabilities.

BizWorks application platform based on KubeVela practice

Figure 1-1 BizWorks business architecture

The BizWorks integrated operation and maintenance platform provides one-stop application lifecycle management, operation hosting, and operation and maintenance management and control capabilities, and supports multi-cloud adaptation. Therefore, application lifecycle management is indispensable, and CICD is the key to continuous application evolution. Key methods play a vital role in customer product releases and upgrade iterations.

CI (Continuous Integration) mainly includes the construction and material output of middle-end applications, low-code light applications, managed applications, and integrated applications. The pipeline can also directly use the general pipeline products accumulated in the industry.

CD (Continuous Delivery/Continuous Deployment) mainly includes the deployment and operation and maintenance of the above-mentioned types of application construction products, providing customers with core deployment and operation capabilities. Users can complete application deployment based on the built-in deployment engine, and can also access other deployments Products such as EDAS.

This article will mainly describe how to use KubeVela to land in the BizWorks integrated operation and operation and maintenance platform application deployment.

Application Delivery Requirements and Implementation

demand background

BizWorks’ requirements for application delivery mainly include two considerations. The first is that in the context of cloud-native technology, application delivery should be designed based on cloud-native technology architecture, so the selection of application delivery technology used must be able to support the corresponding technical component demands ; The second is to start from the business needs, the current application delivery configuration is facing fragmentation, including environment configuration, resource specification configuration, persistence configuration, network routing configuration, etc., and the types of application delivery products are also different. In order to meet the above requirements, BizWorks chooses to use KubeVela to achieve continuous delivery of applications, ensuring the stability and reliability of the final delivery state of the customer environment.

Application Deployment Architecture

At present, Bizworks supports four types of business applications, and integrates some open source or Alibaba Cloud middleware components. Some of its capabilities are mainly realized by using KubeVela’s Application, Component, Trait, and WorkFlow (Figure 2-1). Based on KubeVela Component, BizWorks defines its own stateless components (stateless-component), stateful components (stateful-component), assembly network (advanced-ingress-trait), etc., and then uses KubeVela to shield different cloud vendors or Kubernetes bases Complexity and diversity constitute the current BizWorks application deployment architecture.

BizWorks application platform based on KubeVela practice

Figure 2-1 BizWork application deployment business architecture

Pain points and solutions of fragmented configuration

If the functions provided by the platform are scalable and flexible, it can bring powerful help to the platform to enhance the existing capabilities and introduce better experience function points. However, due to the different user backgrounds and demands faced by the platform, in order to meet the needs of most scenarios as much as possible, the configuration content may become more and scattered, which was the pain point of fragmented configuration at that time. BizWorks’ solution is to use KubeVela’s rich and powerful plug-ins and operation and maintenance feature patch functions. First, KubeVela has many common plug-ins, such as batch release, fluxcd, etc., and also has many built-in high-availability operation and maintenance feature patches, such as Labels, annotations, init-container, ingress, etc. If there is no customization requirement, using KubeVela’s built-in plug-ins and operation and maintenance feature patches can basically meet the requirements; if you need to customize the platform’s own capabilities, it is also possible. Here, we take the custom operation and maintenance feature patch as an example to introduce How BizWorks implements custom functionality.

When the BizWorks application is released, it can support users to configure network routing (as shown in Figure 2-2), so it is necessary to support multiple ingress and service configurations to take effect at the same time. We have made improvements on the basis of KubeVela’s built-in ingress operation and maintenance features, which support the network routing configuration of batch import declarations, and then send them to KubeVela in the form of custom operation and maintenance features through BizWorks (see the sample code below for related cue definitions). Finally, it will take effect in the cluster.

"bizworks-ingress-comp-1-22": {
  type: "trait"
  annotations: {}
  description: "Enable public web traffic for the component, the ingress API matches K8s v1.20+."
  attributes: {
    podDisruptive: false
template: {
  outputs: {
    // trait template can have multiple outputs in one trait
    if parameter.route != _|_ {
      for _, v in parameter.route {
        "service-(v.serviceName)": {
          apiVersion: "v1"
          kind:       "Service"
            name: v.serviceName
          spec: {
            selector: "":
            if v.serviceType != _|_ {
              type: v.serviceType
            ports: [
                port:       v.servicePort
                protocol:   v.serviceProtocolType
                targetPort: v.port
        if v["ingressName"] != _|_ {
          "ingress-(v.ingressName)": {
            apiVersion: ""
            kind:       "Ingress"
            metadata: {
              name: v.ingressName
              annotations: {
                if !v.classInSpec {
                  "": v.class
                if v.annotations != _|_ {
                  for _, t in v.annotations {
                    "(": t.value
            spec: {
              if v.classInSpec {
                ingressClassName: v.class
              if v["ingressProtocolType"] == "HTTPS" {
                tls: [{
                  hosts: [
                  secretName: v.secretName
              rules: [{
                host: v.domain
                http: {
                  paths: [
                      path:     v.path
                      pathType: "ImplementationSpecific"
                      backend: service: {
                        name: v.serviceName
                        port: number: v.servicePort

  parameter: {
    route: [...{
      // +usage=Specify the port your server want to expose
      port?: int
      // +usage=Specify the protocol your service want to expose
      serviceProtocolType?: string
      // +usage=Specify the name your service want to expose
      serviceName?: string
      // +usage=Specify the port your service want to expose
      servicePort?: int
      // +usage=Specify the type your service want to expose
      serviceType?: string
      // +usage=Specify the type your ingress want to expose
      ingressProtocolType?: string
      // +usage=Specify the name your ingress want to expose
      ingressName?: string
      // +usage=Specify the domain you want to expose
      domain?: string
      // +usage=Specify the path you want to expose
      path?: string
      // +usage=Specify the tls secret you want to use
      secretName?: string
      annotations?: [...{
        name:  string
        value: string
      // +usage=Specify the class of ingress to use
      class: *"nginx" | string
      // +usage=Set ingress class in '.spec.ingressClassName' instead of '' annotation.
      classInSpec: *false | bool

BizWorks application platform based on KubeVela practice

Figure 2-2 BizWorks application network routing configuration

Practice case

First, take a stateless component application release as an example to introduce how to use KubeVela to complete the application release plan. BizWorks inherits the OAM design concept and regards the application as a delivered whole, which is composed of different types of components, and components can be customized by binding O&M feature patches. The components in the application can be released according to their own release plan, and the workload and network topology generated between the components will not affect each other, as shown in Figure 2-3.

BizWorks application platform based on KubeVela practice

Figure 2-3 BizWorks application release plan

BizWorks also supports the deployment of application components with complex structures through helm charts, and like stateless components, supports publishing multiple helm-type components under one application at the same time. As shown in Figure 2-4, the template center provides the functions of uploading, updating, downloading, and deleting helm chart type templates, and then completes the deployment, rollback, and deletion operations of the template components through the helm class components defined by the platform.

BizWorks application platform based on KubeVela practice

Figure 2-4 BizWorks helm chart application release

Results and Benefits

  • Possess basic deployment and operation and maintenance capabilities
    • With the help of KubeVela Rollout, the basic deployment and operation and maintenance capabilities of the application platform can completely cover the life cycle of application instances on a platform, and the labor cost of operation and maintenance is reduced by 50%. The public cloud scenario eliminates the cost of switching between products
    • Flexible feature mechanism​provides convenient routing configuration capabilities for application platforms
  • One-click shortcut function to build test environment

Based on KubeVela’s fluxcd Addon and the template center of the application platform, users can quickly build and release a test environment, which can be completely built in about 15 minutes instead of the normal 3-6 hours

  • Application Model Unification

Compared with other open source CD products, the biggest advantage of KubeVela is its open application model OAM. The resources required for declarative construction are of great help to products with multi-cloud deployment and unified application configuration. After the unified configuration, operation and maintenance personnel do not need to Collect resource applications in various formats, and complete declarative resource creation through platform-based configuration and OAM models. This part of the efficiency is almost 100% improved

In addition, with the CD capability of KubeVela, the number of clusters and applications currently managed by BizWorks has begun to take shape. Among them, the public cloud supports 500+ clusters, with a total of thousands of applications; the private cloud supports 100+ sites, and the current largest site supports 100+ clusters, with hundreds of applications.

future plan

In order to better support the expansion and enhancement of subsequent platform capabilities, BizWorks will continue to carry out in-depth cooperation with KubeVela in the foreseeable near future. The general plan includes:

  • Visual batch release, based on Kruise Rollout and KubeVela, supports stateless components and helm chart
  • Elastic scaling, compatible with ACK and Kubernetes native HPA policies
  • Community contribution, custom definition converted to KubeVela addon
  • Canary release, supporting better traffic control and grayscale strategy

You can learn more about KubeVela and the details of the OAM project through the following materials:

  • Project code base: Welcome to Star/Watch/Fork!
  • Project official homepage and documentation:, 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:

BizWorks application platform based on KubeVela practice

stamphere: Check out the KubeVela project official website! !