The DevOps methodology may be gaining acceptance, but not every adopter finds success. Some tips from previous adopters can help newcomers make DevOps work.
Business leaders seek the promised efficiency and effectiveness of a well-oiled DevOps pipeline. To achieve that success requires a DevOps adoption roadmap. IT experts with DevOps experience say the methodology demands new thinking, leadership and a commitment to a DevOps strategy.
At SparkPost, a cloud email delivery service, a DevOps conversion several years ago helped change the direction of the company. The "traditional" development effort was troublesome, morale was low and errors were on the rise, said Chris McFadden, SparkPost's vice president of engineering. So his organization created a new cross-functional deployment team, which included hand-picked members from development and technical operations groups.
McFadden said the new team worked together to focus on tools and chose Bamboo and Ansible to automate the deployment of database, code and configuration changes. "Within a month, the team automated the nascent build-and-deployment pipelines for each service," McFadden said. After just three months, the team's incremental improvements reduced the upgrade cycle by 80% and reduced outages by a similar degree.
"Agile requires breaking down barriers between development and the product management and [quality assurance] organizations; DevOps similarly requires breaking down barriers, but this time between development and operations," he added.
And it's critical to get the DevOps strategy right. It's not just development and operations that need to work together. Business analysts, customers and management have roles to play. "Getting dev and ops to work together still leaves many other people that don't, and those people need to work together for any of this to be a success," IT consultant Wesley Higbee said. "If you simply speed up a process that produces garbage, you don't just get garbage in, garbage out. You get a landfill," he added.
Taking the right steps
To avoid that landfill problem, have a method and a plan. That's advice from Brian Schuster, an Amazon Web Services architect who works for VirtusaPolaris, an IT consulting firm. Schuster suggested several high-level steps that help organize a DevOps strategy:
- Define clearly what level of infrastructure access your organization will have and the standard process that is needed to move into production.
- Don't implement DevOps in the entire organization at once. Move in logical successions to test out the process (department, project, etc.).
- Have a defined process to monitor costs across the organization. Departments that may not have had a defined infrastructure budget will now create infrastructure and new expenses. These expenses need to be tracked and reported to managers.
That's a good starting point, but a range of practitioners provided several other ideas to keep in mind as a business moves from an embrace of DevOps to actual implementation.
Don't change for the sake of change. "Too often, companies feel they need to abandon everything that's worked for them in the past. Our starting point would be a review of the current workflow, software release cycles and server management. From here, we'd help lead a company to a strategy that addresses the most inefficient part of this process first. Oftentimes, that's the software release cycle." -- Jeremy Steinert, CTO at WSM International, a cloud-focused integrator.
Accountability. "Encourage accountability, and take pride in success at the individual team level. Monitor everything. Keep score. And hang out dirty laundry for all to see, continuously, at the individual delivery-unit levels." -- Gil Tene, CTO of Azul Systems, a provider of Java runtime solutions.
Agility vs. stability. "Too often, organizations focus more on agility and not enough on stability and reliability. DevOps has a lot of potential, but in order for it to work well, organizations need to take a measured approach. Operators, developers and testers need to have strong communication and shared goals. Be inclusive -- the traditional infrastructure team members have valuable knowledge which can be paired with developer know-how." -- Daniel Lakier, vice president of application delivery solutions at Radware, a cybersecurity firm.
Start small. "When you start a DevOps transition, start small because you will have to continually learn, adapt, iterate and grow. You can't just throw a magic switch and expect everyone to collectively be doing DevOps. First of all, how your company migrates to DevOps is going to be specific to your organization because not every company and culture is the same. I always recommend as a first step that IT professionals talk to as many people as possible in other organizations who have been through the transition. Then apply those learnings in a way that makes sense for your unique organization, culture and teams." -- Andrew Storms, vice president of security services at New Context, a company that builds secure systems.
Taking on tougher projects. "The biggest challenge in starting a DevOps strategy is how to keep improving after their initial success. Your first targets for a DevOps transition will be siloed applications that do not use customer data. Your next target will be your legacy applications, the same legacy applications that are so complicated and brittle that you may have been deploying them manually for years. At that point, you will arrive at the plateau of frustration." -- Robert Reeves, co-founder and CTO at Datical, a provider of Agile database automation solutions.
The people come first
"The biggest issue with DevOps is to remember that it's about people, not technology," noted Steve Suehring, an assistant professor of computing and new media technologies at the University of Wisconsin-Stevens Point. It's critical to create an environment where developers think like operations staff and where operations staff think like developers, he said.
"The primary pitfall that I've seen in DevOps transitions is getting caught up in shiny technology like dashboards and automation," Suehring said. "Organizations want a shortcut to DevOps, as if paying a consultant to tell them blue/green status and how to implement Hudson and Chef or Puppet will instantly make their problems go away."
But people are the key. An organization should require developers to take responsibility for their releases and require operations staff to attend developer meetings, "with project managers focused on dates over quality," he added.
And commitment to a DevOps strategy can pay off. The success of McFadden's company's early deployment team laid the groundwork for their future DevOps improvements and now "forms the backbone of our current system reliability engineering team," he added.