Why Are Devs Still Talking to DevOps?!

DevOps got off to a promising start. Way back in 2006, Amazon CTO Werner Vogel prophesied a hassle-free relationship between development and operations: “The traditional model is that you take your software to the wall that separates development and operations and throw it over and then forget about it. Not at Amazon. You build it, you run it. This brings developers into contact with the day-to-day operation of their software.”

This you-build-it-you-run-it movement, which became known as DevOps, got us all excited over the promise that it would destroy silos and get teams working together more efficiently than ever before.

But that was a long time ago. And lately, things haven’t been so sunny in DevOps land. 

What are some signs that the honeymoon is over?

Well, for one thing, developers are complaining that they don’t want to handle ops (reasonably so, since this isn’t their core expertise).

And meanwhile, operations teams are complaining that they’re overwhelmed with minute day-to-day demands from development. As DevOps engineer Mat Duggan writes, operations “still had all the responsibilities we had before, ensuring the application was available, monitored, secure, and compliant,” today they’re also responsible for building and maintaining software delivery pipelines, “laying the groundwork for empowering development to get code out quickly and safely without us being involved.” 

Today, every company says they’re doing DevOps, but all too few are reaping the benefits. Meanwhile, DevOps no longer signals a mindset of innovation the way it used to; today it’s just another buzzword every company has to use.

Is it too late to save DevOps? Or do we still have a chance to get our teams back to the core promise, the excitement of true collaboration, that Vogel and others once foresaw?

Rising Challenges

We’ve seen how DevOps promised to bring a breath of fresh air to the software development world when it first emerged. So what happened? Why haven’t things gone as we hoped they would? Mostly, it’s because of new and unforeseen challenges that have emerged in both development and operations.

Challenges for Development Teams Include:

• Faster integration and delivery cycles

• Loss of dedicated QA to thoroughly test releases (it’s been sacrificed to speed)

• Dev tech stack has grown and become more varied

• More complex and distributed apps with complex microservices architectures

• Security issues and software supply chain vulnerabilities

• Lack of time/incentives to learn more about the ops side of things 

Challenges for Operations Teams Include:

• Lack of clear ownership across the SDLC (with frequent finger-pointing at ops, since apps often work in test but fail in production due to real-world complexity)

• Developer demands for help when app testing fails 

• Handling ongoing monitoring and observability, security, and compliance

• Adapting workflows to integrate IAC solutions with guardrails for safety and consistency

• Troubleshooting abstracted systems (like Kubernetes) — when apps fail, developers have little clue what the problem might be

• Demands to learn significant aspects of the dev stack and tools to solve problems

And then, of course, there are challenges that both DevOps and Ops have in common, such as…

• Faster release cycles force both teams to be on high alert at all times

• Technical debt created by taking shortcuts to meet deadlines but must be paid for tomorrow

• Neither side is able to focus on its core expertise

Finally, an issue the entire community is struggling with is “tool tax.” Also known as “tool sprawl,” or as Sharon Gaudin at GitLab writes, a “mish-mash of tools that force team members to continuously jump back and forth between multiple interfaces, passwords, and ways of working.”

There are so many great DevOps tools out there, but you know things have gotten out of hand when our teams are using, on average, between 20 to 50 different DevOps tools.  

Is Self-Serve the Solution?

As we’ve seen, there are so many issues getting in the way of speedy, efficient development. So what can we do to help our teams get past all these roadblocks?

Some businesses have embraced the promise of “self-serve DevOps” approaches. And in theory, these sound like a dream come true. Self-serve DevOps promises to remove routine demands from operations teams’ shoulders while giving developers the tools, infrastructure, and services they need with simple, efficient requests.

This clears bottlenecks and streamlines development workflow, letting them get back to coding without waiting for operations involvement. And, of course, it lightens the manual workload on ops teams. 

There are a few ways self-serve DevOps is being implemented, at least partially, today:

• Internal developer platform

• Workflow automation tools

• Service catalogs

• API marketplaces

Unfortunately, none of these approaches are ideal. They typically just add one more layer of complexity, actually making the problem worse with another shiny new system for developers and operations to learn and more context switching to distract them from core tasks. 

Also, if you peek under the hood, many of these solutions actually rely heavily on “human-in-the-middle” involvement, meaning operations still gets those calls in the middle of the day — or night — that make their job so nerve-wracking.

Time to Go Headless?

Unlike existing “self-serve” DevOps approaches — that, as we’ve seen, usually simply add more unmanageable complexity — a headless approach offers something truly new and different.

The term “headless” emerged from the world of websites (CMS) and e-commerce. In a headless model, the back end is “decoupled” from the front end. This means that the information (content, catalog entries, pricing, and so on) is “presentation-agnostic.” Your content doesn’t care how it’s displayed — via a web app, mobile app, desktop, and so on. This lets businesses decouple content from how that content is used or displayed, creating a nimble and (in theory) intuitive approach that works across all of today’s devices.

For websites and apps, going headless can streamline development or testing:

• For e-commerce, back-end development can be done without worrying about compatibility/usability for different UIs, e.g. mobile, web, applications, and so on.

• For browsers, testing can be done faster without actual UI loading times, etc.

A headless approach can help us think differently about DevOps as well. Both development and operations today are overwhelmed with tools, as we’ve seen. But what if they could both get their work done intuitively without the need for multiple tools and UIs just to complete a task?

Decoupling DevOps Workflows and Pipelines

With one single clear-cut, streamlined, and intuitive way to access the entire DevOps workflow, developers and DevOps won’t be forced to master and constantly access the wide range of disparate systems such as cloud infrastructure, CI/CD, and identity providers. No new systems to learn. No context switching.

Just one simple interface to rule them all.

In case you think I’m about to suggest adding yet another tool to make DevOps’ lives easier, fear not. I’m actually suggesting the exact opposite approach, and that is to “decouple” DevOps:

• First… detach these mission critical functions from all the myriad systems and UIs that our devs and DevOps are using now.

• Then… give them a way to get it all done in one place.

And not just any place. Somewhere devs and DevOps are already working: their collaboration and project management tool of choice. That could be Slack—which is used by 40% of Fortune 100 businesses—or MS Teams—which has 270 million users as of this writing. 

Headless DevOps takes place anywhere your teams communicate all day, every day. Because only then can they realize the real promise of self-serve with easy and secure access to cloud infrastructure, CI/CD pipelines, information, and more.

Picturing the New Headless Reality

Are you hoping to make your DevOps teams more productive? Wherever they’re hanging out, whether it’s Slack or Teams (or even CLI) you need to transform that into their universal DevOps UI.

This creates a win-win:

• Devs win because they can access necessary cloud infrastructure, trigger pipelines, and so on without needing domain expertise in those areas. Plus, they can do it securely with built-in access control. 

• Ops wins because they can be hands-off for the most common day-to-day functions, letting them focus on bigger-picture issues.

Using conversational AI embedded in Slack, MS Teams, or CLI, you can provide granular access control, automating all your workflows with simple conversations.

The benefits of this approach are no doubt obvious to anyone who’s ever dealt with backlogs and bottlenecks in the SDLC, but just to mention a few specifically…

• Eliminating context switching and repetitive tasks — no more juggling Slack requests, Jira tickets, and a range of other tools and platforms 

• Making automations highly accessible — development doesn’t need to rely on operations to find and trigger appropriate workflows, thereby eliminating human intervention and delays wherever possible

• Ensuring accountability — no more buck-passing, with every DevOps function under a single roof and a clear line of authority

• Improving security — operations build in guardrails to give developers safe and secure access with granular, just-in-time access to resources they can’t normally access

• Ending conflicts — end tension between departments by simply (and safely) giving developers what they want, when they want it

In short, you’ll get your teams back to work like never before.

And best of all, you’ll do it all not by adding another shiny new tool your teams will groan about but by transforming a tool you’re already using into a DevOps powerhouse. Now that’s truly using your head.