It's a decade since DevOps became a 'thing' – and people still don't know what it means
You can't buy or hire a mindset
To everyone with DevOps in their job title (and a quick LinkedIn search turned up 45,597 of you just in my network): folks, you're doing it wrong.
To every employer looking to fill positions like "DevOps engineer" (and there are plenty): you, too, are miserably misguided.
As it turns out, DevOps isn't "a job title, a software tool, a team name, or magic enterprise fairy dust", as Slice director of Engineering Brian Guthrie intones, but rather "a set of practices that encourage continuous integration into production".
We know this, right? And yet those job titles, that tooling... we can't seem to get away from them. Vendors complicate this problem, but given that DevOps is really about culture change, the primary person to blame in all this mess is you. You're also the person who can fix it.
Confusing the issue
Maybe we're just too lazy to put in the work to become DevOps-minded, though, to the industry's credit, the desire to "get DevOps" is real. Roughly 10 years after DevOps was coined as a thing, enterprises are madly scrambling to embrace it, as survey data uncovers. The problem is that too often we think it's about hiring a few "DevOps engineers" and setting them free to... DevOp... or whatever.
Vendors, not surprisingly, haven't helped.
Take New Relic, for example. While the company is quick to call out DevOps as a "software delivery methodology that combines developers and operations into a single unit", it's just as eager to talk about it like DevOps is closely aligned with tools you can buy ("New Relic is just one of many important tools you'll need for your DevOps efforts"). This is true in a trivial sense – you're going to want things like Puppet to enable automation, a key feature of the DevOps mindset – but you could buy every so-called DevOps tool on the planet and still not be any closer to enabling a DevOps culture.
And those are the "woke" DevOps tooling companies.
Old-school vendors like BMC are much worse. For example, BMC's site is a mishmash of meaningless buzzwords, all targeted towards "your DevOps team". CA Technologies, for its part, waxes lyrical about its "DevOps solutions" and how they help to "redefine culture" around DevOps. Finally IBM lumbers toward a "Cloud Garage Method".
DevOps emerged from the necessity of operating web services like Google at gargantuan scale. As Mike Loukides has written: "DevOps was the inevitable outcome of building and operating the sites that became the web's giants." As he explains, once a website involves "thousands of computers distributed worldwide, you can't just log in and do an upgrade. You can't give a few commands and reload the site. At this scale, automation isn't an option. It's a requirement."
Importantly, what the web giants discovered is that development, divorced from the operation of its code, simply moves too slowly. Far too many companies think of DevOps as an isolated team or person, when it's really the confluence of different disciplines.
According to Guthrie: "If you think DevOps is a toolkit and not a practice you're missing the point. If you think it's a role and not collaboration between roles you're missing the point. If you think it's a team and not an organisational feedback loop you're missing the point. The goal of that journey is the acknowledgement and recognition that software is safer when people with complementary skillsets in technical operations and software development work together, not apart."
Again, it can't be stressed enough that DevOps is not a skillset and it's not a toolset: it's a mindset. That mindset involves a collaborative approach, whereby operations folks trust product developers to deploy code, and product developers neither understand nor trust the way operations needs code deployed. One way to think about it is that developers need to think about the stability of the product as just as important as the features; that is, that "the product" is the complete experience with the product, and not merely a long list of features.
But let's be honest, you're not there yet.
OK, now what?
After all, even if you buy all that, you still probably carry a "DevOps ninja" title or something like that, and there's not much you can do about it. (P.S. A better title might be something like "Operations / Automation / Release / Infrastructure / Deployment / Software / DevTools Engineer," as Michael Sverdlik prefers, but the Rolling Stones were right: you can't always get what you want). After all, that's why they pay you the big bucks! However, there is something you can do. Actually, a few things.
For one, says Guthrie, you can focus on "incremental change, tight feedback loops, shared knowledge, and mutual respect". If you're a developer releasing large changesets, you're part of the problem. Work on incremental change with an eye towards performance and stability. In other words, start to change culture by virtue of how you change the way you develop software.
For operations folk, it's time to start measuring everything, perhaps starting with time to market and cycle time, as Magnus Hedemark has suggested. The first measures the time it takes to go from conception of a feature to the point that a customer can actually consume it, and the latter measures how long it takes to go from an engineering team working on a project to the customer being able to access it. Both help to fine-tune the overall effort necessary to delivering software.
Another important step, Hedemark points out, is to kickstart a process.
Hedemark says: "DevOps success requires an organisation to put a regular (and hopefully effective) process in place and relentlessly improve upon it. It doesn't have to start out being effective, but it must be a regular process. Usually that it's some flavour of agile methodology like Scrum or Scrumban; sometimes it's a Lean derivative. Whichever way you go, pick a formal process, start using it, and get the basics right."
It's not critical that the process is fantastic to start. The point is that it's something the various team members agree upon and are empowered to tweak/improve as they go. It's also important to visualise this process, so that everyone clearly understands the workflow and can point to where issues bottleneck it.
Such suggestions won't magically make you into a DevOps-minded organisation, but they help to start changing culture. Which, of course, is the point: DevOps is simply not something that you're going to buy or hire tomorrow, but rather something you can help your organisation to become over time. How much time? Well, that depends on the people around you and their willingness to change, as well as yours. Just don't expect them to change simply because you crowned them the DevOps team/person. That's the route to failure. ?
We'll be covering DevOps at our Continuous Lifecycle London 2018 event. Full details, including early bird tickets, right here.