Commentary: At present’s infrastructure turns into tomorrow’s legacy, however there are methods to construct that keep away from pitfalls.

Kubernetes logo concept

Picture: Lisa Hornung, iStock

At present we have now a COBOL drawback, with tons (and plenty) of outdated code hanging round with fewer (and fewer) individuals who know deal with it. COBOL was as soon as the “in” infrastructure, working the backend methods of scads of economic establishments and governments. Now we have moved on.

In like method, Mike Louikides, vp of content material technique at O’Reilly Media, has prompt that our industry’s next “COBOL moment” will likely involve Kubernetes. Over time, he famous, Kubernetes will inevitably get replaced by one thing easier, leaving us to reply the query: “Who will preserve the infrastructure that already depends on it?” 

SEE: From begin to end: The way to deploy an software with Kubernetes (eBioPic Premium)

Infrastructure as code

This “COBOLization” of code is not endemic to all software program. For instance, Loukides makes use of Fortran to attract a distinction between code that creates long-term upkeep points, and code that doesn’t:

Fortran and COBOL are utilized in basically alternative ways. Whereas Fortran was used to create infrastructure, software program written in Fortran is not itself infrastructure….No one cares anymore concerning the Fortran code written within the 60s, 70s, and 80s to design new bridges and automobiles. Fortran remains to be closely utilized in engineering—however that outdated code has retired. These older instruments have been reworked and changed….[I]f all of the world’s Fortran programmers have been to magically disappear, these libraries and purposes may very well be rebuilt pretty shortly in trendy languages—a lot of which have already got glorious libraries for linear algebra and machine studying.

Infrastructure code is totally different. COBOL code written within the 1960s would possibly nonetheless be in use–it’s infrastructure we construct upon. Fortran code, as indicated by Loukides, is not handled the identical manner. 

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

[C]ompanies are shifting purposes to the cloud en masse. Along with easy carry and shift, they’re refactoring monolithic purposes into methods of microservices, steadily orchestrated by Kubernetes….

[I]t’s a protected guess that many of those methods will nonetheless be working 20 or 30 years from now; they’re the following technology’s “legacy apps.” …Kubernetes configuration is complicated, a definite specialty in its personal proper. If Kubernetes is changed by one thing easier (which I believe is inevitable), who will preserve the infrastructure that already depends on it? What occurs when studying Kubernetes is not the ticket to the following job or promotion? The YAML recordsdata that configure Kubernetes aren’t a Turing-complete programming language like Python; however they’re code. The quantity of people that perceive work with that code will inevitably dwindle, and should finally change into a “dying breed.” When that occurs, who will preserve the infrastructure? 

This is not trigger for alarm. Most organizations are centered on modernizing their present methods, quite than peering 10 to 20 years into the longer term, worrying about expertise shortages which may finally meet up with their selections. And, arguably, corporations are making a good move once they construct with an trade normal like Kubernetes. Sure, Kubernetes wil someday be legacy, with all of the expertise shortages that include it. However as we speak, organizations are extra involved by present shortages in Kubernetes expertise as they search to embrace containers-enabled, microservices-driven architectures. 

Which maybe is the lesson to take from this: construct as a lot agility into your present infrastructure as attainable, and let the longer term handle itself. Expedia technology VP Subbu Allamaraju put it this way, talking of an analogous mentality that infects those that wish to protect most infrastructure freedom by hedging cloud with knowledge middle investments: “To achieve success at scale in a hybrid structure and maximize buyer worth, price effectivity and agility requires you to make numerous technical, folks and course of selections upfront years earlier than wanted. Even if you happen to can afford this, you are [un]probably [to] get these proper.”

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

Or heed Duckbill analyst Corey Quinn’s counsel on this same topic: “By constructing for a theoretical exodus, you pay for optionality with characteristic velocity, and cut back your probabilities of attending to a place the place the cloud prices even matter to your corporation’s general success.”

In sum, sure, as we speak’s sizzling Kubernetes cluster is probably going tomorrow’s COBOL-esque legacy infrastructure. However, to misquote the Bible, “Take due to this fact no thought for the morrow: for the morrow shall take thought for the issues of itself. Adequate unto the day is the legacy infrastructure thereof.”

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

Additionally see

Leave a Reply