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

By Matt Asay


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".


Becoming DevOps

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 right here.

Sign up to our NewsletterGet IT in your inbox daily


More from The Register

AI, Reinforcement Learning, Neural Networks... DevOps? Learn more this month

Event Making machine learning work at work

Puppet Insights arrives to shine uncomfortably bright light on DevOps

Want to know if all that cash you spent on consultants is paying off?

Why did Visual Studio Marketplace go down in the Great Azure TITSUP? Ask Azure DevOps

Failover is not an option

Visual Studio Team Services squeezes into new Azure DevOps togs

Azure here, there and everywhere. Except last week when VSTS was nowhere

'The gulf between apps and infrastructure is blurring' says boss of DevOps darling Puppet

Code automation biz waves its big data yardstick

Puppet is a poppet in the eyes of DevOps cash injectors: Automation upstart bags extra $42m

There's gold in them thar hills of servers and daemons

Put on your clogs, take a close look at what DevOps fave Puppet flung out this week

New bits from Amsterdam

CyberArk splashes $42m on DevOps security whizz Conjur

Israeli firm prepares for DevOps deluge

Soft eng salaries soar by 25 per cent – and, oh yes, devops is best paid for non-boss techies

Stack Overflow's worldwide dev survey spills pay figures

DevOps: Social, cooperative... It's gotta be really diverse, right?

Are you having a giraffe?