DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 84 posts at DZone. You can read more from them at their website. View Full User Profile

In Defense of DevOps Teams

  • submit to reddit

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.

This team should help bring developers and operations together.

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, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)