How BizWorks Harnesses KubeVela for Cloud‑Native Continuous Delivery

Collaboration Overview

BizWorks integrated KubeVela starting with version 1.0.5 and expanded deployment and operation capabilities in version 1.2.5. The integration enables continuous delivery for a next‑generation PaaS platform.

Delivery Requirements and Challenges

BizWorks needs to support:

Cloud‑native architecture design, requiring delivery technologies that can manage the relevant Kubernetes components.

Business‑driven configurations that are fragmented across environments, resource specifications, persistence, and networking, with diverse artifact types.

KubeVela was selected to provide a stable, reliable continuous‑delivery pipeline that consolidates these fragmented configurations.

Application Deployment Architecture

BizWorks defines four categories of business applications and integrates open‑source or Alibaba Cloud middleware. Deployment is expressed through KubeVela primitives:

Application

Component

(stateless and stateful) Trait (including a custom advanced‑ingress trait) WorkFlow The model abstracts differences among cloud providers and Kubernetes distributions, allowing a unified deployment workflow.

Fragmented Configuration Pain Points and KubeVela Solution

KubeVela’s plugin ecosystem and built‑in operational traits (labels, annotations, init‑containers, ingress, etc.) address most configuration needs. For scenarios requiring custom behavior, BizWorks creates its own traits.

Custom Ingress Trait Example

To allow users to configure multiple Ingress and Service objects in a single deployment, BizWorks extended the built‑in ingress trait with a batch‑injection mechanism. The following Cue definition illustrates the custom trait:

"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: {
    if parameter.route != _|_ {
      for _, v in parameter.route {
        "service-\(v.serviceName)": {
          apiVersion: "v1"
          kind:       "Service"
          metadata: { name: v.serviceName }
          spec: {
            selector: { "app.oam.dev/component": context.name }
            if v.serviceType != _|_ { type: v.serviceType }
            ports: [{ port: v.servicePort, protocol: v.serviceProtocolType, targetPort: v.port }]
          }
        }
        if v["ingressName"] != _|_ {
          "ingress-\(v.ingressName)": {
            apiVersion: "networking.k8s.io/v1"
            kind:       "Ingress"
            metadata: {
              name: v.ingressName
              annotations: {
                if !v.classInSpec { "kubernetes.io/ingress.class": v.class }
                if v.annotations != _|_ { for _, t in v.annotations { "\(t.name)": t.value } }
              }
            }
            spec: {
              if v.classInSpec { ingressClassName: v.class }
              if v["ingressProtocolType"] == "HTTPS" {
                tls: [{ hosts: [v.domain], 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: [...{
      port?: int
      serviceProtocolType?: string
      serviceName?: string
      servicePort?: int
      serviceType?: string
      ingressProtocolType?: string
      ingressName?: string
      domain?: string
      path?: string
      secretName?: string
      annotations?: [...{ name: string, value: string }]
      class: *"nginx" | string
      classInSpec: *false | bool
    }]
  }
}

Practical Cases

Stateless Component Release : An application is defined as an OAM Application containing a stateless component. Custom traits are bound to the component, and independent release plans are scheduled so that workloads and network topologies do not interfere with each other.

Helm Chart Deployment : BizWorks provides a template center for Helm chart upload, update, download, and deletion. Helm‑type components are declared in the same Application, enabling deployment, rollback, and removal through KubeVela.

Results and Benefits

Platform‑wide deployment and operation capabilities reduced operational labor by ~50 % and eliminated product‑switching costs in public‑cloud scenarios.

The flexible trait mechanism simplifies routing configuration.

One‑click test‑environment provisioning shortened setup time from 3–6 hours to ~15 minutes.

The unified OAM application model increased multi‑cloud resource declaration efficiency by nearly 100 %.

Scale: >500 public‑cloud clusters hosting thousands of applications; >100 private‑cloud sites supporting >100 clusters and hundreds of applications.

Future Roadmap

Visual batch rollout using Kruise Rollout together with KubeVela for stateless components and Helm charts.

Elastic scaling compatible with Alibaba Cloud Kubernetes (ACK) and native Kubernetes HPA.

Community contributions to convert custom definitions into KubeVela addons.

Canary releases with advanced traffic control and gray‑release strategies.

Further Resources

Project repository: https://github.com/oam-dev/kubevela

Official site and documentation: https://kubevela.io