Microsoft opens wider on Open Application Model (OAM)

The Open Application Model (OAM) was initially launched as a partnership between Microsoft and Alibaba Cloud last October.

Microsoft principal program manager Vaclav Turecek now tells us that the OAM has reached v1Alpha2.

OAM aims to provide a standard way to declaratively model applications agnostic of any specific platform, while still allowing each platform that implements the spec to surface its unique features and capabilities.

Also, Microsoft and Alibaba Cloud have joined the Crossplane Project (run by Upbound) to implement the OAM. 

Crossplane is an open source project that enables you to use the Kubernetes API to provision and manage cloud infrastructure, services, and applications.

Further, The Crossplane governance committee has initiated the process of donating the project to CNCF to continue driving the project’s growth.

According to Turecek, OAM provides an extendable model at its core, so that applications can be modeled consistently anywhere without being reduced to lowest-common-denominator feature sets.

3-core OAM elements

OAM applications are made of three basic elements: components, traits and scopes.

  • Components: are the workloads a developer wants to run.
  • Traits: are operational behaviours for those individual components.
  • Scopes: are a way to group components around common operational behaviours and so build applications.

These elements come together in a simple configuration file that defines all or part of an application.

“The key to OAM’s design is that every platform that implements the spec can choose which types of components, traits and scopes to support, as long as the platform implements the overall model as described in the spec. This allows all platforms to surface their unique features and capabilities through a consistent application model. The v1Alpha2 draft of OAM introduces subtle changes with big impacts on how platforms can implement the specification,” wrote Turecek, on the Microsoft open source blog.

He further notes that with developers need to understand which infrastructure an app will run on before they think about deployments, a process that typically involves a degree of coupling (between app and infrastructure)… but now we’re talking about the move to decouple these two entities.

Decoupling delights

To help decouple the application from the infrastructure, OAM defines three distinct roles: application developer, application operator, and infrastructure operator. 

Because it is an application model, the OAM spec focuses mainly on the first two roles. 

“Crossplane defines the same three roles, but mainly focuses on the infrastructure operator role. As it turns out, OAM and Crossplane naturally complement each other: OAM defines the application and Crossplane defines the infrastructure on which the application runs,” said Turecek.

Separation of concerns

We’re moving forwards to a means of compute characterised by the ‘separation of concerns’ (and in this case that’s between app and infrastructure as already noted), but while still needing to retain management capabilities over the state, role, functions and behaviour of those concerns at every level of the IT stack… and this effort is designed to deliver exactly on that technology goal.