Guardrails Can Be the Common Language to Bring Dev and Ops Together
With the rise of Kubernetes adoption and overall expansion of the cloud native landscape, DevOps certainly isn’t dead, but it is definitely changing. The rise of roles like platform engineer is clearly trying to address this strange adolescence that DevOps is going through in the cloud native era.
When adopting a platform as complex as Kubernetes, even the most polished and smooth-running DevOps pipelines have stumbled across gray areas in cloud native workflows that hadn’t been considered prior to the adoption of K8s, forcing teams to grow and adjust. New-world DevOps teams are beginning to take shape, many of which are being led by the ever-shining platform engineering star.
With a focus on empowering all stakeholders in this growth process, platform engineers and DevOps teams are challenged to find ways to break down the ever-existing silos between Devs and Ops to achieve a reliable, fast and frictionless delivery process.
While Devs and Ops might call different corners of the Kubernetes configuration life cycle home, they do share a common goal: Deploy the desired state so their applications run smoothly.
Unfortunately, this means they don’t necessarily share a common language. I’m not talking about how they talk on Zoom calls or in Slack messages to one another — there are already plenty of ways to navigate those language barriers. I’m talking about how these folks — developers, DevOps engineers and platform engineers — keep applying new trends in development culture, like shift left, while struggling to find cloud native tools that work best for their emergent blended workflows.
Often, chosen tools seem ideal for their perceived area of focus, like an IDE versus a cluster management platform, but all are simply creating more languages that are all trying to determine the same thing: whether or not the cluster and its applications are working as desired.
Language barriers in tooling creates cracks where mistakes start to slip in. And when the environment is complex and the cost of mistakes is high, as with Kubernetes, those with limited experience and those who can’t see the complete picture start to operate out of fear. To avoid introducing costly errors, they stop developing altogether.
What these blended teams need to do to shift left properly is create a common language for answering questions about desired state and cluster health.
Don’t worry, I’m not about to say the common language should be YAML.
The Complicated Landscape of Kubernetes Tooling
Despite the blending of tasks that comes with shift left, like moving testing and validation to the precommit phase rather than the tail end of the CI/CD pipeline, each person involved in the Kubernetes configuration life cycle arrives to work with different ideas about the right tool for their job. They still operate out of a siloed mindset.
- Configuration developers and backend engineers, for example, do most of their work in an integrated development environment (IDE), like VSCode, using multiple plugins to create a comfortable environment for authoring in YAML, validating changes and interacting with git for collaboration. They likely don’t think their tool choice has any implication on those who pitch in on other tasks in the configuration life cycle, like cluster management, but they can’t see the full picture.
- DevOps engineers are either asked to fix problems other people created, or rest firmly on the critical path to deployment, spending their days fielding questions from everyone else around the configuration life cycle instead of adding their high-value contributions. They need tools designed for collaboration but don’t want to waste time digging through Slack messages or git commits to understand where they could smooth out operations problems or add key optimizations.
- Platform engineers are responsible for picking a dozen tools, developing the integrative “glue” with webhooks or APIs to get them all to work together smoothly, and then convincing everyone to hop aboard this new “paved road” experience in an internal development platform. For their development and engineering peers, this platform abstracts away all the complexity by providing a simple self-service/ClickOps experience. But behind the curtain, platform engineers are constantly working to improve internal development platforms by bringing on even more tools and writing more code to minimize conflicts between multiple languages.
Many larger organizations create a common language through platform engineering. It’s a perfectly valid and proven strategy; there are engineers on staff to keep the internal platform online. It’s not an easy move for startups or smaller outfits because of how difficult (and expensive) it can be to hire a successful platform engineering team on top of the application and DevOps engineers required to build applications and experiences.
Let’s consider another way. Instead of an abstracted internal development platform, there’s a common language that empowers people on all corners of the Kubernetes configuration life cycle: guardrails. By defining (and enforcing) what developers and engineers are not allowed to deploy, they have a common ground for learning new techniques, encouraging each other’s continuous education and deploying better software.
How Monokle Unifies Kubernetes Languages and Life Cycles
Monokle is a set of tools — Desktop, CLI and Cloud — that creates a single common language for the entire life cycle. Instead of each team member arriving with new tools and a different language about how to best create and maintain high-quality Kubernetes configurations, they can create blended workflows that don’t require a dozen tools magically working in sync.
Developers and configuration engineers can use Monokle Desktop to manage their day-to-day work on K8s YAML configurations, which is typically hidden on their laptops and IDEs until they’re finally ready to push their branch and create a pull request into a transparent platform for ongoing collaboration. As they work, Monokle’s guardrails features, like forms that eliminate those papercut-like YAML syntax errors or full-on Open Policy Agent (OPA) validation, prevent errors while instructing them how to improve their configurations in the future.
DevOps engineers can use Monokle’s CLI tooling to add those same features, especially Monokle’s custom validator engine, directly into their CI/CD pipelines for in-depth quality checks at every stage in the configuration life cycle. By doing so, errors are removed from the critical path by deferring questions to the validator, resulting in higher quality.
Platform engineers and other team leaders can leverage Monokle Cloud IDE for Policy Enforcement to define and implement the guardrails that both Desktop and CLI adhere to from a central location. By implementing clear guardrails, errors are prevented from reaching production in the first place. Platform leaders can define and create project-specific policies and rules to reflect business objectives, ensure performance, meet security and compliance criteria, and maximize Git workflows by integrating policy validation into every PR, ultimately achieving consistent, high-quality deployments in less time and with fewer resources.
No matter what version of Monokle these folks might use in their day-to-day work, they’re leveraging the same guardrail-enabling features to achieve common goals in the blended workflows created by shift-left culture:
- Forms and templates simplify the way developers write their YAML configurations, skipping the frustration of hunting for simple syntax errors that stop deployments in their tracks.
- Real-time validation helps the most knowledgeable Kubernetes developers on the team to establish best practices and must-follow policies for YAML syntax, OPA rules and the Kubernetes schema itself. With custom rules, DevOps and platform engineers can prevent vulnerable or misconfigured code from even being committed to their git repository in the first place, the purest outcome of the shift-left paradigm.
- Resource comparisons between local and cluster resources, or the various git branches that define a cluster’s desired state, for anyone (not just DevOps engineers) who needs to quickly identify and understand the impact of proposed changes as it moves from a development and production cluster. With a line-by-line diff, anyone can catch errors like a mistakenly changed secret or resource limit change that would affect costs.
- A Git-based foundation, where all changes are written into commits to be pushed to the git provider of choice, which ensures all roles and departments can review and collaborate on what others are doing. There are no silos, hidden scripts or questions about who made what changes and when.
- A cluster mode dashboard with observability features, logs and terminal access, recent alerts and more. When many organizations restrict monitoring and troubleshooting work exclusively to DevOps engineers, Monokle makes this information available to anyone, another example of democratizing the educational value of having a common language.
The Path to Deploying Your First Guardrail with Monokle
If you’ve felt like the developers and engineers around you speak different languages, no matter which corner of the Kubernetes configuration life cycle you call home, guardrails might be the common language you’ve needed all along. Successfully deploying applications to Kubernetes is an all-hands-on-deck effort, so why shouldn’t your tools accommodate and encourage collaboration and quality control from the very first line of YAML?
Here are a few guardrails to get started with Monokle:
- If you want to validate your configurations and visualize state in just a few minutes, and entirely for free, get started with Monokle Cloud IDE for Policy Enforcement by signing in and connecting your GitHub account and repository.
- To establish best practices via validators and cluster management, download Monokle Desktop or the CLI tooling, both of which are free and open source.
With shift left blurring pre- versus post-deployment tasks, guardrails are the most transparent path toward creating collaborative workflows, folding education into every commit and deploying high-quality releases to ensure that everyone is speaking the same language.