Not long ago I met with a couple of colleagues of a friend to talk about devops and the directions operations is going these days. It was an interesting discussion, especially given the fact that they worked for the DoD (either directly or indirectly as contractors) pretty much their entire careers. During their careers, they have been stuck in highly-silo’d/stove-piped environments with layers upon layers of bureaucracy, and they are exploring their options on how to get out of that world.
During our discussion I talked about what exactly is devops. This has been something that has been on my mind since starting my current position as RoomKey.com’s ops guy, and the job description explicitly described it as a devops role.
At the time of my hiring, and to some degree at present, I viewed the term devops as a bullshit word that means different things to different people. In much the same way companies claim they are an Agile development shop, but really aren’t, I believe there are folks who claim they’re a devops shop but really are not.So what exactly is devops?
I recently read @jezhumble‘s rant titled There’s No Such Thing as a “DevOps Team.” Jez made a number of good points, primarily of which is that devops (like Agile development) is not something that can be forced top-down by management. Managers cannot just draw a box that overlaps with both their development and operations teams and expect devops to happen. Conversely, devops is about removing that box, and erasing & blurring the lines between dev and ops. As Jez accurately states, “Devops proposes instead strategies to create better collaboration between functional silos …”
Jez also maintains that:
… the “devops team” is not on the hook for the systems that get built, or for deploying them, or writing the build and deployment scripts, or for the operation of those systems. Nor should there be “devops specialists” on development teams doing this work: this is core developer work, the same as writing code, and developers need to own it.
This is where I diverge from his vision, as he makes devops sound like a Platform Engineering team who hands off tools for dev to consume. I disagree – a good ops team who is practicing devops is involved with build & deployment scripts. The ops team is ultimately responsible for keeping the site (and/or application) online, and deployments are activities often overseen by them. Because of this, I believe that ops should own deployment scripts.
That aside, devops is 100% about collaboration. Starting at my first full-time job at the Computer Science Department at Virginia Tech, through a brief stint at AOL and a long stint at a payments start-up, and finally my current job at Room Key, I have been cooperating and coproducing with my colleagues outside of the ops team.
If it’s dropping an infrastructure engineer in a development team, a developer on an operations team, or distinct dev and ops teams, devops is about having open lines of communication between development and operations and about having both sides involved in product delivery from the conceptual/architectural stages all the way through, and beyond, production release.
In this world there are no walls over which to chuck grenades. (We have all been there before: team A hands something off to team B about which the latter has virtually no knowledge.) Since both teams are apart of the process from soup to nuts, there should be no surprises for either side.
So, what makes a great ops person in a devops role?
If I had to limit the answer to a sentence: Someone who can do a little bit of everything in the ops world with the toolbox of a developer.
In reflection of my 12′ish years of professional experience, I think I can say with a straight face that I’ve been doing devops, in one form or another, for most of my career. I consider myself a senior systems engineer (in an IT sense, of course) with a fairly wide breadth of knowledge: including systems, networking, databases, security, etc. That said, I think I could stop doing operations, start developing software, and not be terrible at it. I have skills related to and a familiarity of programming and development practices, and I believe it is that knowledge which allows me to sit down with our development team and speak the same language. It augments my ability to collaborate with them.
I know of too many folks in IT operations that never get the opportunity to break out of their roles as systems, network, database, and/or storage administrators. And, in my opinion, you really don’t get to work on interesting problems until you are cross-discipline, and it’s that broadening breadth that lends itself well to devops.