Why OAM Is the Key to Simplifying Cloud‑Native Application Management

Background

OAM (Open Application Model) is a joint Alibaba‑Microsoft community specification for building and delivering cloud‑native applications. It introduces a new application definition, operation, distribution, and delivery model to push application management toward “light‑weight operations” and drive the next generation of cloud‑native DevOps.

AWS ECS CLI v2 Development Principles

Default to modern applications. Created applications should be serverless, infrastructure‑as‑code, observable, and secure.

Focus on architecture, not infrastructure. Developers specify the desired architecture; the underlying resources are automatically provisioned.

Operations as part of the workflow. Application lifecycle includes operational tasks such as troubleshooting and resolution.

Continuous delivery. Application upgrades should integrate seamlessly with CI/CD pipelines.

These principles reflect user demands for modern, architecture‑centric, operationally integrated, and continuously deliverable applications.

Value of OAM

OAM addresses the above user demands through a set of eight core values.

1. Cloud‑Native

OAM application definitions are declarative and align with Kubernetes API, allowing seamless deployment as Custom Resources.

The definition is self‑contained, describing all lifecycle aspects of an application.

2. Platform‑Agnostic & Runtime‑Agnostic

OAM does not lock applications to a specific platform or runtime. It can run on Kubernetes, ECS, Docker, or Serverless environments, and the same OAM description works across them.

3. Infrastructure as Code

OAM extends the declarative model of Kubernetes to include infrastructure resources. By writing OAM‑compliant YAML, users can provision cloud resources such as Alibaba Cloud ROS components.

Example: provisioning a NAS file system and mount target.

apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: nasFileSystem
  annotations:
    version: v1.0.0
    description: >
      component schematic that describes the nas filesystem.
spec:
  workloadType: ros.aliyun.com/v1alpha1.NAS_FileSystem
  workloadSettings:
    ProtocolType: NFS
    StorageType: Performance
    Description: xxx
  expose:
    - name: fileSystemOut
---
apiVersion: core.oam.dev/v1alpha1
kind: ComponentSchematic
metadata:
  name: nasMountTarget
  annotations:
    version: v1.0.0
    description: >
      component schematic that describes the nas filesystem.
spec:
  workloadType: ros.aliyun.com/v1alpha1.NAS_MountTarget
  workloadSettings:
    NetworkType: VPC
    AccessGroupName: xxx
    FileSystemId: ${fileSystemOut.FileSystemId}
  consume:
    - name: fileSystemOut
  expose:
    - name: moutTargetOut 
---
apiVersion: core.oam.dev/v1alpha1
kind: ApplicationConfiguration
metadata:
  name: nas-demo
spec:
  components:
    - componentName: nasMountTarget
      traits:
        - name: DeletionPolicy
          properties: "Retain"
    - componentName: nasFileSystem
      traits:
        - name: DeletionPolicy
          properties: "Retain"

4. Architecture‑Focused, Not Infrastructure‑Focused

Users declare the desired architecture via the WorkloadType field (e.g., Server, RDS). The OAM controller maps this to the appropriate underlying resources, allowing users to think in terms of components rather than concrete infrastructure.

5. Integrated Operations Management

Operations capabilities are expressed as Traits bound to Components, making operational concerns part of the application lifecycle.

6. Transparent Integration

Just as Docker images standardize build artifacts, OAM’s standardized application description enables seamless integration across different systems.

7. Role Separation

OAM decouples the responsibilities of application developers (Component management), operators (Component composition and Trait binding), and infrastructure providers (mapping Traits to concrete resources), simplifying each role’s focus.

8. Elastic Scalability

OAM definitions are extensible; new Workload types and custom Traits can be added, integrating smoothly with Kubernetes CRD + Operator extension mechanisms.

9. Modular Collaboration

By separating concerns into Workloads and Traits, OAM enables modular reuse. A registry of CRDs can serve as a marketplace for ready‑made components and operational capabilities, further simplifying application assembly.

Future Outlook

As OAM matures, building applications will become increasingly straightforward, with infrastructure automatically matched to architectural requirements, enabling rapid reuse of modular capabilities and positioning OAM as the inevitable choice for cloud‑native application development.