For years, self-service has been touted 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, for example, with a workforce of close to 200,000 internal and external developers.
Self-service DevOps platforms promise virtual self-service kiosks 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 are available, but has anyone actually figured it out yet? After all, 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 a big-picture strategy; it makes compliance simpler with automation, safety 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 happened with the SolarWinds breach of 2020
● Inactive accounts that leave a door open to cybercriminals, as we saw with the Colonial Pipeline breach of 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 require significant effort to update and maintain workflows and meet or exceed 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, for example, choosing a self-service checkout to avoid a long line at the grocery store 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 the 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.
