Blame DevOps on open source. After all, it was the open source movement that gave developers the idea that they were free to code, free to build applications and other software for their companies without needing prior approval. It was open source that crowned developers kingmakers. It was open source that gave developers the freedom to not only write code, but also manage it.
It was open source that gave us DevOps.
DevOps: Freedom To Get Stuff Done
Traditionally, IT operations has been a specialized task, an exclusive one that largely controlled the code allowed to run within the enterprise. Given the fact that all software had to be purchased before it could be run, there was little risk of developers or anyone else introducing rogue software into the hallowed halls of the data center.
Enterprises were able to enforce policies because all software had to start with Purchasing and end with Operations. There simply was no other viable way to get software into the enterprise.
That is, until open source.
Open source ruined the neat and tidy relationship between Purchasing and Operations. Suddenly software didn’t have to be purchased. It could simply be downloaded. As pressures mounted on lines of business to accelerate their pace of innovation, developers stepped up: “I have an open source project for that.”
Operations fought back, trying to crimp open source adoption. They failed.
There simply was too much pressure on developers to get stuff done. Once Amazon gave developers a home outside the data center to deploy their code, the battle was over and a new model for building and managing code was born. Dubbed DevOps, the movement gave developers end-to-end control over their creations.
Since 2011, DevOps adoption has increased 26%, according to a 2013 survey by Puppet Labs, resulting in 50% application failures and the ability to recover up to 12X faster. The rise in DevOps also translates into the ability to ship code 30X faster. All of which is expressed in a separate CA Technologies survey of senior IT decision-makers, which found that improvements to the customer experience is by far the biggest reason enterprises are embracing DevOps.
Given these improvements, there’s no way we’re going back to Operations-focused IT.
Blessing Or Curse?
All of which is not to suggest that DevOps has been an unalloyed blessing. In my experience, developers are often unprepared or unwilling to take on the burden of managing their applications in production. Trained for years on the idea that they could build an application and dump it on Operations to manage, developers are discovering that the “Ops” in DevOps is real, and sometimes really a pain.
For example, one big problem is that production environments and dev/test environments are typically very different. An application that works flawlessly in a small-scale test environment may miss a whole class of errors that only occur in the presence of the more complex production environment (e.g. problems that only occur when application changes interact with a complex, zoned network topology).
The reality is that over-optimizing for Ops (safe, secure and slow) or Development (Fast, opportunistic, iterative) proves sub-optimal. A balance is needed.
But that balance increasingly skews toward upgrading Ops to meet developer demands. Indeed, developers are writing a host of infrastructure and tools to help other developers better manage their creations. Often such tooling is SaaS-based, and a significant percentage is open source, allowing developers to continue to skirt the controls of Operations while maintaining flexibility. Companies like Boundary, Puppet Labs, SumoLogic and more have arisen to make operations easier for DevOps professionals, among others.
My own company, MongoDB, develops the most popular database for modern applications. Universally lauded for how easy MongoDB makes development, our tools for facilitating the operation of MongoDB at scale have lagged. Over the past two years we have been building out monitoring, back-up and other management tooling for MongoDB. It’s simply not enough anymore to forget the “Ops” in DevOps.
No Putting The DevOps Genie Back In The Bottle
I expect we’ll see this trend continue. The power of developers will increase in large part because the industry will better enable them to manage their applications, or to work more seamlessly with their Ops peers. But the era of Ops dictating to developers is over.
Blame open source.
I think this is the first time I’ve ever disagreed with something written by Matt Asay almost completely 🙂
What you write is not wrong per se but it’s definitely not what happened and not the reasons why DevOps happened. DevOps is all Agile’s fault as clearly documented by the people who gave birth to the movement. See The (Short) History of DevOps http://www.youtube.com/watch?v=o7-IuYS0iSE
And DevOps is definitely not about giving “developers end-to-end control over their creations”, it’s about getting devs and ops collaborating from the get go.
Purchasing doesn’t even get into the picture is we are talking about the reasons devops was born
All IMHO of course 🙂
Marco
Marco,
I think I have to disagree with yo disagreeing.
If you rewatch the video you’ll notice a couple of people showing up starting with Patrick, then more people that were at the very first devopsdays , ,you’ll notice that about all of us were Senior Open Source people, almost nobody from the proprietary world was even involved. (Patrick used to have a company called Supporting Open Source, I’ve been doing Open Source for almost 20 years now ).. and a lot of the people at the inaugural devopsdays were people we met at some Open Source or System administration conference before that felt the need to close the gap and build a bridge.
There were a lot of influences and Agile certainly being one of them that lead to us organising #devopsdays, but to me the foundation still is Open Source and always has been .. I still have my strong doubts that you can even do something that smells like devops if you don’t adopt Open Source and its principles. (You can even find Patrick on a Podcast about #monitoringsucks stating that if a tool isn’t Open Source it doesn’t exist to him)
Where Matt however does miss the ball is that it were the says the Operations People were fighting back. Where that might still be the case for some Old School organisatoins where some Ops people don’t get it .. the majority of visitors at the the first couple of #devopsdays event were ops people wanting change, plenty of times we even discussed how to get more developers involved as it took us a couple of years to get the balance right.
So imnsvho the devops movement was started by a number of Senior Open Source Systems people that saw how to improve their work by collaborating better with the developers.
A great article. Thank you.
Good article and closely mirrors my experience with speaking with developers who often see no value in commercial and supported applications, favoring open source apps overall.