I’ve written previously about various aspects of DevOps, and have been interviewed on my perspective of the field. This section of my personal blog 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 often avoid discussing tools or technologies unless I’m speaking with other seasoned DevOps 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… Continually struggling with infrastructure issues and never-ending communication problems between cross-functional teams.. If there isn’t enough transparency between engineers and middle or upper-management, then paying attention to the latest tools and technologies is a waste of time. Tools and technologies will not solve your organization’s problems. Your problem is culture and process. You need to fix that first.
The New Shiny is… Boring
Whenever I hear developers, operations engineers, middle or upper-management talk about shiny new technologies and orchestration platforms, i.e. Kubernetes, OpenStack or even AWS, I get restless. Those conversations put me off. These discussions are often too high-level, superficial, and cyclical (often the same topics are discussed over and over again). 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”. These of course are not just my experiences, but are the experiences shared by of many of my software developer colleagues and systems administration friends in the industry. Many great books have been written on these topics, where these experiences have been collected and analyzed in great detail. Some book suggestions can be found further below in this article.
The understanding of 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 15-20 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 really want to understand DevOps..
The first book, The Phoenix Project, is essentially a fictitious story about a company going through though times, with the protagonist (Bill) learning about the Three Ways as described in The DevOps Handbook. The story reflects the real-world experiences captured from many individuals and organizations about the challenges and solutions to developing and releasing software, and making the work environment a better place.
The DevOps Handbook is essentially a step-by-step guide on how to tackle the many challenges you are likely to encounter during your DevOps Transformation (either for your company, or for your self). These principles are battle-tested and core to really understanding the objective truths about the state of your organization’s technological capabilities, and the cultural barriers to improvement. Both books are very much worth reading and reflecting on.