During our recent chat, Puppet Labs CEO Luke Kanies disabused me of the notion that DevOps fits my original peanut butter cup analogy. “It’s obvious the misconception happens because of the name,” Kanies said.
According to Kanies, DevOps primarily is about aligning operations teams with business goals.
The business wants to be secure, but it doesn’t want security at the cost of being able to adopt new technology. It doesn’t want compliance at the cost of being able to actually provide services to its customers. So it’s critical for operations to find a way to on the one hand, meet the regulatory needs of the organization [like] security [and] compliance, while on the other hand, still clearly and effectively deliver the services to business needs when they need to to the people who need them.
Damon Edwards, president of DTO Solutions echos Kanies’ opinion in his Dev2Ops blog that DevOps is a business problem, rather than a technology one. He explains in his post “DevOps is not a technology problem. DevOps is a business problem” that:
In my opinion, one fault of the early DevOps conversations is that it wasn’t immediately clear just how big the scope of this problem truly is…but alas, the conversation had to start somewhere so it gravitated to the almost universal problem of conflict and disconnect between Developer culture and Operations culture.
Kanies points out that as operations teams move to align with business objectives, they will find themselves working closely with developers since the latter make many of the tools the company sells. For example, Kanies mentioned a bank that employs 19,000 software developers, all of whom need safe production environments to run their applications. Without a good operations team, the aforementioned bank could end up in a situation similar to [what happened] when Google CTO Ben Fried launched an application for a large institutional investor several years ago.
In a recent Ars Technica post Google CIO and others talk DevOps and “Disaster Porn” at Surge, Ars Technica IT editor Sean Gallagher recounts the genesis behind the catastrophe:
The real root of the problem, Fried said, was the way the organization around the system had been built. “Without even thinking about it, the way we scaled up was through specialization,” Fried explained. “We added people to specialized teams, each operating within a functional boundary. We never said understanding how everything works is important.” Because none of them had knowledge of how the application worked beyond their area of expertise, the teams made decisions that led to a “hard failure” of the application.
Add the fact that operations teams also also are responsible for managing off-the-shelf applications, firewalls and configuring production and testing environments, among other things, and you can see how operations ends up acting as the glue that keeps everyone, including developers, united toward the same goal. As Kanies told me:
Operations can focus on stability, consistency, security [and] compliance in their core platform. And they put applications on top of it and provide restrictions for developers, [such as not allowing them to] deploy that version of the application because of possible vulnerabilities. Overall, they’re providing a context, [so that] a given application team can have its own cadence, and release cycles, that operations doesn’t have to take ownership of.
Next: How the new ops paradigm enables developers to take ownership of their applications…
