Best of 2021 – Who Maintains Kubernetes When the World Moves On?

As we close out 2021, we at Container Journal wanted to highlight the most popular articles of the year. Following is the seventh in our series of the Best of 2021.

Scan the industry press and it’s difficult not to conclude that Kubernetes are definitely in a hype phase. Opinions abound on how to use Kubernetes and containers, how not to use them, their history, their future and maybe even how they can teach us the true meaning of life.

Step 1 of 7

14%

Which of the following best describes how you currently monitor and manage systems across your hybrid cloud environment?(Required)

Multiple separate tools for different environments

Multiple separate tools for different monitoring and management functions

Single consolidated dashboard

Custom built monitoring and management solution

No full monitoring and management solution

Don’t know

How valuable would it be for your monitoring and management solution to incorporate predictive analytics to help you identify and address system issues that are critical and not waste time or effort working through all the data and “noise” that is not critical?(Required)

Extremely valuable

Moderately valuable

Somewhat valuable

Slightly valuable

Not valuable

How do you most typically address potential system issues BEFORE they impact your operations?(Required)

Automated workflows and playbooks to remediate potential issues as soon as they are detected

An orchestrated response process that leverages automation, AI, and human expertise to rapidly respond to potential issues

Advanced monitoring tools such as predictive analytics and anomaly detection to proactively identify and address potential issues

Respond to issues as they arise, using manual processes and troubleshooting techniques

A combination of automated remediation, orchestrated response, and/or proactive monitoring to address potential system issues

Don’t know

Other

What methods does your organization use to control and monitor cloud/IT spending?(Required)

Centralized procurement processes

Pre-approved budget thresholds

Automated cost monitoring tools

Department-level spending controls

Regular cost audits and reviews

Cloud cost optimization platform

Approval workflows for resource provisioning

Native financial operations tools provided by the cloud provider

No formal controls in place

Don’t know

Other

Please specify:

Which methods do you rely on most to detect security vulnerabilities in your systems?(Required)

Automated scanning tools

Manual assessments

Vendor notifications

Threat modeling (for early detection)

None of these

Don’t know

Other

Please specify:

What are the TWO most common ways you prioritize vulnerabilities to address within your environment?(Required)

Based on potential impact

Based on exploitability

Regulatory compliance requirements

Based on CVSS scores

Risk-based analysis of multiple factors

First-in-first-out approach

No formal prioritization process

Don’t know

How do you typically handle system updates and security patches?(Required)

Automated updates and patches

Manually review and apply updates and patches on a regular schedule

A combination of automation and manual review

Apply updates and patches on an as-needed basis.

Outsourced update and patch management

No defined process

Don’t know

Other

Δ

Amid this clamor, let me insert a note of (perhaps necessary) warning. As a programmer of, let us say, a certain age, I’ve seen my fair share of development paradigms and languages come and go. Some, like HTML, continue to be relevant and useful for decades beyond their expected shelf life. Others, like COBOL, can end up acting as an albatross around the neck of future development.

Deciding which of these the current Kubernetes trend represents is not easy, but it’s worth an attempt.

COBOL: A Warning?

First, a dose of reality. I’ve already mentioned COBOL above, and that’s because COBOL is an excellent example of how a once-promising and once-useful language and approach can eventually hinder future development.

The reason why COBOL became such a problem is summed up in a recent article about how The New York Times moved away from their legacy COBOL system. The problem for the NYT wasn’t so much COBOL itself, it was that very few people now know how to work with that language, at least at the required level. This made hiring developers difficult, limited agility and, ultimately, stifled the organization’s ability to add new features to the system.

To the current generation of young developers, it might seem absurd to be talking about COBOL, a language that was developed almost 60 years ago. But here’s the thing–a lot of COBOL is still in use, despite the fact that no one knows how to work with it. And the reason for that, I would argue, is that COBOL is a Turing-complete programming language rather than a way of connecting disparate hardware and software components together.

You can see where I’m headed. Kubernetes is, despite the hype, a way of making underlying programming languages easier to work with and a way of making sure they play nicely together. These underlying systems are not going to change as a result of the “Kubernetes revolution,” but Kubernetes itself will eventually be replaced by a different system. At that point, it may be difficult to transition away from the paradigm.

This kind of process (progress?) happens all the time, of course, and, as a result, examples are everywhere. Cable TV faced the same problem back in the early 2000s, for instance, because the systems that underpin the network were built by a previous generation of programmers; the lack of expertise on how to use them at a high level meant that they couldn’t easily be integrated with then-new online streaming services. Does anyone want to place a bet on cable taking market share back from streamers in the next decade? Me either.

The Kubernetes Talent Gap

For those working with Kubernetes now, worrying about a future talent gap might also seem beside the point. That’s because there is a talent gap right now when it comes to Kubernetes, and so the relative lack of expertise is already holding back development. However, this is merely another aspect of the same problem.

Let me explain what I mean. There is no lack of demand for Kubernetes expertise: Tech Republic reported last year that between October 2015 and October 2019—a mere four-year timespan—the share of Kubernetes job searches increased by 2,125%. Kubernetes-related jobs per million also grew by 2,141% in that same time period, according to a blog post.

There is a caveat to be mentioned here, though. This is that many of the jobs for which Kubernetes programmers are in demand are those that involve using Kubernetes to integrate otherwise disparate legacy systems into supposedly more “agile” systems. This is seen most clearly in the fact that so many job ads for Kubernetes developers mention DevOps–where Kubernetes is certainly useful, but by no means essential.

In other words, while it might be that young programmers have plenty of opportunities to learn Kubernetes and to deploy them in their everyday tasks, few are aware of the best practices for using containers in production. And this might mean that we are storing up problems for ourselves further down the line.

Kubernet-ic Agility

The solution to this problem is easier said than done. We need to deploy Kubernetes in a way that is truly agile so that it is not left in place as the rest of our IT infrastructure moves on.

This is not a new idea, of course, and we’ve previously seen many analysts worry about the double-edged sword of Kubernetes. COBOL provides, though, a great example of how not to deploy Kubernetes. If we use containers to merely wrap obsolete systems in new code, there will come a time when no one knows how to work with Kubernetes, and no one knows how to work with the underlying systems, either. And then we will really have a problem.

Building truly adaptable, agile Kubernetes systems means looking at the underlying systems that your containers are working with and making sure that they are fit-for-purpose in and of themselves. Otherwise, we are merely replacing one set of obsolete programs with another set that will one day become obsolete, too.

No matter how it may seem, this is not a complaint about Kubernetes. Instead, it’s a plea to recognize what we’ve all secretly known about for the past five years: The double-edged sword of containerization. While Kubernetes makes our lives as programmers much easier, it also comes with real risks–that we are building systems that will eventually become impossible to maintain.

So take a tip from a developer from the previous generation: Make sure you are building with an eye to the future.