There’s little doubt the DevOps movement is picking up. Gartner says DevOps will be employed by 25% of Global 2000 organizations this year. And while more companies are seeking the competitive edge DevOps can deliver, the transition is not easy or painless. Theenterprise is packed with existing processes, organizations, systems and silos. It can be resistant to change.
Automation can bring speed and consistency, but maintaining visibility and control is a challenge. As we increase velocity, we have to ensure that quality standards are maintained. The ecosystem may be maturing, and there’s a huge diversity of tools, but there’s no clear blueprint for successful DevOps implementation. The Agile manifesto is a set of high-level statements, not a prescriptive set of actionable guidelines.
What can we learn from the successes and failures of others What are the main prerequisites for DevOps implementation in the enterprise Let’s take a look.
* A balancing act. Top-down engagement is important. We need the highest levels of the organization to sign off and understand the changes that need to be made. They can remove roadblocks, invest resources in the right places, provide support, and imbue authority. They can make DevOps a business priority, but they need to stop short of arbitrary enforcement.
The actual implementation must be bottom-up. Each team must be allowed to figure out which technologies are required, how the delivery process for their system will work, and what makes the most sense for them. There’s no one-size-fits-all blueprint -- you need to leverage each team’s expertise to build the best foundation. A balance of top-down and bottom-up will garner the best results.
* The right skills. Familiarity with automation in one or more of the following -- continuous integration, deployment, testing and quality, virtualization and cloud, provisioning, orchestration, or monitoring, coupled with coding fundamentals -- are key for this new way of handling operations. We need to maintain virtual data centers, virtual networking, and virtual servers. We need to look at efficient resource scheduling and cost models. This means dramatically changing or up-skilling parts of your organization, bringing coding skills into Operations, test automation skills to QA, and adopting a new, experimental mode of thinking for product management.
Everyone needs to build a better understanding of the business and customer. Switch to the idea of small releases for release management, safety through automation, and the ability to quickly cycle or revert for change management. Identify candidates with an appetite for it and make sure they get the training and support they need.
There is an enormous amount of domain knowledge about what it means to run infrastructure at scale that your operations team has and it’s essential to retain that, but they must also be armed with the most appropriate modern tools and the skills to use them.
* Measure the right things. We need to measure the right things and make those results visible. The best way to win over skeptics is to show results. You might want to look at the time it takes to go from concept-to-cash or commit-to-cash. You may decide it’s vital to measure how many production deployments or roll backs you’ve had in a specific time period, or how quickly developers were able to get feedback. Maybe you’ll measure MTTR, time spent providing audit data, or handover time during release. Many other metrics are possible -- the right things to measure will differ from organization to organization depending on your business goals.
This also helps create an open culture, which is a core concept of DevOps. As the data rolls in, you can see what’s working and what isn’t. There’s a lot of value in finding out why one project has successfully gone from one deployment per month to ten deployments per day, while another has stalled. Analyze, evaluate, and make changes.
Measurement also helps you to distinguish means from goals. DevOps isn’t about simply implementing a bunch of tooling, because tools are just implements to help you meet other goals. We need to continue to draw a distinction between what we’re trying to achieve and which processes, practices and tools we’re trying out to that end.
* Constant communication. What we’re really striving for with DevOps is collective responsibility. Developers shouldn’t be blindly implementing whatever has been assigned, they need to ask questions early if they know it will have a significant impact down the line, or if the feature simply won’t be usable. Likewise, testing and QA in a DevOps environment isn’t about finding bugs and passing it on, but about fixing defects, and collaborating to make sure issues actually get resolved. Business teams should be providing input and answering questions from day one.
The earlier everyone is communicating the better… and the lines of communications must be kept open. We need to find ways to break down the traditional walls between silos and enable productive communication and collaboration to take place. Teams should have visibility of the entire process of getting new features to production, so they can build a big picture view. It doesn’t happen by itself. We need to make sure that goals are shared.
While many of these aims are challenging and ambitious, a single step in the right direction can still be beneficial. The first stage of a move towards DevOps might be to focus on automation as a way of improving efficiency and reducing errors. A true culture shift will take longer, but as long as you keep measuring, every step of the way, you can be confident you’re headed in the right direction.
XebiaLabs is the leading provider of software for Continuous Delivery and DevOps. The author is a cloud, service delivery and automation expert and has been part of the shift to more automated application delivery platforms. He contributes to a number of open source projects including Apache jclouds, the leading cloud library, and is a co-organizer of the DynamicInfraDays container community events. He is also a frequent contributor to DevOps Magazine, DZone, InfoQ, CM Crossroads and SD Times.