Commentary: Today’s infrastructure turns into tomorrow’s legacy, however there are methods to construct that keep away from pitfalls.
Today we have now a COBOL downside, with tons (and much) of outdated code hanging round with fewer (and fewer) individuals who know the best way to deal with it. COBOL was as soon as the “in” infrastructure, working the backend techniques of scads of monetary 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 business’s subsequent “COBOL moment” will probably contain Kubernetes. Over time, he famous, Kubernetes will inevitably get replaced by one thing easier, leaving us to reply the query: “Who will maintain the infrastructure that already relies on it?”
SEE: From begin to end: How to deploy an software with Kubernetes (TechRepublic 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 essentially other ways. While Fortran was used to create infrastructure, software program written in Fortran is not itself infrastructure….Nobody cares anymore concerning the Fortran code written within the 60s, 70s, and 80s to design new bridges and automobiles. Fortran is nonetheless closely utilized in engineering—however that outdated code has retired. Those 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 could possibly be rebuilt pretty rapidly 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 Nineteen Sixties may nonetheless be in use–it’s infrastructure we construct upon. Fortran code, as indicated by Loukides, is not handled the identical approach.
So what’s our modern-day COBOL? For Loukides, the reply is clear. It’s Kubernetes:
[C]ompanies are transferring purposes to the cloud en masse. In addition to easy raise and shift, they’re refactoring monolithic purposes into techniques of microservices, ceaselessly orchestrated by Kubernetes….
[I]t’s a secure wager that many of those techniques will nonetheless be working 20 or 30 years from now; they’re the subsequent technology’s “legacy apps.” …Kubernetes configuration is complicated, a distinct specialty in its personal proper. If Kubernetes is changed by one thing easier (which I believe is inevitable), who will keep the infrastructure that already depends on it? What occurs when studying Kubernetes is not the ticket to the subsequent 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 the best way to work with that code will inevitably dwindle, and will finally grow to be a “dying breed.” When that occurs, who will keep the infrastructure?
This is not trigger for alarm. Most organizations are targeted on modernizing their current techniques, somewhat than peering 10 to twenty years into the long run, worrying about expertise shortages that may finally meet up with their choices. And, arguably, corporations are making a smart move after they construct with an business commonplace like Kubernetes. Yes, Kubernetes wil at some point be legacy, with all of the expertise shortages that include it. But immediately, organizations are extra involved by current 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 doable, and let the long run handle itself. Expedia expertise VP Subbu Allamaraju put it this fashion, talking of a related mentality that infects those that need to protect most infrastructure freedom by hedging cloud with knowledge middle 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 identical matter: “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, sure, immediately’s sizzling Kubernetes cluster is probably 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, however the views expressed herein are mine.