Dissecting DevOps

DevOps has become an industry catchphrase, but there’s substance behind the buzzword. Hint: it’s not just about automation tools. 

by Chris Belyea

I recently had an opportunity to speak at the local VMware User Group. The presentation was an introduction to DevOps concepts for an audience that’s focused on infrastructure engineering and operations. As I was preparing, it reminded me that underneath all of the buzzwords, the DevOps movement is about changing the traditional IT organizational structure in ways that ultimately improve service delivery to customers.

In many ways, server virtualization is one of the key technical developments that led to the DevOps movement. What used to take months of procurement and engineering could now be done in a few keystrokes (approvals notwithstanding). Virtualization is not new, but VMware made it mainstream in the modern data center. Virtualizing storage and networking completed the picture.

Turning infrastructure into software gives IT tremendous flexibility, but these advancements haven't resulted in any fundamental organizational changes to IT departments. The traditional silos still exist: compute, networking, storage, and database administration. Each group has its own specialized expertise, but hand-offs between teams are slow and too frequently error-prone. While each team is responsible for its domain, IT systems span multiple domains and failure sometimes leads to finger pointing instead of owning the problem. Even worse, each infrastructure silo is usually divided further between engineering and operations. Software development, of course, is a separate operation that’s often totally separate from IT. The end result is a culture of narrow focus and lack of ownership that brings the gears of innovation to a grinding halt. Customers ultimately suffer.

The immediate reaction from many IT departments is to implement a so-called “DevOps tool”—often a configuration management product such as Chef or Puppet. While these tools can improve operations, without the right operating model their full value will never be unlocked. No tool can smooth over organizational inefficiencies.

If existing team structures are an impediment, what does an ideal team structure look like? One solution is to have product-focused, cross-functional teams with the blend of skills necessary to operate effectively. Having developers and infrastructure engineers working side-by-side removes friction and ensures that developers and ops are focused on the same objective. Existing silos may not completely disappear (someone has to maintain the network, for example), but as more of the data center becomes virtualized and is supplanted by the cloud, there is less and less static, on-premise infrastructure to maintain.

DevOps is not a tool, and no software can optimize an org structure. But by changing the way technology teams work, they can deliver to customers faster. The right automation can help, but in the end it’s always about the people.

View the Dissecting DevOps presentation.

Learn more about our Cloud and DevOps solutions.

Chris Belyea
Chris Belyea
Senior Consultant
Contact Chris