I have observed that almost any successful project, or even any endeavour, usually goes through these general steps:
- Define the goal.
- Determine the specific tasks to achieve the goal.
- Execute the tasks.
- Review progress and update[0] tasks.
- Repeat 3-5 until goal achieved.
That first step is the most crucial. The goal, or specifically the goal’s definition, sets the direction of the project and anyone involved should always refer to it along the way. Is a specific task relevant? Look at the goal. Are we making any progress? Look at the goal. Are we lost? Again, look at the goal. The goal should always bring clarity to any confusion.
An effective goal, therefore, should be clear and concise. Its definition should be so obvious, it doesn’t need more than two readings to understand it. A confusing goal is not only ineffective but may also harm progress in the long run. DevOps, or “implementing/adopting DevOps”, is a popular example of a confusing goal.
DevOps is a decade-old “buzzword” which, in the tech industry, makes it “not new” but at the same time not yet that mature. Adopting it can bring significant benefits to any organisation, especially in terms of software stability and release velocity. But let’s be honest, DevOps is quite difficult to understand and defining it can prove to be futile. I wrote “DevOps is a buzzword” instead of “DevOps is a practice” or movement or culture or whatever, because it can be one or all of those, depending on who you ask. Trying to find the definition of DevOps is like asking, “What is love?” or “What is the purpose of life?” Everyone has their own definition.
Implementing DevOps is a major organisational change and a confusing definition is the last thing we need. Restructuring teams, changing workflows, and adopting new technology can waste a substantial amount of money and effort if not done correctly.
OK, so what is the alternative?
I have noticed that organisations interested in DevOps actually have two objectives: faster code deployment and better application reliability. [1] My suggestion to directly set our course to these two instead of obfuscating them with “DevOps”.
Let’s have a quick thought experiment by going through step no. 2 as written above. Here are the common suggestions in our case:
- Restructure the development and operations teams.
- Automate 100% or near 100% of processes.
- Adopt X and Y tools.
- Move or use applications to the cloud.
- Break down our monolith software to microservices.
Filtering out these suggestions becomes more straightforward if the goal is either faster deployment or better reliability. For example, the first point above can have multiple variations:
- Merge dev and ops into one team and give them complete ownership of both development and operations.
- Keep them separate but remove their barriers so that they can closely collaborate.
- Simply add programmers to the existing ops team so that they can write the infrastructure as code.
“Which will deploy code changes faster?” is a better question than “Which is the DevOps best practice that everybody else is doing?”. The focus is on solving specific problems. Selecting the right solution will also feel less dogmatic because the choice will be based on the individual context and not on “what everybody else is doing”.
Of course, I am not saying to not pay attention to how other practitioners do their thing. I’m just saying that completely mimicking them is not a good idea. What works in their context might not work for others, and vice versa. And I believe this mindset is applicable to most things, including this article. 🙂
[0]: “Updating” can also mean adding new tasks or discarding those that become irrelevant.
[1]: When I say “faster code deployment” and “better application reliability”, I’m thinking of CI/CD (continuous integration, continuous delivery/deployment) and Site Reliability Engineering, respectively. You can use these terms to look up how other organisations increase deployment velocity and improve reliability.