Today we have a COBOL problem, with lots (and lots) of old code hanging around with fewer (and fewer) people who know how to handle it. COBOL was once the “in” infrastructure, running the backend systems of scads of financial institutions and governments. Now we’ve moved on.

In like manner, Mike Louikides, vice president of content strategy at O’Reilly Media, has suggested that our industry’s next “COBOL moment” will likely involve Kubernetes. Over time, he noted, Kubernetes will inevitably be replaced by something simpler, leaving us to answer the question: “Who will maintain the infrastructure that already relies on it?” 

SEE: From start to finish: How to deploy an application with Kubernetes (TechRepublic Premium)

Infrastructure as code

This “COBOLization” of code isn’t endemic to all software. For example, Loukides uses Fortran to draw a distinction between code that creates long-term maintenance issues, and code that does not:

Fortran and COBOL are used in fundamentally different ways. While Fortran was used to create infrastructure, software written in Fortran isn’t itself infrastructure….Nobody cares anymore about the Fortran code written in the 60s, 70s, and 80s to design new bridges and cars. Fortran is still heavily used in engineering—but that old code has retired. Those older tools have been reworked and replaced….[I]f all the world’s Fortran programmers were to magically disappear, these libraries and applications could be rebuilt fairly quickly in modern languages—many of which already have excellent libraries for linear algebra and machine learning.

Infrastructure code is different. COBOL code written in the 1960s might still be in use–it’s infrastructure we build upon. Fortran code, as indicated by Loukides, isn’t treated the same way. 

So what’s our modern-day COBOL? For Loukides, the answer is clear. It’s Kubernetes:

[C]ompanies are moving applications to the cloud en masse. In addition to simple lift and shift, they’re refactoring monolithic applications into systems of microservices, frequently orchestrated by Kubernetes….

[I]t’s a safe bet that many of these systems will still be running 20 or 30 years from now; they’re the next generation’s “legacy apps.” …Kubernetes configuration is complex, a distinct specialty in its own right. If Kubernetes is replaced by something simpler (which I think is inevitable), who will maintain the infrastructure that already relies on it? What happens when learning Kubernetes isn’t the ticket to the next job or promotion? The YAML files that configure Kubernetes aren’t a Turing-complete programming language like Python; but they are code. The number of people who understand how to work with that code will inevitably dwindle, and may eventually become a “dying breed.” When that happens, who will maintain the infrastructure? 

This isn’t cause for alarm. Most organizations are focused on modernizing their existing systems, rather than peering 10 to 20 years into the future, worrying about talent shortages that might eventually catch up with their decisions. And, arguably, companies are making a smart decision when they build with an industry standard like Kubernetes. Yes, Kubernetes wil one day be legacy, with all the talent shortages that come with it. But today, organizations are more concerned by existing shortages in Kubernetes talent as they seek to embrace containers-enabled, microservices-driven architectures. 

Which perhaps is the lesson to take from this: build as much agility into your current infrastructure as possible, and let the future take care of itself. Expedia technology VP Subbu Allamaraju put it this way, speaking of a similar mentality that infects those who want to preserve maximum infrastructure freedom by hedging cloud with data center investments: “To be successful at scale in a hybrid architecture and maximize customer value, cost efficiency and agility requires you to make a large number of technical, people and process decisions upfront years before needed. Even if you can afford this, you’re [un]likely [to] get these right.”

SEE: Kubernetes: A cheat sheet (free PDF) (TechRepublic)

Or heed Duckbill analyst Corey Quinn’s counsel on this same topic: “By building for a theoretical exodus, you pay for optionality with feature velocity, and reduce your chances of getting to a position where the cloud costs even matter to your business’s overall success.”

In sum, yes, today’s hot Kubernetes cluster is likely tomorrow’s COBOL-esque legacy infrastructure. But, to misquote the Bible, “Take therefore no thought for the morrow: for the morrow shall take thought for the things of itself. Sufficient unto the day is the legacy infrastructure thereof.”

Disclosure: I work for AWS, but the views expressed herein are mine.

Developer Essentials Newsletter

From the hottest programming languages to the jobs with the highest salaries, get the developer news and tips you need to know.
Weekly

Sign up today

Also see