Open Application Model (Oam) – How to Separate Applications From Infrastructures

Flexibility beyond Kubernetes

Digital platforms are expected to respond quickly to changes in market demand, allowing for the testing of new business models and ideas quickly. This is a mega trend of adaptability in business which is reflected in software development architectures.

Modern microservice oriented applications built using the cloud native paradigm and framework are very often deployed to Kubernetes, as it’s the most popular container fleet management platform.

But, Kubernetes is just one of the deployment targets of the applications.

There are different cloud environments and on premises environments, and there are alternatives to Kubernetes; even more importantly some day another platform will be the number one platform.

We should not limit ourselves to one platform, as we need more flexibility for deployment of our applications. It will be needed in cloud transformations, in hybrid clouds, and in cloud migrations between different cloud providers in multi-cloud environments.

Again, another layer of abstraction to help

What happens at that moment in the IT word, when you want to separate things and create more flexibility, is the creation of another layer of abstraction to separate the application definition from the particular application deployment platform.

Using common abstractions such as a component and then translating those abstractions and definitions into platform specific artifacts.

Open Application Model (OAM) is not focused on the infrastructure, but on the application definitions. This focus makes it unique and interesting.

What is Open Application Model (OAM)?

According to the official web page, OAM is “an open standard for defining cloud native apps and building app-centric platforms”.

Emphasizing platforms is also an important sign of our times, especially when we build entire platforms consisting of multiple digital products rather than a single separated app.

→ Learn more about Meeting the Future. Trends & Technology 2021.

Open stands for not being owned by a single enterprise entity, such as one of the giants who would control it and impose their rule over others.

We can think of OAM as an application description language, that is focused on cloud native applications. Right now it’s focused on containers and Kubernetes as a runtime, but it’s not limited to that.

It uses YAML (Yet Another Markup Language) as its grammar for configuration files describing the application.

Application components

Components mean application services and parts, which are deployable independently. Developers declare operational characteristics of the code in runtime-agnostic terms. (source: Microsoft)

Traits

Additional operational functionality that is attached to the application component is specified in Traits. Ingress, autoscaling, volume mapper and others are specified in traits as well.

You can think of traits as plugins of additional infrastructure related information.(source: Microsoft)

Application scope

It’s an option for grouping components with common characteristics. Application scopes may overlap each other as they are for grouping, but are not used to create boundaries.(source: Microsoft)

Application configuration

This is the description of how to deploy the components of the application as a whole. This is a runtime-agnostic description which is then interpreted for the specific runtimes.

Adoption

Support for existing runtimes

Both Kubectl and Helm are supported by OAM.

OAM Kubernetes Runtime is the official OAM plugin for Kubernetes and it is installed using Helm.

So, the most important and popular runtime is well supported.

For instance, Rudr is an open source implementation of OAM done by Alibaba. The Rudr controller runs on Kubernetes and translates the OAM configuration and commands to Kubernetes.

OAM is also supported by Azure cloud services.

→ More about Avenga Cloud Services

Focus on infrastructure

Currently, we are observing an obsession with infrastructure and too much focus is being placed on the autoscalers and/or resource pool management. The real business value comes from the applications and their functionality, not from the way they were deployed.

This mindset shift is needed to embrace Open Application Model (OAM), but it will take time.

Domination of Kubernetes – YAGNI?

One of the most popular terms in IT is YAGNI – You Aren’t Going To Need It. If you have Kubernetes clusters with all the required tooling, why bother with another description language as a translation layer from the abstraction of OAM to concrete deployment scenarios of Kubernetes? We already have a lot of complexity to deal with, enough is enough.

Today, Kubernetes is almost synonymous with cloud native.

However, only the most inexperienced and ignorant may believe Kubernetes will stay forever.  Others understand perfectly that the times will change and there are other options, and there will be even more options in the future.

Using OAM today with Kubernetes is future proofing, which is an additional investment, but it may quickly return when there’s more than just the Kubernetes of today or what it will be in the near future.

The lowest common denominator problem

Higher level abstractions are supposed to support multiple deployment environments. But, these environments are not the same. They differ as a few features are available only in some of them. Abstractions, in order to be universal, are usually looking for what is common among different options. In this case OAM abstractions are the common denominators.

So in other words, by using OAM you don’t utilize 100% of the capabilities of the underlying deployment scenarios. It’s the well known lowest denominator problem and the benefit is the flexibility.

‘Run once, debug everywhere’

This previously used to be an ironic saying about Java. The promise of the abstraction, such as OAM, is that you write specifications once and you can deploy them to any platform that supports the specification.

As we all know this is true, but only in a perfect world. But in the real world, the same abstractions may behave differently depending on the target environment.

Future of Open Application Model

Microsoft and Alibaba are the strongest supporters of the OAM model and have tested its interoperability between Azure, Alibaba Cloud and on premises infrastructures.

OAM is described as something worth looking into and investigating.

However, even its current version is well below the famous 1.0, so it’s something we are watching with great interest.

If you need more DevOps or modern application architecture advice, our architects and DevOps experts are here to help.