Blog Insights 3 things that are wrong with DevOps today
Published on: February 20, 2018
5 min read

3 things that are wrong with DevOps today

Why are collaboration woes, shift-left waste, and tooling admin costs still plaguing DevOps?


I’m continually impressed by the benefits achieved by modern ways of working. Lean processes, Conversational Development, and automation have helped us ship more value, faster. Those achievements have led customers to expect a lot more from their service providers. DevOps has been critical to those gains, but we’ve got more work to do – DevOps still has its problems.

I have the privilege of talking with GitLab users every day. We celebrate impressive technical achievements, work through complex problems with CI/CD, or discuss new needs for their organization. The needs and problems seem to align themselves to one of three different areas:

1. The wall still stands

Dev and Ops are still at war in some environments. In just the past couple of weeks I’ve heard the lack of collaboration between these groups called “the wall,” a “chasm,” and a “joke” by people in both areas! We’re simply not communicating well enough yet. We’re disappointed that after this much investment, there’s still so much room for improvement. Development and Operations continue to use different tools and to follow different rules.

It's like we're really doing DevSecBizPerfOps

But it doesn't end there. Now we've got more people in the mix analyzing concerns like security, performance, and business metrics. It's like we're really doing DevSecBizPerfOps or some such thing, and so our flow continues to be interrupted. Silos continue to exist, if not multiply. It also feels like Ops hasn’t gotten enough love, which is why GitLab is working toward better Operations views as part of our product vision for 2018.

2. Administration costs are still too high

As we continue to shift left with build, test, and security, admin costs continue to rise. Developers are often being empowered at the cost of their own productivity. Administration efforts can actually consume half a developer’s time each week! Unfortunately, this is a growing form of waste. A core DevOps goal is to reduce administration time, but the admin costs of DevOps tools can be some of the highest in the software development lifecycle ecosystem due to extensive plug-in architectures, support of quickly evolving environments, and asynchronous vendor update woes. We continually increase complexity and add requirements to existing stacks without looking for more modern solutions. Despite all the loss of time, I still hear commonly that there's no way to visualize the flow of the code from requirement to production, especially once code is committed to a repository.

The good news is that more of us are taking the time to re-examine our ecosystems because they've become bloated with a wide variety of tools from a wide variety of vendors for very specific purposes. I wouldn't consider the current trend to be a tooling consolidation so much as a streamlining or simplification of toolsets. Questions I hear most often tend to focus on optimizing our efficiency and reliability while minimizing administration of laborious plug-in and trigger-driven architectures. We're trending in the right direction.

3. We're holding onto the past

We’ve spent and continue to spend billions on software tools annually. Tooling can be extremely costly! Sometimes we’ve invested so much money in old tooling that we simply can’t let it go. Too often we hold onto tools and processes just because we spent a lot of time and money on them while newer, time-saving products are available for less than the cost of the renewal of the old beasts. And so we hold onto the past as we try to implement new technologies. It’s no surprise that shoving new technology into old tools can generate enormous friction and unique problems.

It’s no surprise that shoving new technology into old tools can generate enormous friction and unique problems.

Perhaps we bought best-in-breed tools. Those products commonly require excessive coding efforts to integrate and maintain because "best in breed" typically means we bought from a number of vendors. Interconnectivity of those tools typically doesn’t come out of the box. And of course, once the API is mentioned as a solution, the admin and maintenance burden increases once again. We spend a lot of money on specific solutions but inevitably end up with holes in our end-to-end process, too often as it relates to security or performance.

But this way of looking at tooling is beginning to change! I'm hearing more frequently that dramatic price increases, as well as the outsourcing of product maintenance and support, are triggering enterprises to reconsider the past. When we've invested all that time and money into a product, but that product then gets sold to three different parent companies within a decade, our ROI calculations lose their luster. Outsourcings and vendor-level product sales are being viewed as indicators of a potentially declining market. Enterprises are using that as a trigger to seek out updated tools for the years ahead, reducing cost and enabling modern workflows.

It all impacts delivery efficiency

No matter whether we’re talking about disappointment in collaboration, shift-left waste, or tooling admin costs, it comes down to this: it all negatively impacts our ability to deliver securely with speed and efficiency. If we truly want to meet and exceed the expectations of our customers, we’ll need to continually hone and improve our DevOps processes and tools to reflect modern ways of working.

Photo by Caleb George on Unsplash

We want to hear from you

Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum. Share your feedback

Ready to get started?

See what your team could do with a unified DevSecOps Platform.

Get free trial

Find out which plan works best for your team

Learn about pricing

Learn about what GitLab can do for your team

Talk to an expert