Open Application Model (OAM) vs DevOps: Why OAM is a Step Backward

Introduction

The Open Application Model (OAM) was introduced as a way to standardize application deployment configurations across different environments. It separates the concerns between developers, operators, and infrastructure providers, allowing developers to focus purely on application development while operators handle deployment and management.

At first glance, OAM seems like a promising approach to simplify cloud-native application deployment. However, when viewed through a DevOps lens, OAM introduces an unnecessary abstraction layer that contradicts modern deployment practices. In this blog, we’ll explore why OAM feels like a step backward and how DevOps-friendly alternatives such as Helm and Terraform provide better standardization.

Understanding OAM with an Example

Let’s take a simple example of a web application with a database. In an OAM-based deployment, the architecture is divided into distinct layers:

• Component (Business Logic) – Defines the application (e.g., a frontend, a backend, or a database component).
• Traits (Operational Configurations) – Handles scaling, networking, monitoring, etc.
• Application Configuration – Binds components with operational traits.

OAM Example for a Web Application

Below is an OAM YAML definition for a simple Nginx-based frontend with autoscaling enabled:

apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: web-app
spec:
  components:
    - name: frontend
      type: webservice
      properties:
        image: nginx:latest
        ports:
          - port: 80
      traits:
        - type: autoscaler
          properties:
            min: 2
            max: 5
            cpuUtilization: 70

This separates the application logic (frontend component) from operational aspects (autoscaler trait). While this structure might seem useful for standardization, it creates more problems than it solves in a DevOps environment.

Why OAM Contradicts DevOps

1. Reintroducing Silos in Deployment

One of the core principles of DevOps is breaking down silos between development and operations. OAM, however, reintroduces these silos by forcing a strict separation of concerns:

• Developers only write application logic (components).
• Operators must handle deployment using OAM runtimes like KubeVela.

This contradicts the Shift-Left approach in DevOps, where developers are encouraged to take more responsibility for deployment configurations using Infrastructure as Code (IaC).

2. Extra Translation Layer = More Overhead

In a typical Kubernetes-based deployment, developers define their apps using Helm charts, Terraform, or Kubernetes YAMLs. With OAM, however, an additional translation step is needed where:

1. Developers define OAM components.
2. Operators translate these into Kubernetes manifests using KubeVela.
3. The OAM runtime applies these configurations to Kubernetes.

This adds unnecessary complexity and creates a single point of failure—if the OAM runtime (e.g., KubeVela) fails, the entire deployment model breaks.

3. Existing DevOps Tools Already Solve Deployment Standardization

OAM claims to solve deployment standardization, but DevOps teams already have mature tools that do this effectively:

• Helm – Standardizes Kubernetes deployments with reusable Helm charts.
• Terraform – Automates multi-cloud and infrastructure provisioning.

Instead of adding another abstraction layer, organizations can use Helm/Terraform to achieve the same (or better) deployment standardization.

4. Limited Adoption in the Industry

Despite being introduced by Microsoft and Alibaba, OAM has not seen widespread adoption. The Kubernetes ecosystem already provides well-established deployment patterns, making OAM feel like a reinvention of the wheel rather than an innovation.

When OAM Can Be a Good Option

While OAM introduces unnecessary complexity for DevOps-driven teams, it might be a viable option in specific scenarios:

1. Enterprises with Strict Separation of Roles – Organizations with large teams where developers, operators, and infrastructure engineers have distinct responsibilities might find OAM useful for enforcing boundaries.
2. Multi-Cloud and Hybrid Cloud Environments – If an enterprise needs to run applications across AWS, Azure, on-prem, and edge computing environments, OAM’s abstraction layer can provide a standardized model.
3. Highly Regulated Industries – Sectors like banking, healthcare, or government, where compliance and strict governance require clear separation of concerns in deployment workflows.
4. Organizations Looking for a Deployment Framework – If a company lacks an established DevOps workflow, OAM could serve as a structured approach to application lifecycle management.

However, even in these cases, organizations should evaluate whether existing tools (Helm, Terraform, GitOps) can meet their needs before adding the OAM layer.

Better DevOps-Friendly Alternatives to OAM

If standardization and simplicity are the goals, here are two DevOps-friendly approaches that are far superior to OAM:

1. Helm: The Standard for Kubernetes Deployments

Helm is the de facto standard for Kubernetes application packaging and deployment. It allows developers to define templates and override configurations with values.yaml, enabling easy reuse across environments.

Example: Deploying an App Using Helm

helm create my-app
helm install my-app ./my-app-chart --values=my-values.yaml

Why Helm is better than OAM:

• Direct integration with Kubernetes (no need for an OAM runtime).
• Developers and DevOps teams work with the same toolset.

2. Terraform: Infrastructure as Code (IaC) for Cloud & Kubernetes

Terraform enables declarative infrastructure management and is widely used for multi-cloud deployments.

Example: Terraforming a Kubernetes Deployment

resource "kubernetes_deployment" "nginx" {
  metadata {
    name = "nginx"
  }
  spec {
    replicas = 3
    container {
      image = "nginx:latest"
      port {
        container_port = 80
      }
    }
  }
}

Why Terraform is better than OAM:

• Works across AWS, Azure, GCP, and Kubernetes.
• No additional abstraction layer required.

Conclusion: OAM is a Step Backward for DevOps

OAM was created to simplify deployment configurations, but in practice, it:
Reintroduces silos by separating development from deployment.
Adds unnecessary overhead with an extra OAM runtime layer.
Duplicates functionality already covered by Helm and Terraform.

Instead of adopting OAM, DevOps teams should focus on proven tools like Helm and Terraform, which provide better deployment standardization without breaking DevOps principles.

Skip OAM—embrace DevOps.