Gene: You were a vocal critic of the idea of DevOps. What was the basis of your skepticism?
Rob: There are a couple of gut reactions that an old-school IT person like me has to DevOps:
● Anything that accelerates the rate of change or increases volatility inherently creates risk.
● Anything that hands control to the developers is letting the cowboys free on the range.
We Ops people all have the scars of past experiences that reinforce these attitudes. I have one client where the Internet team releases every Tuesday and all of the business people and the service desk brace themselves. “It’s Tuesday; it’s change day. Is everybody ready for the inevitable consequences of the fact that these Internet-y people are rolling stuff out weekly?”
Gene: What were the “a ha” moments that changed your position?
Rob: There were two.
One was debating John Willis (@botchagalupe), and he said a few things that really resonated with me. One was, “We can get a fix into production faster than you can schedule your emergency CAB (Change Advisory Board) meeting.” When I asked what the auditors think about giving development a path all the way into production, he said, “They love it, because the only entity with root access to production is the automation engine.” The fact that you’re restricting the number of people who have root access and you’re creating an automated audit trail of what happens to production—that hit me.
The thing that finally tipped me towards embracing DevOps was Jez Humble’s (@jezhumble) blog post about antifragility. The concept of antifragility was new to me. I suddenly realized that these lunatic DevOps people are not trying to make things more fragile. We’re both moving away from fragile, it’s just that old school is moving towards robust and new school is moving towards resilient. That was the final piece that enabled me to say, “Okay, I get it”.
Gene: What are you most excited about around DevOps?
Rob: There is a profound sea change going on in IT, and it’s all about liberation of people. We haven’t seen such a change in decades. DevOps is just one major facet of something even more profound. It is that aspect of DevOps that really excites me.
I was scrabbling for a word that resonated and I went with “liberation.” The analogy is to the Women’s Liberation movement and how profound that was in changing the world. Then after talking to your co-author George Spafford at DOES15, I got a better term: “The IT Renaissance.” This major shift is profoundly changing the world of IT people. When I looked at Shadow IT, BYOD, DevOps, Agile, mobile apps, social media—all of these things that are going on—the common thread that I could see was a new way of thinking, new ideas, liberation of people, empowerment of people.
Also I’m excited by anything that challenges me. I’ve been talking about how DevOps “does your head in,” how it flips a whole lot of your preconceptions and your assumptions.
There are exciting consequences of DevOps: being more nimble, accelerating our ability to deliver, becoming better aligned with the business, giving people their life back. Another big “aha” for me was when you [Gene] said “humane IT,” how you want to improve the lives of a million people. Why can’t we go home at four? Why can’t we remote in on the weekend and check that a release is going properly and then go back to playing with the kids? Why isn’t that normal? That was a big “aha” for me.
Gene: What advice would you give to DevOps proponents who are having to convince skeptics?
Rob: For the old school, it’s all about risk. There is another phrase that I use: “to protect and serve.” I’m a big fan of policemen, and there is a parallel between IT people and cops: cops are getting a lot of scrutiny at the moment, but most of them are decent people trying to get a job done in an embattled state where they’re battered into a corner by the environment in which they exist. You can draw some interesting parallels between the mental state of cops and traditional IT people.
Anyway, the phrase “protect and serve” is sometimes contradictory. We in IT are the custodians of the existing systems: we are there to protect the investment, the asset of information and its systems. At the same time, we are there to serve the needs of the business. Generally, Protect is about resisting change and Serve is about enabling change; trying to be more responsive, nimble, faster. IT is caught in these conflicting obligations to the organization, to both protect and serve simultaneously. The old school tends to skew towards Protect and the new school is more about Serve.
The old school, in this Protect mind-set, will only hear risk when you talk about a change like DevOps. You’ve got to show them that by doing Serve, by accelerating the rate of change, they’re not endangering Protect. I don’t think DevOps people talk enough about how low-risk DevOps really is. There is too much talk is about how great it is, how fast it is, how much change it enables. The conversation with old school IT should be about how DevOps is reducing risk and error while increasing controls and automation. DevOps is actually doing both things: it’s protecting and serving.
We must be patient. Not everyone is an early adopter. For some people, you’re just going to have to wait until they’ve seen it. We have this perception in IT that because you can change software in seconds, that you can change process and people as quickly. We lose sight of the human rate of change.
In a decade’s time, we will see that half the organizations are doing half DevOps. It’s going to take a significant time for the human rate of change. We are going to have to wait for some people to retire before this stuff gets in.