From YAML Engineer to YAML Herder
A common trope in the Kubernetes world is that you are not a DevOps engineer or site reliability engineer, but rather a YAML engineer. Everywhere you look, there is another YAML manifest to be wrangled.
Creating, editing, updating, and applying these manifests is the daily grind of the YAML engineer. Tools for inspecting and understanding objects in a cluster are good and plenty, but integrated tools for pre-deployment tasks related to creating, editing, validating and debugging manifests is scarce. As the size and complexity of these manifests grows, trying to manage boilerplate code and finding small differences between your current context and the production cluster you are trying to fix comes close to being impossible. Hours can be spent hunting down trivial mistakes, and those hours are not cheap. Your entire team — or business! — can be blocked while an elusive YAML-indentation holds your production environment hostage.
Attempting to manage YAML files by hand is moving us away from the DevOps ideal of infrastructure as cattle and toward infrastructure as pets. Nurturing each fat-finger mistake or CVE update back to health is a painstaking process. YAML engineers are veterinarians, nursing each individual YAML pet back to health.
There has to be a better way to manage manifests and turn YAML engineers into herders of YAML cattle.
From Cloud Native DevX to OpX
Looking across the aisle to the cloud native developer, we see a totally different world. Modern integrated development environments, like Github Codespaces and Gitpod, are all about accelerating the “inner loop” for the developer, so they can focus on writing code rather than wrangling details. With cloud-based IDEs, even helping a colleague or reviewing code becomes a click away.
Ephemeral dev environments don’t make you lose your current context. Just open a new workspace with their environment, make your edits or comments, and switch back to your work. Being able to describe this process in code reaps many benefits, from reducing configuration drift to creating many possibilities for automation.
We need to find a way to translate the advantage of the cloud native developer experience (DevX) into better operations experience (OpX). YAML engineers do not have the same number of choices to accelerate their inner loop. Code editors will have some support, either natively or via plugins (which probably don’t work well together) or they can choose to use yet another CLI (yech 🤮). What is really needed is a “manifest IDE” that helps with all of these tasks in a well-integrated and consistent way, creating the cloud native OpX.
Monokle: Bringing OpX to Cloud Native
Monokle is your open source YAML IDE to bring real OpX to the cloud native world. Monokle makes it easy to manage and debug YAML manifests before you deploy them to your cluster.
To begin with, Monokle helps you quickly get a high-level view of your manifests, along with their contained resources and relationships. It allows you to visualize and navigate resources both within and outside your cluster, and diff them against any changes you want to make. It validates references between resources to ensure you haven’t misspelled an object name or namespace, and lets you fix those interactively to make sure your changes are getting the job done.
Once you understand how your manifests work and work together, Monokle lets you easily edit resources without having to learn or look up YAML syntax. You can refactor manifests while still maintaining the integrity of names and references throughout all of them. Finally, if you are using kustomize or Helm, you can preview and debug the resources they generate; validate their links, values, etc. You can even compare a set of generated resources to those already running in your cluster, all to ensure that when you hit the “deploy” button, all will go as smoothly as you had promised in the pre-release meeting.
Monokle brings OpX to YAML engineers who want to turn their YAML manifests into cattle, rather than having to treat them like pets.
Monokle sits squarely between traditional developer IDEs and operational cluster dashboards. IDEs are great at managing individual manifests, but generally fail to give the “big picture” when it comes to providing a manifest-centric view of defined resources and their relationships and related workflows. Cluster dashboards, on the other hand, generally don’t provide any functionality for working with manifests. They are all about inspecting and managing resources already running in your cluster and do not focus on pre-deployment artifacts or workflows.
Monokle fills this gap by providing a holistic view of your Kubernetes manifests and focusing directly on related workflows — editing, validation, debugging, diffing, deploying, etc. Monokle works nicely together with both IDEs and cluster dashboards, complementing them with manifest-centric functionality and workflows.
Getting Started with Monokle
Monokle is in its open source infancy; there are so many directions it could take, problems to solve and users to make happy! Ultimately though, it’s about making life easier for the people managing manifests. If you are looking to improve your cloud native OpX, give Monokle a try. Download it or build from GitHub, and let us know what we can do to make you a happier YAML engineer.
Links
- Get Monokle on GitHub.
- Get in touch with us on Discord.
- Check out monokle.io for content and videos.
