When Self-Serve DevOps Forgets Who It Serves

For years, the industry has touted self-service as the salvation of DevOps. Why? Well, every department in your organization has its own reasons for putting self-service DevOps at the top of its wish list:

• Ops teams need to ensure high availability, performance, and security
• Dev teams need speed, self-sufficiency, and transparency
• Security teams need guardrails, compliance, and accountability
• And, of course, the C-suite needs ROI, strategy, and insight on top of everything else

These goals often cause tension—especially between Dev and Ops. Verifying security takes time that developers usually don’t have. And once at scale, even the fastest manual processes break down. Like at the U.S. Department of Defense, with a workforce of close to 200,000 internal and external developers. 

Self-service DevOps platforms promise virtual self-service kiosk for software delivery, uniting teams and creating a frictionless path to independent developer access and provisioning. According to the State of DevOps report from Puppet, self-service DevOps is a hallmark of “highly evolved” DevOps organizations.

Many self-service solutions have become available, but has anyone figured it out yet? Afterall, if everyone is happy with their self-service approach, why are they still searching for answers?

Approaches to Self-Service DevOps

True self-service DevOps promises a wide range of benefits: It lets Ops stop rushing to put out fires and shift to big-picture strategy; it makes compliance simpler with automation, safe guardrails, and clear accountability. And, there is the promise of tremendous capital efficiency.

It’s no surprise that so many vendors are rushing into the space, offering so many flavors of approaches that Baskin-Robbins would be jealous:

• Internal developer portals
• Shared service platforms
• Workflow automation
• ChatOps/Chatbots
• Service catalogs
• API marketplaces 
• Cloud competency centers

But let’s face it: in reality, most of these approaches fail. And when self-service isn’t working as it should, and companies fall behind on their service request queue, many DevOps teams default to risky practices that aim to expedite operations but actually expose the company to attack:

• Over-privileged and over-permissioned accounts, that give broad access to anyone who gets their foot in the door, as in the SolarWinds breaches of 2020
• Inactive accounts, leaving a door open to cybercriminals, as with the Colonial Pipeline breach in 2021

What you might not realize is that these two risks are so prevalent that IBM Security X-Force penetration testers managed to use them to hack into 99% of client cloud environments. So when we say self-service DevOps is failing, it’s failing big-time.

So what’s the solution? Why is true self-service DevOps so hard to achieve?

Why They Fail

There are actually a number of reasons why today’s self-service DevOps platforms fail: 

• They break end-user workflows, forcing users to change their behavior and learn new processes.
• They force devs to switch context, which kills productivity.
• They need domain expertise to operate, reducing the target audience that can use them.
• They’re heavily reliant on “human in the loop” involvement, often creating more work.
• They demand significant effort to update and maintain workflows and maintain SLAs.

Most importantly, with current self-service DevOps solutions, users are often flying blind. They “don’t know what they don’t know,” for instance, how to locate, search, identify, create, and use resources and workflows.

Imagine choosing a self-serve checkout to avoid the long line at the cashier. But then...

a) You get stuck behind someone frantically trying to scan a wrinkled, expired coupon.

b) You get stuck behind someone who doesn’t understand barcodes and scans all their items twice.

c) You forget that alcohol requires age verification, causing an alarm bell and flashing lights to start going off above the register - (spoken from experience, embarrassing).

d) All of the above.

In all these scenarios, a human attendant must come running to fix things, defeating the whole point of self-serve. Self-service is only self-service if it’s easy to use even when things go wrong.

With most so-called self-service DevOps solutions, if something goes wrong, you’re back to waiting—drawing the operator back into the loop—just like with the old system.

What True Self-Service Devops Looks Like

To achieve true self-service DevOps, you need a few elements in place.

Headless UI 

Most developers are (gasp!) human beings. So the best interface is no interface at all. Why not let developers express their needs freely in natural language using existing tools such as Slack, Microsoft Teams, or a command line interface?

Workflows

Developers are frustrated when processes don’t make sense or take more steps than necessary. Let’s adopt workflows that actually handle all the nitty-gritty—so that all developers need to do is ask (in their own words) to be granted access to resources, information, and workflows.

Intelligence

For developers, there’s nothing more frustrating than not knowing where to turn for information you need. True self-service DevOps, powered by AI, will use your existing data to provide a single source of truth with all the answers and insight devs need. 

End-User Feedback Loop

An ideal self-service DevOps platform will ask the developer for feedback that is then used, in turn, to improve the platform itself. First, because everybody enjoys having their voices heard, and second, because this reinforces the role of the platform, which is to serve DevOps by improving the end-user experience. Similar feedback loops have been used in apps like Waze, which uses social navigation to continuously improve the quality of its end-user experience. Self-service DevOps is next in line. 

Once you’ve accomplished all of this, you can work more efficiently, providing immediate on-demand assistance, so your Dev and Ops teams can work without interruption.

How will you know when you’ve achieved true DevOps self-service? When you forget you ever did things any other way—and wouldn’t go back for a million dollars. When you wake up one day and realize that your platform not only lets you build trust and accountability but also gets all your teams working together...and—(gasp) dare I say it?—having fun. 

That will be the last DevOps platform you ever buy.

This article was originally published on DevOps.com.