This article is part of an Essential Guide, our editor-selected collection of our best articles, videos and other content on this topic. Explore more in this guide:
1. - What the DevOps movement is -- and is not: Read more in this section
Explore other sections in this guide:
DevOps is an exciting and far-reaching shift in IT delivery. The promises are tempting: radically higher productivity, lower cost and more reliable systems.
So I guess it's finally time for your IT organization to get on the development-operations (DevOps) bandwagon, right? Everybody's doing it, so don't delay. The big question isn't whether, but how and where do you start?
Warning: Misuse of DevOps may cause loss of career, temporary business interruption and uncomfortable meetings with your CEO.
First, go out and hire some DevOps people. Wait, wait -- DevOps isn't a job.
Okay, so you should create a DevOps group or department, right? A great team of people you can train up on DevOps led by a director of DevOps. Hold on! DevOps isn't a department or function either.
Well, if it isn't a role, a function or a department, what is DevOps?
DevOps is culture, process, technology and people. The DevOps strategy merges many disciplines into a cohesive set of organizing principles. DevOps is a new way of delivering IT systems that promises faster delivery, higher quality, an end to world hunger and eternal life. Okay, maybe not those last two. DevOps is also a huge investment of time, energy and resources for IT organizations.
DevOps -- the combination of application development and systems operations -- can transform and improve IT delivery. It is also so ripe for misapplication that I think there should be a warning label. Warning: Misuse of DevOps may cause loss of career, temporary business interruption and uncomfortable meetings with your CEO.
Why DevOps isn't easy
First, let's be clear about what DevOps isn't. DevOps is not Chef, Puppet or Salt Stack, or any other tool, scripting environment or technology. It's not automation, although the automation of everything is a core principle of DevOps.
DevOps also is not a replacement for the deeply technical and specialized skills in your organization. Eliminating the stovepipes of specialization does not mean firing all of your Linux or Oracle experts.
For a highly focused technology company like Yahoo, Facebook or Yammer -- all DevOps leaders -- achieving DevOps success is hard work. For traditional enterprises, especially large distributed organizations, DevOps success on a global basis is often unattainable.
Why is it so hard? Culture.
DevOps requires deep cultural and organizational change. That means changing behavior -- a lot. It means throwing out decades of embedded explicit and implicit practices. You have to tell the veterans accustomed to running things that much of what they know and do every day is obsolete.
Changing IT organizational structure is easy. I can put the developers and the operations people together in a room and tell them to get it done. But will those two different groups of people, with many years of different training and different experience, morph into a DevOps organization? They might as well be from different planets.
How to tackle DevOps
Reshaping your team for DevOps and applications agility requires courage and dedication at the executive level. It will also take time and money, and will require hard decisions about team members.
To make a DevOps strategy work, align incentives. If you reward developers only for their productivity in churning out code, and you give bonuses to operations teams only for their infrastructures' reliability, nothing will change. Instead, reward teams for system creation and operations and apply those rewards to all on the team.
Organize around business systems, not functional responsibilities. This is what breaking down the silos in IT means. A team should have developers to create the code from user interface to business logic and data structures, operations automation, deployment, and so on.
People need to know what systems they are responsible for and not just float from system to
system without accountability. The exception to this is the
Teams stay together on whatever applications and systems for which they're responsible.
Don't create a situation where one team supports too many applications. I know that's tough to contemplate in an era of shrinking budgets, but after this transition, your teams will be far more productive and can handle the increased demand without the need for additional staff.
You need plenty of specialist contributors to support the teams -- these are the gurus and experts on different disciplines. They are there to support, however, and are not permanently assigned to systems. They are not accountable to these systems.
Automate everything -- deployment, upgrades, scaling, maintenance, data hygiene, testing, monitoring, security and policy management. Invest heavily up front in automation. The goal is 100% automation, and don't think about deploying at less than 90%. Automation can beget automation sprawl. Central review and alignment will keep libraries of Chef or Puppet scripts from growing uncontrollably.
Incentives and recognition go to the whole team. A success is achieved by everybody. Similarly, a failure reflects on the whole team. System teams should recognize the contributions of specialists; implement incentives for providing outstanding support.
Develop new enterprise architecture standards around build-to-operate principles. This will align systems more to the needs of operations.
The DevOps strategy needs support from the top of the organization to the bottom. The entire executive leadership team -- not just the CIO -- should know why this is important and how to make it a success.
Allocate a lot of time for training and organizational development activities. Remember, this is major cultural and organizational change. If you try to move too quickly without all of your team being fully aligned, time-wasting missteps and conflicts can undermine the program.
About the author:
John Treadway leads the products and software business at Cloud Technology Partners, with an entrepreneurial background. He first encountered shared resource pools playing computer games on an IBM mainframe using teletype terminals, and became an expert on on-demand, elastic, metered and shared resource pools and provisioning via cloud computing. Treadway is based in the Boston area.