From big data to storage to security, the DevOps concept is being applied to every field of IT operations under the sun today. This “Everything Ops” movement reflects the popularity of DevOps—but is it also diluting DevOps’s significance?
DevOps itself focuses on software delivery. It’s about designing, building, testing, deploying and managing software applications.
If you follow the DevOps conversation, however, you know that DevOps principles are now being extended to lots of niches that don’t have much or anything to do with software delivery chains. Consider these examples:
- DataOps: DevOps principles for data analysts.
- ChatOps: The idea that chat tools should be integrated into workflows.
- SecOps (or rugged DevOps, or DevSecOps, or whatever else you want to call it): DevOps practices for security teams.
- Storage Ops: The insertion of DevOps practices into storage.
The list could go on. Taken together, these many flavors of DevOps reflect what I like to a call an “Everything Ops” tendency. Fans of DevOps want DevOps to take over the entire world of IT.
Benefits and Drawbacks of ‘Everything Ops’
If you believe that DevOps represents a better way to deliver software, then the Everything Ops movement is a positive thing. It’s a way to help people who work in areas of IT other than software delivery to innovate as well by taking cues from their DevOps colleagues.
But there is also a danger that Everything Ops can be applied too broadly. You can’t fit every single thing in the IT universe into the DevOps mold. For example, CloudOps (the DevOps-related way of managing cloud infrastructure, not the company of the same name) just doesn’t make a lot of sense. It’s basically just a reiteration of the ideas that are already at the core of cloud computing: Scalability, agility and location-agnosticism.
Concepts like ChatOps can also be problematic because they refer to a specific way of using a particular type of technology, whereas DevOps is about cultural practices. ChatOps is a fundamentally different sort of thing from DevOps.
Conclusion
In short, by overextending the DevOps conceptual framework, you run the risk of diluting the importance of DevOps itself—and of losing your focus on software delivery, which is the area that DevOps benefits most.
This is not to say that we shouldn’t extend DevOps to other fields. We certainly should. But we should be careful when doing so. Don’t try to make DevOps eat the entire IT world, because that just doesn’t make sense.
