In Defense of DevOps Teams
In Defense of DevOps Teams
Join the DZone community and get the full member experience.Join For Free
Discover how you can reduce your Kubernetes installation from 22 steps to 1.
It’s in vogue right now to claim that there’s no such thing as a DevOps team or warn about certain kinds of teams that brand themselves DevOps but are not. Jez Humble’s doing it. Patrick Debois has made similar noises in the past.
I still haven’t met anyone who claimed that were a “DevOps team” that wasn’t doing something awesome for their company. Most are build and release engineers trying to help smooth the interaction for Dev and Ops. Others are evangelizing the ideas. Others come from a release management background. All of them come to the problem with a perspective of optimizing the whole. That is just great.
That hasn’t changed since I wrote this last July:
I see what I would call the “DevOps Infrastructure Teams” pretty regularly and they are hugely beneficial. These are groups sorting out problems like performing rapid releasable builds, how do we spin up new instances of our standard web servers in minutes rather than weeks, etc and providing canned solutions to both developers and operations. Ideally, developers and testers use a capability like quickly instantiating a server from the private cloud to generate test environments and the operations team uses the same capacity to borrow extra capacity for managing peak loads.
We also see these infrastructure teams serving as DevOps evangelists in the enterprise and serving as mentors as additional teams take on a DevOps approach in general and specific techniques such as Continuous Delivery.
I believe we’ll see more of these teams in the next few years and more existing teams that perform these roles take on the DevOps name. For better or worse, they may be to DevOps what Scrum was to Agile – an avenue to enterprise adoption that purists find a little unpalatable.
I agree with Curtis Yanko’s recent linked-in post as well:
I fully understand that DevOps is a philosophy and not a title but… in older organizations trying to shake waterfall there needs to be a cross functional team championing the cause and demonstrating the value of partnering for success.
Exactly. In small Agile/Lean shops, any sort of dedicated DevOps infrastructure group is probably an anti-pattern. In the bigger, more established companies that are just adopting Agile now, a group that provides DevOps help as a service is a great thing and one that’s unlikely to be very temporary.
I’ll add the caveat that it shouldn’t be its own silo, but instead bring teams together in some way. This really shouldn’t need to be said. I’ve never actually seen a “DevOps team” that was creating new silos. Maybe they exist. So far, I don’t think they exist in big enough numbers to worry about.
If you can describe what your DevOps team does in terms that serve as a caption to the picture above, you’re probably doing something right. Don’t let the DevOps elite give you the impression otherwise.
Published at DZone with permission of Eric Minick , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.