Premise
Recently an increasing number of new variants are emerging around DevOps. This is of course a testament to the gravity of DevOps as movement. Each variant claims to be something new and shiny. DevQaOps, DevBizOps, DevApiOps and DevSecOps, to mention a few. It almost seems like there is a new variant coming each week which claims to solve all of your problems. Have you ever wondered why that is or what is all of this fuzz about?
Chronology
When DevOps was first coined, the Tech world was not the same as it is now. The Tech domain is a rapidly evolving landscape filled with disruption and fads. The required skills & competences of ten years ago often no longer apply today. The advancements in e.g., cloud computing and microservices have created a demand for new skills and expertise. The team that applied DevOps ten years ago, shouldn’t look the same today from the capabilities standpoint. That is why one of the core pillars of DevOps is continuous learning, you’re never finished learning. As DevOps gained popularity, more and more organizations tried to jump on board the hype train. This meant that organizations with different levels of maturity started applying DevOps and make it fit to their reality. Like many other paradigm shifts before, applying a tried and tested framework and making it “fit-for-purpose” can lead to all sorts of conundrums.
Key issues
Applying a best practice and making it “fit-for-purpose” without a deep understanding of it, is a recipe for disaster. Especially if your take of “fit-for-purpose” is to twist and turn tried and tested practices to fit your paradigm. An excellent satire piece was written about this by Ron Jeffries – We tried baseball and it didn’t work. It is often referenced in books and pieces of Agile and DevOps. DevOps includes all the required capabilities for software production. The DevOps cycle is simplified visual illustration for introductory purposes. It does not contain all the necessary information for adopting DevOps. Just because the cycle traditionally does not display aspects such as UX Design, InfoSec or Quality Assurance, it doesn’t mean that they are excluded from it.
One major factor leading up to the DevOps variants can be attributed to the ever-increasing shortage of tech experts. The digital disruption has created a reinforcing loop of higher demand than the supply. More and more often DevOps teams consist of junior level programmers and/or system admins. They have not had the opportunity to perfect their craft and are oblivious to the holism that is software production. One cannot address things they are not aware of. Unintentionally excluding critical practices from software production has led to the need to retroactively address them. There are no shortcuts to mastery.
Conclusion
The emerging variants are partly due to ‘Fear of Missing Out’ aka FOMO, and partly due to a real need to address arisen issues with incomplete or unbalanced adoptions of DevOps. The most recent variants of <X>Ops are a whole another story, but the Dev<X>Ops variants address specific needs in a given environment. Basically, the question is – which X is suboptimal in your team or organization and needs reinforcements? Dev<X>Ops isn’t the new DevOps, it’s DevOps with a single emphasis based on a dire need. If you are now considering starting DevOps, don’t start with Dev<X>Ops – the original is still the key.
Key takeaways
- The X in Dev<X>Ops is okay, but do not try to come up with a new DevOps – the original one still applies.
- DevOps requires highly skilled experts, so be prepared to have both Seniors and Juniors in the team.
- DevOps is a highly capable and refined tool, but you need to know your way around it.
