KubeVela — taming Kubernetes complexity with one interface.

Deep dive 4 of the KubeCon Mumbai 2026 series. Gowtham S and Jerrin Francis (Cloud Platform, Guidewire Software) made the case that platform fragmentation — developers forced to master compute, networking, security, observability and Terraform just to ship a service — is the real tax on cloud-native productivity. Their answer: the Open Application Model (OAM) implemented by KubeVela, an application-centric delivery control plane that lets platform teams publish opinionated building blocks and lets developers describe what they want in one YAML file — including cloud resources — while the platform handles how.

This talk is the natural capstone of the platform-engineering cluster in the series. DD01 showed one product's evolution, DD02 showed how to share a platform safely, DD03 showed how to observe it. This one asks the developer-experience question: how do you hand all that platform power to application developers without making them learn the entire iceberg underneath?

The setup — Kubernetes is the OS for AI now

The presenters opened with a stat from the 2025 CNCF Annual Survey: Kubernetes is now the de facto "operating system" for AI, with production use hitting 82%. That framing matters — if Kubernetes is the substrate everything runs on, then the interface to that substrate becomes the highest-leverage thing a platform team owns. A bad interface taxes every developer, every day.

The problem — the complexity iceberg

The central image was a complexity iceberg. A developer just wants to deploy a service. Instead, to do it "properly" on Kubernetes, they're forced to master five whole disciplines:

Discipline	What they're forced to learn
Compute	Deployments, HPA, Pod Disruption Budgets
Networking	Ingress, service mesh, TLS, DNS
Observability	Prometheus, Grafana
Security	RBAC, OPA, Secrets, Vault
IaC	Terraform modules, state files

Most of that iceberg is below the waterline — invisible to the developer until it sinks them. And the IaC layer in particular was hitting a hard ceiling:

• Monolithic state. Massive Terraform state files became unwieldy, extending deployment times and creating a fundamental scalability bottleneck.
• The drift dilemma. Live infrastructure constantly diverged from code due to manual changes — eroding confidence and complicating operations.
• The "two-plane" problem. Developers had to juggle two distinct toolchains — kubectl for apps and Terraform for cloud resources — that don't share a model or a reconciliation loop.

The solution — OAM, the Open Application Model

The conceptual fix is OAM: a specification that brings an application-first approach to cloud-native systems by cleanly separating the concerns of application developers from platform engineers — moving away from the traditional infrastructure-first mindset. The developer's experience goal, in the presenters' words: "deploy this image, expose it, scale it, and done."

But they were careful to add the caveat: OAM is just the blueprint. A blueprint defines the structure; execution brings it to life. That execution engine is KubeVela.

KubeVela — the execution engine

KubeVela is a modern, application-centric continuous-delivery control plane built on Kubernetes to implement OAM and build opinionated Internal Developer Platforms (IDPs). The "opinionated" word is doing real work: the platform team bakes in the right defaults so developers fall into the pit of success.

Its vocabulary is small and worth learning, because once you have these six nouns the whole model clicks:

Term	What it is
Application	The unified deployment that ties all aspects together — the top-level object.
Component	A deployable unit: a microservice, database, messaging system — the core workload.
Trait	Bolt-on operational features attached to a component: scaling, monitoring, encryption, versioning.
Workflow	The delivery pipeline / orchestration logic — defines steps and dependencies (a DAG).
Policy	Rules and constraints at the application level: multi-cluster, security, lifecycle.
Addon	A plug-and-play module for integrating extra capabilities or third-party tools.

How it works — the two-persona split

• The platform team defines reusable, secure building blocks (OAM Components & Compositions) that encapsulate best practices and governance, and publishes them to a central library.
• The application developer declares their needs in a single, simple YAML file and "claims" infrastructure (like a database) without needing to know the underlying cloud-specific implementation. Traits like traffic management, canary/blue-green/A-B, autoscaling, and identity attach declaratively.

What an Application looks like

The whole deployment is modeled as a DAG. A single manifest carries components, their traits, app-level policies, and the rollout workflow:

kind: Application
spec:
  components:
    - name: express-server
      type: webservice
      properties: { image: demo/hello-world, port: 8000 }
      traits:
        - type: ingress
          properties: { domain: testsvc.example.com, http: { "/": 8000 } }
  policies:
    - type: security
      properties: { audit: enabled, secretBackend: vault }
    - type: deployment-insights
      properties: { provider: arms|prometheus, leadTime: enabled,
                    frequency: enabled, mttr: enabled }
  workflow:
    - type: blue-green-rollout   # post-render, partition: "50%"
    - type: traffic-shift        # partition: "50%"
    - type: rollout-promotion    # manualApproval: true, rollbackIfNotApproved: true

Read it top to bottom and you see the magic: the component is the app, the trait exposes it, the policies enforce security and wire up DORA-style delivery insights (lead time, frequency, MTTR), and the workflow encodes a real progressive-delivery pipeline — blue-green, 50% traffic shift, manual approval with automatic rollback — all in one declarative file the developer can read.

Killing the state file — Crossplane for cloud resources

The other half of erasing the two-plane problem is provisioning cloud resources the Kubernetes way. The talk reached for Crossplane, which extends Kubernetes to manage external infrastructure — AWS resources, Datadog, SaaS tools — as native Kubernetes objects:

Crossplane capability	Why it beats the Terraform model
Custom APIs (XRDs)	Define org-specific infra APIs like "Database" instead of raw cloud primitives.
Continuous reconciliation	Actively monitors and enforces desired state, auto-correcting drift — unlike Terraform's "apply-once."
No state files	Desired state lives in etcd — no monolithic state file to lock or corrupt.
Unified API	One interface for AWS, Azure, and GCP — Kubernetes as a universal control plane.

"One interface" — the payoff

With KubeVela over an OAM model plus a Crossplane-style provisioner, a single workload definition deploys code and provisions the cloud resources it needs. The demo's tagline said it all: "One KubeVela App, Three Provisioners, Two Clouds." A Team-A application manifest declared a backend-service (webservice + gateway trait), an aurora-db (aws-rds-aurora), and an s3-bucket — app and infra, one file, one apply.

What it brings to the table, in the presenters' list:

• Build opinionated IDPs with governance baked in.
• Avoid exposing platform-level configuration to developers (which would require upskilling them on the whole iceberg).
• Abstract away boilerplate and redundant platform-level logic.
• Get rid of error-prone piles of YAML and reduce the misconfiguration surface area.
• One interface for the developer to deploy apps and cloud resources.

The forward-looking bit — GenAI on Kubernetes, same interface

The most timely slide showed the exact same model applied to an AI workload — tying this talk straight into the AI cluster later in the series. One Application manifest deployed a model, ran llm-d inference, and provisioned its storage:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata: { name: llama-chat, namespace: team-ai }
spec:
  components:
    - name: model-server
      type: llm-d-inference
      properties:
        model: meta-llama/Llama-3.1-8B
        modelSource: s3://team-ai-models/llama
        replicas: 2
      traits:
        - type: gpu
          properties: { count: 2, product: nvidia-a100 }
    - name: model-store
      type: aws-s3-bucket
      properties: { bucketName: team-ai-models, versioning: true }

The same component/trait grammar that deploys a web service now deploys an LLM with GPU traits and an S3 model store. That's the thesis proven: if your interface is right, "deploy a model" is no harder than "deploy a service." Compare this with the GPU-scheduling reality in the Zero GPU deep dive and the serving concerns in Serving and Scaling — KubeVela is the friendly front door; those talks are what's behind it.

Looking ahead — the future is platform engineering

The closing argument: KubeVela combined with ACK, KCC, or Crossplane delivers cloud-agnostic, Kubernetes-native platform engineering — treating infrastructure as code (the good kind, continuously reconciled), eliminating fragmentation, and enabling true self-service. The four benefits: unified control (Kubernetes-first removes monolithic state complexity), developer velocity (application-centric abstractions with governance), reliability (continuous reconciliation beats static apply-once tools), and scalability (reusable components let a small platform team scale impact org-wide).

FAQ

OAM vs KubeVela — what's the difference?

OAM is the specification (the blueprint): an application-first model that separates developer and platform concerns. KubeVela is the engine that implements OAM on Kubernetes and actually executes the deployment. Blueprint vs builder.

How is this different from just using Helm?

Helm packages and templates Kubernetes manifests, but the developer still sees and owns the Kubernetes complexity. KubeVela's OAM model exposes a curated, application-level interface (components + traits) backed by platform-owned building blocks, and extends to cloud resources via Crossplane/ACK/KCC — so developers never touch the iceberg below.

Why Crossplane instead of Terraform?

Continuous reconciliation vs apply-once. Crossplane stores desired state in etcd (no state file to lock/corrupt), auto-corrects drift, and exposes one Kubernetes-native API across clouds — collapsing the "two-plane" problem. It's swappable with ACK or KCC; the pattern matters more than the tool.

Does this lock developers into KubeVela?

The underlying model is OAM (an open spec) and the resources are standard Kubernetes/Crossplane objects, so the lock-in is to standards rather than a proprietary product. The opinionated IDP is yours — the platform team owns the building blocks.

Takeaways

• The complexity iceberg is the real tax. Developers shouldn't need to master compute, networking, security, observability, and Terraform to ship a service.
• OAM splits "what" from "how." Developers declare intent; platform engineers own the governed building blocks.
• KubeVela executes OAM with a six-noun grammar: Application, Component, Trait, Workflow, Policy, Addon.
• Crossplane kills the state file — cloud resources become continuously-reconciled Kubernetes objects, erasing the two-plane problem.
• One interface, apps + infra + AI. The same manifest deploys a web service or an llm-d model with GPU traits.
• Opinionated IDPs scale a small platform team org-wide by reducing the misconfiguration surface to a curated set of blocks.

Next in the series — Deep dive 05: Beyond the Primary CR, which goes one layer deeper into how the operators behind these abstractions are actually built.

References

• KubeCon Mumbai 2026 — Day 1 index · the rest of the series
• KubeVela · Open Application Model · the engine and the spec
• Crossplane · cloud resources as Kubernetes objects (or ACK / KCC)
• CNCF Annual Survey 2025 · the 82% production-Kubernetes figure