And I confess that I viewed the fifth anniversary, which passed in 2014, as a bittersweet milestone.
On one hand, the movement is clearly gaining traction, as more companies embrace the notion of bringing developers and operations people to help produce better software faster.
But I’m also concerned about DevOps’ long-term viability. I think its founders need to do something quickly to give the information technology community a better understanding of what the technique is all about –- or else face issues down the road.
A good illustration of the lengthy distance the methodology has come, and where it could be going, can be had in a recent piece by James Fryman, a DevOps engineer at StackStorm. I’ll chime in later with a little more color about my concerns.
Here are some of the differences in DevOps that have developed over time, according to Fryman:
- From tools to sharing experiences: In talking about DevOps, many people used to focus on implementing tools and processes to make system administrators’ lives easier, Fryman reports. Today, the conversation centers on sharing stories of how things have gone for companies in adopting DevOps practices and strategies, Fryman writes. For instance, many organizations previously had ratios of admins to servers of roughly 1 to 25 – which made fast growth difficult, since it wasn’t feasible to recruit at the rate that enterprises were expanding. Now, with DevOps methods, that ratio is sometimes closer to 1 to 500.
- Giving monitoring some love: Operations folks vent about modern monitoring systems, or lack of same, via the #monitoringsucks hash tag on Twitter. But Fryman argues that more are shifting toward the #monitoringlove tag, “which is now directed at how to be more effective and mindful about utilizing monitoring in the stack.” Similarly, the #empathy tag is helping dev and ops types to be “able to experience and understand the others’ priorities in the delivery pipeline.”
- Automation and collaboration: New tools are allowing developers and operations folks to work closely as software goes through the process of being built, tested and rolled out. For instance, GitHub, a collaborative programming system with which Fryman has been associated, is using a tool called ChatOps to automate tasks like deployment, graphing, monitoring and even tweeting. ChatOps also allows developers and ops personnel to communicate while doing tasks like testing or deploying new features, according to Fryman.
- Spreading the word. Fryman suggests that many people in the IT field still don’t know what DevOps is all about. He writes that he gets calls from recruiters, interested clients and others who want to, say, “buy” DevOps or hire engineers specializing in the methodology. “This is all part of normal culture change, which takes time and energy,” he says.
Growing pains ahead?
It’s great to see DevOps expanding and taking hold. But the movement could face growing pains soon.
Clearly, DevOps is suffering from a lot of misunderstanding about what it is, and isn’t. I know the argument that its founders have: Defining it would limit what it could become.
The problem is that without a simple, clear definition, DevOps is becoming different things to different people. Consultants are springing up like spring flowers, all singing different tunes about what DevOps can do and, more importantly, how to put it in an IT organization.
This could inevitably lead to failed implementations, and in turn a possible eventual backlash when those misguided efforts become public.
For DevOps to avoid becoming just another management fad, somebody with authority has to take the bull by the horns and not only define it, but also lay out the steps that organizations need to take to make it a reality. Doing DevOps in a thousand different ways will only lead to failure.
And that would be disappointing –- especially when there is no reason for DevOps to falter.