SaltyVagrantForget DevOps
This article as PDF
Do not implement ‘DevOps’! In fact forget DevOps entirely.
Let me illustrate the problem as I see it. What is DevOps? You might answer, “it is a manifesto for organisational structure that breaks down barriers between development is operations”, or perhaps “it is tools and techniques to automate the process such that the distinction between development and operations is eliminated”, or “it is a new role with IT”, or “that infinity diagram thingy”.
Which did you respond with, or perhaps you have some other definition in mind? You are of course right. You are of course wrong. And therein lies the problem. DevOps has been corrupted (largely by HR and marketing departments) to a meaningless symbol for some nebulous silver bullet that will save your organisation in the 21st century.
There is no generally agreed definition of DevOps. It is a term sure to ignite passionate flame wars online (a sure sign that a term is next to useless). DevOps can mean pretty much whatever you need it to mean.
Okay, so I’ve pissed all over DevOps as a term, do I think the myriad things DevOps seems to encompass are also crap? No, but I do think people become so fixated on “DevOps” that they forget the problems it tries to solve.
There is an old humorous aphorism, generally a variation on, “When you’re up to your ass in crocodiles it can be difficult to remember that your job is to drain the swamp.” This sums up perfectly the problem I see most people having with DevOps. We went through the same process over and over and over in IT. Each new methodology is heralded, corrupted, and rendered useless (at least in-so-far as being a meaningful term).
I encourage you to step back, take a deep breath and forget the term “DevOps”. Instead look at your organisation and think “what is the problem here?” and proceed from there. No! Don’t think, “well, the problem is the silo between development and operations, therefore DevOps!” That’s the wrong approach. In fact it’s likely to be harmful rather than helpful. Think for yourself.
Let’s assume the problem you see is the silo between development and operations. Fine. Let’s address that from your organisations perspective.
Many organisations see this problem because they run projects as isolated efforts. A project team is assembled, the project’s goal is to produced application X but date Y (these are in themselves problematic ways of thinking, but common enough none-the-less). Once application X is ready (whatever that means to your project) it is delivered to operations who deploy it and are thereafter responsible for its care and feeding. The project team is disbanded and its members reassigned. In many organisations the project team consisted of many contractors who may leave the organisation once the project is complete. Some project members may hang around for a ‘warranty’ period but once that ends the operations team is largely on their own.
This approach often ends up with operations having a hell of a time getting problems resolved. Just tracking down the appropriate project team member to diagnose a problem can be an issue.
Okay, how to fix this.
There are many ways but the DevOps received wisdom says something along the lines, “the project does not end, the team persists and become the applications caretakers in production.”
Yeah. That might work for your organisation but realistically you have to work within your organisations limitations. Unlike The phoenix project: a novel about IT, DevOps, and helping your business win[KBS18] where we are presented with a idealised situation (management are agreeably amenable to wholesale change in culture) we mere mortals must deal with situations in which we have less control and less compliant management. Devops from Scratch is an attempt to be realistic about what we can achieve, providing useful strategies rather than idealised outcomes.