Microsoft recently announced the Open Application Model (OAM), a specification aimed at describing applications decoupled from their implementation so that there is clear a separation of concerns. OAM is targetting Kubernetes and other platforms.
In the world of DevOps, it is often still necessary to maintain the delineation between development (dev) and deployment (ops) to assist with delivery workflow coordination, and the OAM specification aims to facilitate this. The stated goal of OAM is "to make simple applications easy and complex applications manageable". The initial implementation for the Kubernetes platform is called Rudr and meets many of these stated goals.
The following diagram (courtesy: https://github.com/oam-dev/spec/#introduction) illustrates the different personas and their respective responsibilities and how the different pieces are part of the OAM spec.
In related news, Microsoft also announced Dapr, an open source "portable, event-driven runtime that makes it easy for developers to build resilient, microservice stateless and stateful applications that run on the cloud". Dapr is targeting the dev persona for building microservice applications, and Rudr is focused on the ops persona for running applications.
InfoQ caught up with Vaclav Turecek, principal program manager at Microsoft and one of the spec leads regarding the announcement.
Turecek talks about the proliferation of platforms running on top of Kubernetes, and how OAM is aimed at distinguishing the parts that developers and operators are responsible for, respectively, thereby streamlining the entire software development life cycle. He talks about how some of the other platforms seem to overlap with OAM, and how OAM is unique. Finally, he touches on the OAM community and its roadmap.
InfoQ: What problems does OAM solve?
Vaclav Turecek: When it comes to application development and deployment, we think it is important to distinguish between the parts that developers are responsible for, and the parts that operations is responsible for. Otherwise, if these roles get muddled, it would result in communications mishaps, bugs, or even service outages. OAM attempts to solve this problem by modeling the application according to the roles responsible for building and running apps and operating infrastructure.
For Kubernetes specifically, where we have released a reference implementation called Rudr, we think OAM will help simplify application composition and operations. By and large Kubernetes is focused on container infrastructure. The core resources in Kubernetes like Services and Deployments represent disparate pieces of an overall application. They do not represent the application itself, and there isn’t really a construct that represents an entire application and its operation. OAM provides application constructs that model an application as a whole along with its operational characteristics, like autoscaling, traffic routing, ingress, and so on.
InfoQ: How is OAM unique in the crowded Kubernetes ecosystem space?
Turecek: There is a huge ecosystem of tools and libraries for Kubernetes today. We haven’t seen much in the application modeling space with goals similar to Open Application Model. Helm and CNAB are most commonly compared to OAM – and not just because the creator of Helm and CNAB is also one of the OAM authors, but because they all deal with some aspect of deploying applications.
Helm and CNAB are in fact complementary and, true to the Unix philosophy of solving one problem well, each solve a different problem in this space and work well together. For example, you can describe the components of an application and how to operate it with OAM and deploy that directly to Kubernetes. Have additional dependencies you need to include? Put your OAM definition and dependencies into a Helm chart and install it all together. Need to get that running on a Kubernetes cluster that doesn’t have access to your container images? Put that Helm chart along with the container images into a CNAB bundle and install it that way.
OAM also allows infrastructure operators to configure the underlying systems that provide the operational functionality that OAM applications consume. This means you can plug in a wide range of existing tools and libraries. For example, you could plug in any SMI-compliant service mesh, like Istio or Linkerd, to provide load balancing and traffic routing capabilities that are surfaced through OAM traits. This allows infrastructure operators to satisfy unique operating requirements of their environment, like compliance or security, and create a curated application environment for developers and application operators.
InfoQ: Is OAM aimed for multi-cloud? In other words, is it trying to “standardize YAML” across multiple K8s cloud platforms?
Turecek: The overarching idea with OAM is to standardize the model by which applications are composed and operated, regardless of the environment you end up working in. So as you go from one platform to another, you have a consistent experience, a transferable process, and potential portability. That said, we fully expect the implementing platform capabilities to differ, and the model is designed around this assumption. This is a level above Kubernetes, where Kubernetes is just one supporting platform.
InfoQ: How does the OAM specification define an application and how is it different from Helm?
Turecek: Interestingly, what we found through our research was that nobody could agree on a definition of "application" in a microservices world. The way OAM is designed currently doesn't enforce a rigid "application" structure for services. We have a concept of application scopes that can be used to place application-like boundaries around groups of services. For example, grouping services in a "health" scope where the health of each service in the group is evaluated when any one of the services is upgraded, as a trigger for automated rollback is something application scopes are designed for. This is different from Helm charts, where there is no added functionality to a group of resources.
InfoQ: Finally, who created and maintains OAM? What's the roadmap?
Turecek: OAM is being developed by the creators of Helm, OpenKruise, and Service Fabric, and is currently maintained by engineers from Microsoft and Alibaba Cloud under the Open Web Foundation agreement. Our ultimate goal is to donate the specification to a foundation as the project grows.
The initial implementation for Kubernetes called Rudr is available on GitHub. More detailed information is available in the OAM Specification, including the different personas, their respective responsibilities, etc.