Crafting the YAML to install applications on Kubernetes can be time consuming. Not just to do but to learn. There are a lot of Kubernetes objects and the each have a lot of options. If you were to print the API documentation (you can find v1.18 here) that describes the objects it would be well over 1,000 pages. This only includes the latest version of APIs and only the objects you might use when deploying an application rather than everything. This doesn’t include documentation detailing how to connect these objects together to deploy applications.

I’ve also heard it said that Kubernetes manifests are like assembly or machine code. Sure you can write a program in assembly or machine code but we typically use higher level languages and compile to machine code. Kubernetes objects are verbose, you repeat yourself when using multiple objects needed to represent an application, and there are so many things we often fail to use all that we should because we spent so much time getting things running. PodDisruptionBudget comes to mind as an example of this.

Then there is the matter of different platforms. At a high level this could be the difference between something like Kubernetes and Nomad. But, different platforms built on Kubernetes are going to vary a great deal more. For example, are applications exposed via Ingress or a service Mesh like Istio? Any time you want to deploy an application to a variation or an entirely different platform you have a lot of work to do in YAML creation.

Wouldn’t it be great if there was a higher level construct you could describe your application in that was simpler? Maybe one that covered 50-80% of use cases and the common situations.

Last year I saw two such efforts. One was a prototype I wrote to test the idea. It could take a simple description for an application (e.g., WordPress with a database) and create the Kubernetes manifests needed to deploy it. It could also create a Helm chart. The other effort was the Open Application Model (OAM). This is a spec to describe applications. This can be “compiled” into Kubernetes manifests or something for another platform. The descriptions look like Custom Resources and an initial implementation, named rudr, is a Kubernetes controller.

But, these are prototypes and shiny new things. Is there something that already exists, describes applications, and is in wide use?

Enter Docker Compose Spec

Docker Compose has been used to describe applications for some time. There are hundreds of thousands of compose files on GitHub today. And we know compose files can be turned into Kubernetes manifests thanks to the Kompose project. Kompose has long been a project to translate the files.

Compose is now embracing the idea of a higher level spec that can be “compiled” for different platforms. This is through the Compose Spec. Docker just announced it.

I think this is a great thing for developers. While Kubernetes has the manifest sharing problem mostly solved, the tools to make Kubernetes approachable to developers are in their infancy. An easier more concise way to describe applications would go a long way to making the experience better.

Plus, this makes applications more portable. Not just between major platforms but between different platforms built on Kubernetes.