Overview
This article, written with a lot of humor (and perhaps sarcasm?), triggers a lot of (recent) memories and struggles, and speaks mainly about how "you can't buy DevOps", and how "tools are necessary but not sufficient".
As a sidenote, I think this is the second or third article I've read recently that states that one can't just "buy DevOps"; does anyone actually think that DevOps is a product (or tool)? I would assume that "yes, you can buy DevOps" given how many "tools", "manifestos", and "evangelists" are out there... (And the irony is that the authors of both these articles are "DevOps advocates"...)
Anyway, although the article doesn't cover anything new (or for that matter practical and useful), neither does it point to (too many) other relevant works, it does provide an opportunity to think critically about one's investment in "DevOps"...
The bottom line is that I found it a worthwhile read, although granted, that might be due to confirmation bias. :)
Highlights
Tech is Not a Panacea
According to noted thought leader Jane Austen, it is a truth universally acknowledged that a techie in possession of any production code whatsoever must be in want of a container platform.
Yup... I've been to a few meetups in my area and everyone was on the container band-wagon...
[...] Proposal: rename 'staging' to 'theory'. "It works in theory, not on production." -- Najaf Ali [...]
Yup... Just the other day we deployed something in production, which when it hit the actual "production data" it blew in our faces...
Perhaps we need something like "preproduction"? I know the big firms are using it, but perhaps it should be extended to smaller shops...
Good Team Interactions: Build, Because You Can't Buy
[...] We've all heard "we only communicate through APIs," but technology alone does not solve all communication problems. If you launch a new version of the API, does that mean you'll ever be able to deprecate the old one? Is well-labeled versioning sufficient for current needs of all your API's consumers? How about future, conflicting, overlapping needs? At some point, you'll have to talk to each other. [...]
Interesting question; it made me pause and think for a moment, as I always thought that having a well-defined (and well-designed) API (plus a few integration tests) would prove sufficient to integrate two products together.
Tech, Like Soylent Green, is Made of People
Andrew Clay Shafer likes to opine that 90 percent of tech is tribalism and fashion.
Web 4.0 anyone? (Or is it Web 3.0? I'm not sure... Let me check my browser version... OK, I've figured it out... For those reading this in 2019 it's "Web 80.9 anyone?"; for those reading this in 2021 it's "Web 192.7 anyone?")
Ten years ago it was JSF and Wicket. Five years ago it was GWT. Now it's Angular, React, and Vue.
What does the crystal ball say about tomorrow?
[...] Nobody is doing resume-driven development with shell scripts; I'm willing to bet that all the janky bash ever written was meant to solve a real problem.
Yup again... If I'm honest, in the last 5 years I think I've written more Bash than any other programming language (perhaps even put together)... I've written scripts that orchestrate deployments, scripts that parse and aggregate logs, scripts that wrap other scripts, and even scripts that generate scripts... (You could say "it's scripts all the way down"...)
Moreover I've tried to "learn" (if not "resume-develop") some of these Bash scripts into Ansible, but (although there are "ups") there are a lot of "downs"...
[...] Software is "done" when it's decommissioned; until that point, day one is short, while day two lasts until the heat death of the universe.
[...] While a proof of concept can be "done" enough to ship it, operationalizing it takes longer, and keeping it running in production is an ongoing project.
Yup, yup and yup...
Avoiding Sadness as a Service
[...] If legacy weren't important, you could just turn it off. But this is where your customers and money live. [...]
And finally, yup! If I think back in my "professional" career (the other half being "research"), I would say that most of my time was spent on maintaining "legacy" systems that were paying the bills and the development of the "new-and-improved" system...