Managed services killed DevOps

DevOps, as we know it, is dead. Perhaps not many people agree with me, but the age of DevOps is just about over. Then again, perhaps this won’t come as a surprise to some.

While certain industries somehow manage to survive for years — decades, perhaps — without needing to make fundamental changes, that’s absolutely not the case in the software world. Developers consistently reinvent the wheel, and our tools and practices just keep getting better and better by building on existing technologies and constantly making improvements. These kinds of shifts are what have led to the rise of DevOps in the first place, after all.

So why is DevOps, as it exists now, going away? It’s a “Perfect Storm” scenario in some ways. Lots of events coming together that drastically change the status quo. And where it all began was the concept and eventual widespread adoption of agile development and continuous deployment practices.

DevOps was invented as a way to unite developers and IT operations (system administrators) to help them find a common ground. The premise was to automate the development and deployment tools that require collaborations between both disciplines. But someone still has to come in and write the required tool set. Thus, most companies resolved to create DevOps teams that combined the expertise of both sides to support their developers.

The old model of throwing the code over the wall to system administrators who would deploy it stopped working with agile processes and continuous deployment practices. Whose responsibility is it when something goes wrong — the person deploying the code or the developer? Developers don’t know much about deploying and systems administrators don’t know much about how the code is supposed to work.

In a way, this is the same antipattern (to borrow a term popularized by Andrew Koenig) that led to the QA team. And now QA is dying, too; no one can afford to have it in the middle of continuous deployment. Developers are responsible for full test automation and making sure their code works. Once code is verified and ready, it is pushed and enabled in production. Developers know they are responsible for what happens with their code as it hits production.

Thus, we declared “all deployments shall be automated” and DevOps teams were born — not without quite a bit of confusion in the market over the definition itself of DevOps. The fat lady sang and system administrators were pronounced DevOps, and they started to learn Python to develop tools. Developers who knew a thing or two about operating systems and networking joined in to help them with development.

For a time, all was good and peachy. DevOps teams were happily developing their custom tools, allowing developers to deploy the code to production with a push of a button; but they were still managing a lot of infrastructure the same way system administrators were doing it before — databases had to be expertly installed, replicated, clustered, cached, etc.

But before long, another problem crept in. No one wanted to invest a lot of money into DevOps; they don’t write the product’s sexy features and they are, frankly, the cost center of your cost center. The teams were bare bones — they did the minimum work necessary, but it was tough to get the tools to the point of great reusability and give developers enough control to configure the tools themselves. Suddenly, DevOps became the bottleneck. And all wasn’t quite so peachy and rainbow-y anymore.

So, who’s to blame for the demise of DevOps? That’s easy! It’s everybody’s friend, the cloud.

And when I say the cloud, I really mean managed services.

Today, developers are increasingly turning to managed services for toolsets and infrastructure requirements — tasks traditionally managed by DevOps teams. Amazon Web Services and other managed service providers have allowed for a dramatically simplified way of working, reducing complexity on the developer end and, thus, allowing them to focus on software development instead of installing databases and ensuring processes like backup, redundancy and uptime. In other words, managed services removed a lot of headaches with which DevOps teams were forced to deal.

While it might be hard for some people to accept, the only conclusion can be that DevOps teams are creating the same problem they were initially built to solve. DevOps was established to speed things up, but because of the nature of managed services today, you no longer need a whole team to facilitate them — why not simply teach all developers how to utilize the infrastructure tools in the cloud? The truth is, like QA before it, DevOps has itself become an unnecessary step in the continuous deployment process. As such, it is obsolete.

Does DevOps need to go away entirely? No! In fact, it will live on in existing development teams. DevOps at its core should really be a culture, and the very important skills it cultivated over the years should be imparted to all developers, especially those of the next generation.

The DevOps role itself will live on in a different state, though — largely to manage governance issues like centralized security and cost management, because, while the cloud provides flexibility for instantly provisioning new software and tools on demand, the flip side is you have to be careful with it — otherwise you can unintentionally provision more than you need, and you’ll end up spending a fortune.

DevOps as a team may be gone sooner than later, but its practices will be carried on to whole development teams so that we can continue to build upon what it has brought us in the past years.

DevOps is dead. Long live DevOps!