While there are many DevOps self-serve options available, many issues still exist between Devs and DevOps. Headless self-serve is a new approach to consider.
Join the DZone community and get the full member experience.
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?
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.
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
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.
