What is the DevOps paradox?
I love sharing with others. That's my main motivation when I write a book. There's a hard-to-explain joy in knowing that our work as authors might be helping others. But strangely, that's not the case with DevOps Paradox.
This time, my motivation was much more self-serving. I wrote this book because I personally wanted to understand what DevOps is. Now if you know anything about me, or have read any of my multi-book DevOps Toolkit series (https://www.devopstoolkitseries.com), then you're surely thinking that I should already know what DevOps is, especially if I'm trying to spread my knowledge of it through these books.
The thing is, if there's anything that my years of working in the field have taught me, it's that DevOps is not a well-defined process. There is no set of rules that must be followed. As I discovered in my journey, and as you'll read in these pages, it's even questionable whether there is such a thing as a "DevOps department" or a "DevOps engineer." This ambiguity is exactly why DevOps is so fascinating to me, and I hope to you, the reader, as well.
I love going to conferences, but not for the obvious reasons. I rarely listen to talks. Instead, I tend to roam the corridors of conference centers and convention halls looking for the next victim who will allow me to pick his or her brain. The best thing about conferences is networking. The most interesting conversations are not taking place at scheduled talks, but rather in corridors and at the after-parties.
I consider myself lucky for being able to dedicate an important portion of my time attending conferences since I know that I benefit greatly from those "corridor-talks." I wanted to do something similar with this book.
This book is called DevOps Paradox. For those of you who may be wondering what it means, the Oxford English Dictionary defines the word "paradox" as:
Over the course of these interviews, my objective is to look at these often-contradictory views of what DevOps is, which, as we will investigate, may prove to be well founded.
What we have right now is an idea that people should work more closely together and that we should remove the barriers that slow them down.
As such, anything can be DevOps.
Almost every software company is marketing its products as "DevOps," and "DevOps engineer" is the most sought-after role in job listings. That's not to mention the fact that "DevOps departments" are popping up like mushrooms after the rain.
Yet despite this, almost every person I spoke to in this book gave me a different answer to the fundamental question of "What is DevOps?"
DevOps brings sanity into a very chaotic world created by a misunderstanding that software development is similar to factory production. DevOps continues where Agile left off, and urges us to remove the obstacles that we were often not even aware existed.
The idea of DevOps builds empathy between team members that ultimately results in greater cooperation. It's about culture, but it's also about the processes and the tools. At least, that's what I originally thought, even though I received very opposing definitions from the teams I worked with.
To answer the questions I had about DevOps, I asked a number of DevOps practitioners what they thought DevOps was. Some of them are industry veterans, while others are up-and-coming stars. Some are my friends, while others are people I have admired from afar.
Many of these conversations were recorded via remote sessions, while others took place in pubs or in conference corridors. Whenever I could, I did my best to speak with someone face-to-face.
I wanted the interviews to be casual. I did not want people to answer predefined questions. Instead, my goal was to bring to a wider audience the types of conversations I normally have with experts I meet in conferences and in companies I work with as a consultant. I do believe that some of the best breakthroughs come from corridor-talks. That's the spirit I wanted to maintain in the interviews.
Each conversation starts with the question "What is DevOps?" or some variation thereof. It is only meant to be a conversation-starter and to facilitate something that is an unstructured, unprepared, and very casual conversation. Think of each interview as a conversation with a friend or an acquaintance that I've met in a pub. As a matter of fact, a few of them were actually recorded in a bar over a few beers!
In this book, I wanted to share casual conversations with people who practice and often shape DevOps. My hope is that we'll get insights into what drives those people and come away with a better understanding of what makes DevOps so powerful.
The only thing the people I interviewed have in common is an interest in DevOps itself. You'll see, however, that some of them have very opposing views of what DevOps actually is (or is not), and even whether it's a worthwhile pursuit. You may often feel that what is described by one person contradicts what others have said. This is intentional and, in my opinion, reflects the chaos DevOps is trying to tame. It also serves as a reminder that we are still in the very early stages of adopting DevOps to our workplace cultures, while trying to navigate the complexities of the software industry and finding different solutions to the same problems.
With all that said, I urge you, the reader, to be open-minded. You've almost certainly heard about DevOps, and many of you are likely implementing some form of DevOps in your organizations right now. I just ask that you leave what you know aside. The interviews in this book are likely to turn everything that you think you know upside-down. They will definitely challenge your assumptions and your experience. What this book won't do, however, is tell you on which side of the DevOps debate to pitch your tent. There is no right or wrong answer here. This book also won't tell you how to "do" DevOps, though you may glean some ideas for implementation from the experiences related in these interviews. My goal with this book is solely to present both sides of the DevOps paradox and leave the door open for you to make up your own mind.
How ironic that something designed to break down silos within organizations and foster cross-departmental collaboration is the subject of so much debate within the IT community! But that's the crux of the DevOps paradox, isn't it? And that's why it's such a fascinating topic of conversation. You may not agree with everything you read in these interviews, but at the very least they should provoke thought and maybe even debate within your organizations as you and your teams embark upon your own DevOps journeys.
Lastly, before we get started, I'd like to thank those who gave their time to be interviewed, I couldn't be more grateful for all the great contributions you made. Thank you! This book wouldn't be what it is without you!
I do my best to be approachable and help people improve their skills. Feel free to contact me on Twitter (@vfarcic), to send me an email (viktor@farcic.com), or to join Slack workspace DevOps20 (http://slack.devops20toolkit.com/).
Viktor Farcic is a Principal Software Delivery Strategist and Developer Advocate at CloudBees, a member of the Google Developer Experts and Docker Captains groups, and published author.
His big passions are DevOps, microservices, continuous integration, delivery and deployment (CI/CD) and test-driven development (TDD).
He often speaks at community gatherings and conferences.
He published The DevOps Toolkit Series (https://www.devopstoolkitseries.com) and Test-Driven Java Development (http://www.amazon.com/dp/B00YSIM3SC).
His random thoughts and tutorials can be found in his blog TechnologyConversations (https://technologyconversations.com/).
