Starting Our Journey
A Series on Beginning DevOps /part one
It was the end of 2014. I’d been relatively successful at running engineering build, test automation, and tooling for my company, and was beginning to wonder what was coming next in my career.
More or less out of the blue, there was a message from a former Netflix director wanting to talk. We’d met once before over some beers in Sunnyvale, and — as you’d expect — I’d been impressed with his technical insight and forthrightness. The up-shoot was that he felt like I might be a good fit to help with DevOps at the company he’d just joined. DevOps? I’d heard of it, but wasn’t totally sure what it meant. I didn’t say that, of course: what came out of my mouth was something more akin to Sure - I can totally do that… it sounds like fun!
It took several months to get in to meet with senior leadership to formally interview, and along the way I had plenty of time to read up and learn about this DevOps thing. I thumbed through classics like Lean Enterprise: How High Performance Organizations Innovate at Scale, and Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation. I read a lot that was out there on the Internet, and whereas there was some great prescriptive, opinionated stuff such as https://12factor.net there was also a lot of less great opinionated stuff which was simply confusing: the term seemed to mean different things to different people.
One thing was certain: over my career, I’d been struck by the differences in software agility experienced by larger and smaller companies. Specifically, how companies institute silos to aid in division of labor and add control structures and process to help mitigate risk as they grow, but lose efficiency as they do so. This is explained nicely on this section of the original Netflix Culture Deck. I wanted to think about DevOps in terms of how to empower developers to deliver software in a radically improved fashion: how can we reduce the amount of time it takes from commit to getting feedback on the correctness of that change?
But deeper still, I read a little of Ron Westrum’s work, and begun to wonder how can we influence the way in which the organization’s culture drives the value stream.
It seemed like there was a lot to be figured out, and — although it was easy to reach some level of initial clarity — there was a lot to learn, and I’d need help. Fortunately, I was joined by a small set of talented individuals, and we quickly became energized as we worked through our uncertainty to see what we could accomplish.
A little later, and as we’d begun to deliver on our promises, I started second guessing myself: it seemed like everything we were doing was just common sense, and how is it that everyone isn’t doing this already?
Later still, I began to wonder if this wasn’t common knowledge after all, and I presented some of our lessons learned at Voxxed Days in Belgrade. There were a couple of slides in there that I refer back to time and time again, one of which talks about the kind of things that are important to focus on as you’re thinking about a DevOps transformation. I’ve wanted to share that information more formally for a while, and try to cover a lot of it here.
To learn yet more about our journey, you might also want to check out The Five Phases of DevOps.
This is the first of a series of articles on how we learned to radicalize software delivery in order to eliminate operational silos, dramatically accelerate the rate of change, and all but eliminate production outages. Although the content here is definitely opinionated and you’ll ultimately need to find your own path, I hope that you’ll find them useful.
Coming Next: Change is Hard.
This article originally appeared on Medium.