(Author’s note: This blog entry is a slight rewrite of an article for Discover Performance where I was interviewed about DevOps.)
Agile and iterative development methods have promised greater business agility by letting developers create applications faster. But IT infrastructure and operations teams aren’t always able to deploy the changes / applications at the same speed. Thus, IT experiences the bottlenecks that occur when Agile’s need for speed clashes with operations’ need for stability. The result is non-agile Agile–a feedback loop with a huge delay in the middle.
The key is bringing both agile principles such as iterations and cross functional teams together with operations fundamentals automation, to the entire application lifecycleassessment, development, management and monitoring. Because DevOps includes a strategy and set of principles, backed up by tooling, for promoting collaboration between development and operations DevOps can help solve the problem of non-agile Agile by producing leaner, more responsive teams that ultimately deliver business value back to the customer. There are a number of factors to consider when bringing DevOps to the enterprise.
Upfront assessment: In a DevOps environment, you’re looking at new applications holistically, including assessing cost of the infrastructure you’ll deploy in the cloud or on-site. Additionally, you need to decide how you’ll manage releases: whether you’re going to adopt continuous delivery (in which the development team hands the application to operations to deploy) versus continuous deployment (in which development releases incremental changes to production without a formal hand-off to operations)—or both, or as we see in most teams a mixture (normally dependent on the time of change).
Application development: DevOps requires developers to take on additional responsibilities or simply different approaches in the development phase (with the help of their operations counterparts of course). Look to adopt practices such as continuous integration to catch flaws early and increase the level of automation in testing. Use production data to help in the application development and testing phases, and maybe even build monitoring and diagnostics into the application so that it is ready for deployment.
Ongoing maintenance and monitoring: With DevOps, traditional operations concerns about reliability and stability get raised earlier in the process. Victor Miller, senior manager of systems management at Blue Cross and Blue Shield of Florida, stresses the importance of moving monitoring further back into the application lifecycle. “The challenge there is reeducating people and making sure that they understand that they have to develop their app with monitoring in mind,” Miller said in an interview at HP Discover 2011.
Creating a successful DevOps environment requires widespread changes, which can be mapped to people, process and technology solutions.
People: You need open collaboration and education between your operations and development teams as well as a way for experts to share their knowledge. Two key DevOps best practices in terms of people and culture are:
- No finger-pointing
- Focus on mean time to recovery instead of mean time between failures
Process: Most of the customers I speak with are using some form of iterative development. Operations teams are often very focused on ITIL, which provides a set of rules around service delivery. The challenge is to take processes for continuous delivery and incorporate ITIL’s additional standards. Creating the Dev Ops version of “WaterScrumFall” (the combination of Agile and Waterfall processes). The two can exist together!
Technology: Development and operations use different tools. But there’s meaningful information in both, and DevOps creates the opportunity for cross-hybridization. For instance, developers may need to become more aware of configuration management systems, server automation systems and monitoring tools etc that are traditionally associated with operations. Especially valuable are social collaboration tools that help development and operations share information, collaborate and ultimately work more like a single unit.
KPIs for DevOps
DevOps encompasses key ITIL service delivery processes, such as configuration, change and release management. To monitor your progress on the path to DevOps, pay attention to these KPIs:
- Time to set up an environment
- Time from change request to release
- Number of deployments per week / month
- Mean time to resolution
Steve Katz, manager of Software Performance and Quality at Seagate, talked about his company’s experience with DevOps in an interview conducted at HP Discover 2011. For his organization, putting hard metrics around expectations for performance has been key. “That’s been a huge boon for us,” Katz said, “because it’s helped us script [requirements for performance] early in the project and actually look at the unit-level pieces, especially in each different iteration of the Agile process. We can break down the performance and do testing to make sure that we’ve optimized that piece of it to be as good as possible.”
The next phase: NoOps and the cloud
Just as DevOps is an outgrowth of Agile, NoOps is sometimes seen as the next phase of DevOps. NoOps doesn’t mean you’re getting rid of operations. With NoOps you’re automating the process of releasing the application into the dev /test environment or production.
I typically see customers who embark on the DevOps journey go through one of two paths they either think it through and progress rapidly to continuous delivery or the other path (especially in more traditional enterprises) is they follow a maturity model, starting with ad hoc manual provisioning that requires lots of back and forth between the Dev and Ops teams.
The next step is identifying repeatable processes and automating them. For example, when development checks in a build, the build manager can automatically communicate with the testing tool and kick off a series of regression tests. The same applies to provisioning test environments. With automation in a DevOps environment, a QA person can open a ticket, kicking off the multi-step provisioning process. As a result, the time it takes to set up the infrastructure to test a new application can go from weeks to minutes.
This is only the start of the journey, there is more to learn. However, what (we hope) we know is that long release cycles are a thing of the past. With most organizations using some form of Agile and iterative development, operations leaders can make their teams leaner and more responsive by embracing DevOps.
I’d like to hear your experiences with DevOps. Feel free to share them hear on the Executive CIO Forum.
For more information, read the white paper “Agile Development Meets IT Operations–In the Cloud,” (registration required). For more articles like this, join Discover performance for IT leaders
Paul Muller Blog: IT is like salad dressing, sometimes you need to shake it up