How to Build an Application‑Centric Kubernetes Platform with OAM

Background

This article is the second part of a July 2020 webinar series on building a unified, standardized application‑management platform on Kubernetes using the Open Application Model (OAM). It focuses on concrete steps to create an application‑centric Kubernetes environment.

Four Architectural Layers

Application‑Layer Drive – Define custom resources (CRDs) and controllers on top of Kubernetes to expose user‑facing APIs such as pipelines or custom workloads.

Application‑Layer Abstraction – Treat the CRDs and controllers as an abstraction layer; existing projects like Tekton or Istio can serve as drivers.

Plugin Capability Management – Register installed plugins (e.g., Tekton, KEDA, Istio) in a capability registry so users can query whether a specific ability is available.

User‑Experience Layer – Build friendly interfaces (CLI, dashboard, DSL) that operate on the abstracted application layer rather than raw Deployments and Pods.

Open Application Model (OAM)

OAM provides a standardized, extensible framework that implements the four layers above. It defines four core constructs.

Components

Components are versioned definitions of workloads (e.g., Deployment, StatefulSet, Knative Service). Creating or updating a Component triggers the OAM runtime to generate the corresponding Kubernetes resources. The workload implementation is pluggable – any CRD that satisfies the Component interface can be used.

Traits

Traits describe declarative operational capabilities such as autoscaling, traffic routing, or canary releases. They are implemented as ordinary Kubernetes API objects (CRDs) like HorizontalPodAutoscaler, VirtualService, etc. A Trait is attached to a Component through an ApplicationConfiguration.

ApplicationConfiguration

ApplicationConfiguration binds one or more Components with their associated Traits, forming a self‑contained application description. Because it is a single CRD, the whole application can be version‑controlled and applied to any cluster, simplifying GitOps and CI/CD pipelines.

Definition Objects

Definition objects register the available Components and Traits, exposing their version, schema, and conflict rules. They enable a capability registry so that a platform can discover installed plugins without manually inspecting CRDs or controller status.

Practical Benefits

Standardized API reduces UI development effort; a CLI or dashboard can directly create a Component and its Traits.

Self‑contained ApplicationConfiguration simplifies GitOps and CI/CD pipelines.

Capability registration makes plugin discovery and health‑checking straightforward.

OAM runtime is stateless, ensuring high availability and easy scaling.

Roadmap

The OAM project is open source ( github.com/oam-dev) with contributions from Alibaba, Microsoft, and other cloud providers. Future plans include multi‑cluster support via a Scope model and tighter integration of service‑mesh traits.

Key Technical Q&A

Can OAM represent serverless functions? Yes. A Function can be modeled as a Component, for example using Alibaba Cloud Function or Knative Service.

How are custom rules defined? Custom rules are expressed in the spec section of OAM resources. The spec can be strict or flexible depending on the workload.

Does OAM work with Kustomize or other YAML tools? OAM resources are plain YAML CRDs, so any YAML‑manipulation tool (Kustomize, kpt, etc.) can process them.

Stability plan The OAM spec was in alpha in 2020 with a beta release expected later that year. The oam-kubernetes-runtime plugin provides a stable, backward‑compatible runtime.