DevOps Tools: Why We Don’t Need More CI/CD Suites

There’s an old saying among Unix acolytes that a well-designed software tool should do one thing and do it well. Looking around the DevOps tools landscape today, it seems that wisdom has been forgotten. The DevOps market is filled with platforms that try to do many things at the same time--and, in some cases, do none of them well.

This begs the question: Have DevOps tools grown too bloated and broad? Would developers be better served by a DevOps tools marketplace offering them a selection of focused tools, rather than a litany of platforms that promise all-in-one, end-to-end, fully automated and continuous solutions for everything under the sun?

I think the answers to those questions are yes and yes. Here’s why.

A Brief History of DevOps Tooling

When the DevOps concept emerged more than a decade ago, the DevOps tools market did not yet exist. As a result, it was up to DevOps practitioners to decide which tooling would allow them to operationalize the theories at the core of DevOps.

They did this by using an array of individual tools to construct continuous integration/continuous delivery (CI/CD) chains. They combined continuous integration servers (whose functionality, at the time, was still actually limited to continuous integration) with distinct testing frameworks, build automation tools and deployment tools. Each CI/CD chain, in other words, was custom-built from individual tools.

Then, in the mid-2010s, software vendors began offering tools that were branded as all-in-one DevOps solutions. Some of them were extensions of continuous integration servers, which grew into full CI/CD suites. Jenkins and CircleCI are good examples: Once upon a time, these tools were essentially just CI servers for managing code integration, but they now market themselves as complete CI/CD solutions.

GitHub followed a somewhat similar path. In its early days, it was merely a Web interface for Git. Now, it caters to the needs of developers who want a complete CI/CD solution through features like Actions.

In other cases, new DevOps tools platforms that promised all-in-one CI/CD, like Shippable and ElectricFlow (which is now CloudBees Flow), were built from the ground up. Public cloud vendors, too, couldn’t resist getting in on the all-in-one CI/CD action. Hence the development of solutions like AWS CodePipeline and Azure Pipelines.

Even infrastructure-as-code tools, like Puppet, have tried to morph into CI/CD suites. (To be fair, Puppet’s CI/CD solution is about managing infrastructure code more than application code; still, this is further evidence of efforts by vendors of DevOps tools to broaden the mission of solutions that originally had a distinct and specific purpose.)

DevOps Tool Bloat 

Admittedly, many of the “all-in-one” DevOps tools platforms that have emerged during the past decade depend to some extent on integrations with external tools, rather than providing completely original functionality. In this sense, some semblance of tool independence has been preserved within the DevOps tools market.

Still, by and large, I’d argue that the way in which the DevOps market has consolidated around all-in-one CI/CD solutions poses several problems for developers:

It’s true, of course, that there is no law saying teams can’t build their own CI/CD suites from scratch if they don’t like the all-in-one offerings out there. However, given that many DevOps tools now want to be complete CI/CD platforms unto themselves, finding pared-down tools for building a lean, flexible CI/CD chain from the ground up has become difficult. There aren’t many CI servers left that only do CI, or build automation tools that only deal with builds. They tack on release automation, testing and more.

Paradoxically, then, in their quest to make it easier to put DevOps principles into practice using turnkey, end-to-end CI/CD platforms, DevOps tools vendors have created a world where it’s actually more difficult to build an efficient CI/CD workflow.

The Future of DevOps Tools

It’s hard to imagine the all-in-one DevOps platforms disappearing anytime soon. I highly doubt that the vendors behind tools like Jenkins, Puppet, GitHub or any other modern DevOps platform are going to say “Hey, let’s return to our roots by scaling our functionality back to what it was circa 2010.”

Still, I offer the observations above as a warning to new tool vendors in the DevOps market: Don’t get carried away and assume that the only way to succeed as a DevOps vendor is to build a platform that packs every feature that any DevOps team could ever want into a single platform.

Instead, focus on developing a tool that solves one DevOps pain point--like compatibility with legacy application architectures or infrastructure cost-optimization, to name just a couple challenges that are not well-addressed in existing DevOps platforms--and solves it well. That’s what the DevOps market really needs right now--instead of another integrated, “complete” CI/CD product.