An Application-First Approach to DevOps | by Vaibhav Rajput | Jun, 2022

Standardizing the Kubernetes infrastructure to give Devs the ease and Ops the freedom

Photo by Markus Winkler on Unsplash

This article is about one of the few implementations of an amazing and crucial concept for a fast-paced development environment, the Open Application Model (OAM).

OAM is a concept that promotes the idea of developers focussing completely on their application and not on the knowledge of underlying infrastructure. It states that the approach should be application-first, extensible, and run-time agnostic. You can read more about it here.

1*tHdGB8D2gZ2VD7omnsN oQ

Coming back to our topic, the implementation of OAM that I am talking about here is KubeVela. I mentioned it briefly in my last post on Crossplane and thought that this is the right time to go deeper into it.

To get started with KubeVela, simply follow the installation steps.
For managing resources with more ease, you can optionally install vela CLI. For a Mac system, you can simply use brew like so

brew update
brew install kubevela

Once you have vela CLI ready, you can install the core components (CRDs) on your cluster simply by running

vela install --version v1.4.2

If you wish to skip the vela CLI, you can also install it directly using helm like so

helm repo add kubevela
helm repo update
helm install --create-namespace -n vela-system kubevela kubevela/vela-core --version 1.4.2 --wait

You should see an output like the following:

says kubevela has been added to your repositories, then other text. at the end, shows an image of a boat

As part of the installation, a few CRDs are installed.

1*ZcMbq8YUZ4 I5A6RVhGN8Q

There’s quite a lot of stuff here but we’ll focus on the highlighted ones only.

Application is what the developer would be creating, containing only the details specific to the application and its configuration. There would be no Kubernetes resources mentioned in this file. Let us create one for ourselves below:

Simply apply this manifest like so:

1*4GDQ3Q9NuA47K AwF omFg

And now if you check the resources, you’ll see quite a few of them created for you based on just this code.


But how did I know what all resources I want to create?

For this, take a look back at line number 8 of that manifest. We mentioned webservice as the type of our application. This brings us to the next CRD

There are several predefined componentdefinitions you can use. You can list them like so:

1*sdd2 zP5rVZNSXqShJ 5Qg

The one we used, webservice, is a long-running, scalable, containerized service that has a stable network endpoint to receive external traffic from customers. And hence, it creates a deployment (long-running and scalable) with a stable network endpoint (service and ingress).

There’s plenty of other componentdefinitions you can use but say you have a requirement that isn’t solved by any. Say you have to make some additions to one of them? Or make a new one altogether? Well, both are possible.

To create a custom componentdefinition, you don’t have to start from scratch. Use an existing Kubernetes manifest and run vela def init (more details here).

If you look at one of these component definition YAMLs, you’ll see that they have a schematic block which can be written in cue, Kube, or helm.

I personally prefer cue due to its flexibility but it comes at a cost of learning a whole language. If you don’t want to do that, go for helm or Kube. Also, if you’re familiar with Kustomize, Kube might come easy to you (it’s standard Kubernetes manifest with parameterization).

Lastly, we have the option to extend an existing componentdefinition. You can use it for say, adding horizontal pod autoscaling to the existing webservice application you created above.

This TraitDefinition resource would also be defined quite similarly to componentdefinition in terms of schematic section with a template code written under it. One difference here would be appliesToWorkloads which will define when to trigger this trait. In our case, it would be with deployments, so it would look something like this:

Note that the parameters have a default value min : 1, max : 10 and cpuUtil : 50 which means that the user may or may not pass them in the application definition file.

Just to add, given how efficiently all the resources are packed together in one application, the clean-up is just as easy.


Now, if you check the resources using

kubectl get all,ingress

You won’t find any of these.

OAM, in my eyes at least, is the kind of standardization we need in the DevOps community. And KubeVela is a great example of how it will benefit us.

I should mention that there is one downside of this tool. The documentation wasn’t originally written in English, but was translated into English. So, it’s just not as good as you’d expect.

News Credit

%d bloggers like this: