How KubeVela Workflow Transforms SAE’s Serverless Architecture for Faster Cloud‑Native Upgrades

Background and Challenges

Serverless Application Engine (SAE) is a Kubernetes‑based, serverless‑plus‑microservice cloud platform that hosts various business applications. Its Java‑centric architecture simplifies one‑click deployments but introduces three major challenges: non‑standard, complex operational processes; scaling release efficiency under high concurrency; and rapid integration of internal serverless capabilities while keeping development costs low.

Why Choose KubeVela Workflow?

Existing cloud‑native workflow projects like Tekton and Argo are mature, yet KubeVela Workflow offers a distinct advantage: each workflow step is designed around cloud‑native IaC principles, allowing custom functions to be invoked directly rather than merely launching containers. Steps are defined via CUE language, enabling reusable, abstracted operations.

Workflow Step Definition

Each step type corresponds to a WorkflowStepDefinition resource. Developers can write these definitions in CUE or reuse community‑provided step types. Parameters are declared in a parameter field, and at runtime the controller injects actual values to execute the CUE code as if calling a function.

apiVersion: core.oam.dev/v1alpha1
kind: WorkflowRun
metadata:
  name: build-push-image
  namespace: default
spec:
  workflowSpec:
    steps:
    - name: build-push
      type: build-push-image
      properties:
        context:
          git: github.com/FogDong/simple-web-demo
          branch: main
        image: fogdong/simple-web-demo:v1
        credentials:
          image:
            name: image-secret

Case Study 1 – Automated Operations

SAE engineers need to pre‑warm base images across multiple regions. The manual process involves ACR image builds, multi‑region pushes, and template generation, which is error‑prone and time‑consuming. By modeling each action as a programmable step (e.g., HTTP request to ACR, conditional error handling, multi‑cluster ImagePullJob deployment), the workflow becomes reusable and visualized via a dashboard.

Invoke ACR to build an image and wait for completion.

Handle build failures.

On success, trigger image‑cache construction and stream logs.

Use a step group to pre‑heat the image in Shanghai and US‑West clusters via ImagePullJob resources.

Case Study 2 – Optimizing the Release Pipeline

The original SAE release flow relied on a Java executor that polled task queues and Kubernetes resources every second, leading to latency and tight coupling. By replacing this with KubeVela Workflow, each release step becomes an IaC‑defined CUE module that calls SAE micro‑service APIs or directly manipulates Kubernetes objects, enabling event‑driven execution and millisecond‑level state updates.

Case Study 3 – Rapid Feature Rollout

To support multi‑language canary releases, SAE integrates Kruise Rollout and ALB. A single KubeVela Workflow orchestrates ALB traffic splitting, Kruise rollout updates, and SAE business components, allowing new features to be launched by merely adding or updating a step definition rather than writing new Java code.

Conclusion

Adopting KubeVela Workflow enabled SAE to achieve faster, more reliable releases, lower development effort, and scalable automation built on serverless infrastructure. The open‑source solution provides over 50 built‑in step types (e.g., image build, Terraform, conditional wait, notifications) that can be combined to create end‑to‑end CI/CD pipelines.

References

GitHub repository: https://github.com/kubevela/workflow

Documentation and examples: https://github.com/kubevela/workflow#try-kubevela-workflow

Multi‑app orchestration: https://github.com/kubevela/workflow/blob/main/examples/multiple-apps.md

Environment initialization with Terraform: https://github.com/kubevela/workflow/blob/main/examples/initialize-env.md

Request‑and‑notify example: https://github.com/kubevela/workflow/blob/main/examples/request-and-notify.md