Automate the Boring Stuff with Kubernetes

In the tech industry, I have found that when people say something is impossible with software, what they often mean is that it is tedious. Certainly there are fundamental and complex computer science problems that you may encounter in your work. But generally speaking, it is the tedious work that we often avoid.

The thing is, there is plenty of tedious work out there in enterprise software. From wiring up APIs, to refactoring old applications, to the daily administrative tasks required to keep things working. It’s a lot less fun to run something old than to build something new.

For some time now, Kubernetes has been an exciting open source ecosystem where innovation has exploded. Yet even with all of this excitement and experimentation, no business is out there running Kubernetes just to run Kubernetes. They are using it because it helps them automate the tedious tasks.

The reason we’re all here participating in this community is because of the common goal of optimizing, expanding and sharing an application platform. Kubernetes excels at this, helping end users support and automate the operation of applications at scale.

It’s the applications that matter. Everything underneath them is, for lack of a better term, tedious. While implementation, location and support all matter a great deal, they shouldn’t be the greatest concern to your application developers. Their time is your most precious resource, and the last thing you want them to have to worry about is tedium.

Your developers should be focusing on innovation. But they can’t do that when the build won’t complete, the test environment is different from the production environment or they can’t get access to a fresh install of PostgreSQL in their region for three weeks.

It Must Be Automated

Everything beneath the developers must be automated. Your developers are building with the very service-oriented building blocks your architects envisioned a decade ago. But they can’t build new applications with them if they can’t access them in a test environment. And they especially can’t spin up new database instances if that process isn’t automated in a more secure fashion with your platform team using Kubernetes Operators there to provide guardrails.

Now that the underlying piping is sturdy and reliable, thanks to over a decade of Kubernetes community growth and development, it’s long past time to focus on the applications. Kubernetes is no longer just a container platform; it is the foundation for an application platform. And with the right subset of accouterments, it can be a powerful automation platform to enable faster development and more secure software supply chains.

Coupled with things like Ansible for IT automation, Quarkus for cloud native Java and even the built-in Kubernetes virtual machine support, there’s no reason to let legacy applications remain hand-driven or, worse yet, untouched. Even better, migrating older Java workloads to your new application platform enables innovative, new green shoots to sprout on those old projects.

Automation at scale enables developers to focus on code development at speed versus everything else that gets in the way. But that implies proper guardrails to keep them from doing things that could be damaging if used incorrectly. Argo CD essentially enforces a git repo upon a cluster, which means there is a single source of truth for your production environments. And it can be changed only through proper processes. All of this is designed to be automated.

Those ensuing artifacts can be stored and secured by Quay and Red Hat Advanced Cluster Security for Kubernetes, again, in an automated fashion. All of these automated systems have the added bonus of providing that essential element in any software system: consistent repeatability.

Consistency

Because we’ve all worked together to expand Kubernetes’ capabilities, all these pieces of the application platform puzzle can combine to give your administrators and developers one path to deploying anything they need. The destination of that deployment should be basically irrelevant. Test environment and production environment can be identical in deployment artifacts, removing the painful drift that can occur when codebases diverge.

All this automation and deliberate architecting of an open source application platform wasn’t done just because people around the world decided it would be fun to dedicate years of their lives to infrastructure code. It was built because we all share the same problems. No business on earth is going to beat the competition based on how well they know Kubernetes alone.

The winners will be those who are able to innovate faster and to get to market faster with new products, driven by software developers who are exclusively focused on business problems, instead of developer problems.

Just like a fleet of trucks, or a manufacturing plant, the end goal is not the trucks nor the conveyor belts. The end goal is what goes into the trucks or comes out of the manufacturing plant. You can twiddle the knobs on the factory machinery or tinker with the engines on the trucks, but at the end of the day, if you can run those things 24/7, you can generate value 24/7 as well.

Today, you can automate a factory with Kubernetes. You can run civic watering systems with it. You can bank on it. And while we’re not yet at the point where you can drive a real truck with it, millions of virtual drivers have been simulated inside Kubernetes already. Did you know you can run a cruise ship with it?

Here’s to cruising into the future with the open source community that built the foundation for the best application platform for enterprise business. It’s anything but tedious.