April 10, 2024
DevOps has become an industry standard term, and many organizations strive to become more "DevOps" oriented. This can have some wonderful effects: reduced time to market, better time to recover, better customer satisfaction, and increased developer morale. It's hard to deny its usefulness but there is an often-unsaid part of the DevOps story that can have the exact opposite effect. Below are some common pitfalls and some strategies to combat them.
It's hard to google DevOps and not see 20+ advertisements for tools that can make "make your organization DevOps" or "become DevOps quick with our platform." The reality of the situation is that there is no product, no silver bullet, to becoming a DevOps practitioner. Like any other tool that you can buy, it does not make you an expert. You can buy a chainsaw, axe, and flannel but can you call yourself a lumberjack?
Let's take an example of a tool, like a pipeline runner; there are plenty of examples of different products that offer this service. The reason we need the tool is to run automated tasks to speed up different processes. These can be as simple as cron jobs that trigger bash scripts that build and deploy your application, to be as complex as you need them to be. The goal is to provide some sort of automation and if that can be done easily and with a little lift, go for it.
Tools can become a crutch that make your journey longer and more laborious than understanding the process first and adding tools later to improve the process. It's now a question of when the teams will finish installing the tools vs when they can start improving their process. Understand the process first and its shortcomings before immediately buying the new shiny thing that ultimately is some cron jobs and bash scripts under the hood.
And so, there was DevOps, the only operational model from this point forward. This strategy starts with the idea that there is some date in the future that will mark a new process, a new DevOps day and all will rejoice. It's a tempting proposition, throw out the old process that has been a pain and offers nothing good but red tape and delays for a new shiny process.
This often develops as a team that will create a new process, a new way of working for the whole organization or product line. It's a large investment but can be offset by how much efficiency we will gain once this new process is perfected. Spend a year building this new way of working, perfecting the ideas, the feedback loop, the automation, a paved road per say.
We just waterfalled our way into becoming more DevOps, developing a new process away from our product developers and then deployed to them. We are breaking the entire idea of DevOps using this approach, at minimum we need to be deploying our DevOps process in tandem to get quick feedback from our developers. The best way of avoiding this is to pull in your developers and empower them to better their process and not waiting for it to be handed to them.
A bit like the above big bang strategy, golden pipelines can become more restricting than freeing to development teams. The concept of a golden pipeline stems from a want for all development to follow a standard process. It is enticing, each product is developed in the same way and developers could be interchanged easily, one improvement can lead to improvements everywhere.
Just like tools, paved roads, golden pipelines, blazed paths, can be helpful if you understand their purpose in your process. It can be nice to have an established process, but can put the same thorns into developers that the old processes had for them to begin with. Things can become prescribed to a level that doesn't make any sense, like what build tool are you using? If all your products are using the same frameworks this works out well, but if e.g. one is making hardware device firmware and microservices, it may not work well for them.
Standards are good to have, we do not want a wild west of different procedures and processes across our entire ecosystem, it's a warning of moderation. If you want your teams to be empowered you need to bake in some wiggle room, allowing them to find their own best way of working within some guidelines. Allow all of your people to contribute to the process and don't settle for good enough.
"A battle plan never survives contact with the enemy" - Helmuth von Moltke the Elder, 1871
This quote really dives into the heart of DevOps and its feedback loop. In our context it could be reworded, "A software design plan, never survives contact with the customer." Our goal with DevOps is to create a tight feedback loop because no plans survive without adapting to changing conditions.
Avoid trying to install tools; install processes that use tools to increase flow, communications or decrease defects. Slow and steady progress beats big bang. Apply standards sparingly and allow your people room to do what is best for them. They are the people making value for your customers, empower them to improve.