DevOps has kicked off a lot of discussion in IT management. Some love it, some hate it. But even that reaction is far too binary. The fact is that DevOps is not an all-or-nothing proposition. There is a measured approach you can take, emphasizing small experiments validated in short, low-risk bursts. Here, we’ll take a look at a few areas where DevOps can start making a difference for you relatively quickly.
First a disclaimer. We could get into a religious debate over whether moving toward DevOps can be called DevOps. Let’s put that to one side for this discussion. The idea I want to get across is that getting traditional IT departments to begin to work more in “DevOps style” is a benefit in and of itself.
Starting Along the Maturity Curve
DevOps was born from web ops, organizations that are all digital. For established IT organizations, to move toward DevOps, identifying the low-hanging fruit is the best place to start: focusing on problems that are not necessarily the easiest, but the most obvious to solve. If you can make incremental progress, like identifying the top ten things that cause failed changes or how to deploy the configuration file for an application so you can rebuild it instantly if anything goes wrong, you are on your way.
Changing the Culture
The typical IT department is composed of many smaller groups that are in charge of servers, networking, storage, databases and security. In a lot of organizations, they tend to behave more like competitors than collaborators, which can lead to turf wars and finger pointing.
The first big issue DevOps tries to solve is identifying the customer, and guess what? All these groups have the same customer: the business. Work together to confirm the business’ objectives and foster collaboration to support those objectives. Better communication is a hallmark of DevOps, and it’s one of the easier elements to implement. Want to reduce confusion and conflict? Get people talking. It sounds simple, but it can reduce finger pointing and increase accountability.
One easy first step toward breaking down silos is to cross-pollinate the teams: embed an operations person in the development group, and a developer in the ops team, for instance. At the next level up, create cross-functional teams focused on delivering a specific product or result. At the highest level, teams can be reorganized by application, business impact, or value stream.
Improving Tools and Automation
Automation has been fragmented and is at different stages of evolution in many IT organizations. Server automation is more mature than network or storage automation although I believe that in 2013 we will begin to see the software-defined mindset applied across historically fragmented portions of IT. Still, it’s quite ironic that these divisions should exist; network and server engineers have pretty much the same configuration management problems, but often don’t speak the same language.
Automation frees organizations to spend time innovating and grappling with new challenges. Automate known issues that cause pain in your organization first. Automate anything in your infrastructure that will reduce error rates, such as DNS, NTP, and firewalls. That will allow you to demonstrate that DevOps is worthwhile. Then, move up to an application or one of the environments—perhaps getting developers to build virtual machines using configuration management. At the latter stage of the automation maturity curve, you stop worrying about nodes and start worrying about availability of services. A node can be rebuilt; an application can be moved to another node. The degree to which you can automate failover and nodal performance is a sign of maturity.
If you don’t measure, you can’t improve. At the beginning of the growth curve, you can gain more insight into your applications and develop a common language to talk about constraints on application deployment and performance. The middle of the curve is instrumenting your applications and making that output available in a shared data environment, and the airplane-cockpit dashboard overview of your entire operation is the Holy Grail.
DevOps is not a fad for Internet companies. It’s a way of working that can make organizations more productive and employees happier (and it doesn’t look bad on a resume either). It’s easy to look at a traditional IT org chart and say DevOps isn’t for us. But if you look deeper, you’ll find that there are at least some ways you can move toward a more collaborative, productive, team-based way of working. Once you do a few of those experiments, DevOps fever is likely to spread across your organization.
A former IT executive in the banking industry and author of six technology books, James has been involved in IT operations for over twenty years and is an advocate of open source technology. He joined Puppet Labs in March 2010. James is the VP of Business Development and Client Services for Puppet Labs.