everythingpossible - Fotolia

Resistance is futile when building DevOps teams

Few businesses are jumping into DevOps with both feet, despite the substantial benefit potential. The process of building a DevOps team structure starts with a much-needed conversation.

It goes without saying that established companies saddled with legacy technology and operational behavioral patterns are slow to change -- if they change at all. In time, though, the competitive ones that wish to survive become less resistant to ideas they once rejected, such as placing certain workloads in the public cloud.

Another shift on the horizon is the collapsing divide between developers and IT pros. By now, the term "DevOps" has reached mainstream, though the practice has not. Building, validating and deploying applications with lightning speed by uniting developers and IT pros brings about faster results and creates value to customers. And yet, plenty of IT pros resist. And staff reorgs are difficult because not all teams will jibe, IT teams said.

At the AWS Summit in New York earlier this month, I ran into several AWS architects who don't develop. Another team deals with development, they said.

Agile IT is all about speed, said Tim Prendergast, founder and CEO at Evident.io who also led DevOps teams at Adobe and Ticketmaster. Traditional IT projects run longer. An Oracle database might see an upgrade every 24 months. In a DevOps shop, you might move Oracle to MySQL to Postgres or MongoDB -- all within six months.

DevOps is like any grassroots effort. It starts with one person, but grows virally because there is value. You don't start DevOps teams by suggesting that they commence. Companies need to have internal meet-ups or create a group mailing list of like-minded IT pros, Prendergast recommended. Hold a hack-a-thon to demonstrate how continuous integration can be applied to putting an application in the cloud. Look for partners and allies along the way. Learn from their success.

And pick a project to show off DevOps' benefits. Sharing knowledge across internal groups will bring an uptick in people practicing this pattern. What follows is a dramatic drop in development time and delivery cycles. If companies looked at these high-velocity models for infrastructure and application development as competitive advantages, they'd take them more seriously than if viewed as something to do because it's cool.

In addition to a new mindset, companies need new tools. For example, tools that IT pros use today weren't built for an infrastructure that changes so rapidly. A network-based scanner might take hours to run across all of your devices. A VM in the cloud may not even live for an hour.

Today's security tools were built to protect a perimeter around a data center -- not to protect things like AWS Simple Storage Service or Relational Database Service, Prendergast said.

It's not easy to break down the walls between established IT teams. But DevOps teams with all domains of knowledge can make intelligent assertions as to why a problem might exist. An accelerated app/dev and deployment cycle delivers faster value to customers. And really, what choice do you have? If your competition is a startup that uses this model and is reaching your customers that much faster, your business is exposed to disruption.

Next Steps

Four ways DevOps can boost AWS security

AWS enables DevOps culture, cloud-native app design

Survive and thrive in cloud DevOps

Dig Deeper on DevOps Team Organization