I Thought DevOps Integration was Supposed to be Easy?

We’ve said it on this blog before, and we’ll repeat the same message: Solving a software engineering problem is simple physics. It takes a set amount of energy to move a project from point A to point B, and changing the process or path doesn’t change the unavoidable fact that difficult software problems are difficult to solve. DevOps integration is no different.

If you have a complex, highly-orchestrated release no amount of automation can change the fact that the large, successful systems found in the Fortune 500 are often full of seemingly intractable complexity: databases that have been around longer than most of your junior engineers, middleware systems maintained by teams that have been outsourced to by the teams they were originally outsourced to, and lot’s of risk. In fact, the risk is the common attribute in most big business, and while moving your development and operations teams to work more closely together can reduce your overall exposure to user-error by encouraging more automation, it doesn’t take the risk out of software releases.

…and software releases are all risk. Your downtime doesn’t just happen because software stands still.

What Drives DevOps Integration

Last year I was at an industry conference in New York focused on DevOps, and I spoke about using Plutora to model and manage large-scale releases. Afterwards, I spoke to a number of people attending the show about what they thought about DevOps. DevOps integration is a trend taking all industries by storm, and it sells a simpler, more agile approach to software delivery. A model in which developers have more control over the software and systems they are deploying.

Several attendees told me that they were adopting the DevOps methodology or that they had already adopted DevOps and that it was yielding positive results. Almost all of them made the point that it was less of a technical advance than a cultural change, and one in particular told me that the biggest “before and after” change was that developers now had a greater understanding of production networks and production operations. In this attendee’s mind, DevOps integration was fully realized when her developers understood what was happening when they were releasing software.

DevOps Skeptics: It Ain’t Easy

Other attendees (a minority of attendees at this DevOps conference) told me that DevOps integration wasn’t relevant to what they were doing. I focused on this group because I was curious about what is driving this contrarian view on DevOps. One attendee told me that his company deals with too much security risk to let developers work with production, and while I offered up some solutions like data masking his objection seemed to be more from the position that developers really had no business being responsible for production.

Another attendee told me “DevOps didn’t make anything easier.” And, this was an attendee I ended up having a longer conversation with. His objection, DevOps didn’t come with a set of tools that could be easily adopted without hiring new developers, and it didn’t feel like a solved problem. He suggested that he was waiting until DevOps “grew up” before adopting it. I think he’ll be waiting for some time, but that’s no reason not to move toward a DevOps model today.

They're Right. It isn’t Easy, and it isn’t “Grown Up”

DevOps integration isn’t easy, and the tools haven’t matured yet, but if you look at software development over multiple decades who can argue that software development is a mature practice? We started Plutora because we took a long-term perspective on software development with the understanding that the tools we use to manage software projects are inadequate to tomorrow’s challenges.

Anyone waiting for anything to “mature” in today’s software industry is going to be waiting quite a long time, and in the meantime they are going to be busy growing irrelevant to the trends and challenges that will define success in the coming decade. It is true that adopting DevOps and embracing continuous delivery in the enterprise involves some risks, some unknowns, but innovators always have to take some risks in creating the technologies of the future.

I think the DevOps adopters got it right when they told me that the biggest difference was understanding – the understanding that developers gained when they became responsible for production deployments. It is this awareness that leads to DevOps transformation not the adoption of some point-and-click tool that will make software easier.

Again, that tool will never arrive, software challenges will always be difficult and complex, it’s the project management challenges and the communication challenges that we have some control over, and Plutora is our attempt to change the game.