I’ve written previously about various aspects of DevOps. I’ve also been interviewed on my perspective of the field. This section (currently a work-in-progress) is aimed at putting together all these little references and insights to form a holistic view that might best describe what I personally think of the DevOps field or “movement” in general. Hopefully this finds you well and you are able to gain something from it.
An article I published some time ago on LinkedIn titled “Why the DevOps Movement Resonates so Readily With the Idea of Empathy” does well to describe why I believe DevOps is so much more of a people-focused field than it is a technical one. The following is a key excerpt from that article, which I believe is worth repeating here.
DevOps is not simply about automation, build-pipelines, or CI/CD. It is not only about processes and documentation, or release cycles and the cadence of deployments to production environments. It is however, about improving productivity and harmony within a team or organization. It’s about attention to detail. It’s about culture. It’s about removing obstacles so that Development and Operations, among other teams, can work together more reliably and more enjoyably. It’s about removing barriers to innovation, promoting experimentation and encouraging curiosity. Most importantly, DevOps is about bridging gaps – and bringing people and technology together.
The core of why DevOps exists is not because it is intended just to address problems between technologies – that is a relatively trivial task. The core of why DevOps exists is that it aims to address problems between people. These are much more difficult problems to solve; and is the reason why (often in less mature organizations that grow in size quickly), a DevOps transformation can be a very painful process. Most new (or uninitiated) DevOps engineers often expect that DevOps should be easy or all about automation, and are often surprised when they can’t “do DevOps” when they join an organization that isn’t yet ready to dive into that phase of the DevOps transformation process.
When I talk about DevOps, I don’t often discuss tooling or technologies unless I’m speaking with other seasoned DevOps engineers or practitioners. There are endless blogs that discuss everything from the latest shiny continuous integration software to enterprise-scale virtualization and orchestration platforms like OpenStack and Kubernetes. There are many many tools out there to satisfy endless technical problems at varying scales. Often however, these tools (the more complex and cutting-edge of them) are geared towards two distinct markets – organizations that already have mature development and operations departments, and small start-ups with little to no management overhead (seasoned developers and operations engineers that make the decisions and do the work themselves).
If your organization however has grown to include, for example over fifty technical resources; has multiple development teams, several layers of management, does not have clear processes and responsibilities defined, then your organization needs to focus less on tools, and more on culture and technical debt. If your organization is continuously struggling with broken or delayed releases, infrastructure issues and never-ending communication problems between cross-functional teams or between engineers and management, then you are wasting your time looking at the latest shiny technology thinking that it will solve your organizations problems. Your problem is culture and process. You need to fix that first.
The New Shiny is… Boring
Whenever I hear developers, operations engineers, or upper management talk about new shiny technologies and orchestration platforms like Kubernetes, OpenStack or AWS, I get sleepy. The conversations bore me to death because often times the discussions are very high-level and superficial. There is often a significant lack of understanding around how these technologies work which makes them seem like magical solutions that will solve all problems and immediately make the organization run “like Amazon”, “like Netflix” or “like Spotify”.
The understanding (and realization) around how these technologies work under-the-hood; the foundational technologies they are built-upon, and the real problems they are actually intended to solve never come to light against the fantastical mental imagery and wonder that some folks have at the thought of everything being fully automated and production incidents magically going away for good. This is the hardest part of DevOps, making people see the reality of a situation – managing expectations.
The problem is not that these tools aren’t great and wonderful, they absolutely are! Automation tooling has come a long way over the last fifteen years, and so much more can be done by smaller teams (or individuals) than ever before. The problem is that growing companies are always putting the cart before the horse.
If you attempt to do the right things, in the right order, then you are less likely to repeat your mistakes.
The DevOps Joint 
Leave a Reply