5 Questions and Answers about DevOps

Why Development and IT Operations? Because that is typically the value stream that is between the business (where requirements are defined) and the customer (where value is delivered). The origins of the DevOps movement are commonly placed around 2009, as the convergence of numerous adjacent and mutually reinforcing movements:

• The Velocity Conference movement, especially the seminal “10 Deploys A Day” presentation given by John Allspaw and Paul Hammond
• The “infrastructure as code” movement (Mark Burgess and Luke Kanies), the “Agile infrastructure” movement (Andrew Shafer) and the Agile system administration movement.
• The Lean Startup movement by Eric Ries
• The continuous integration and release movement by Jez Humble
• The widespread availability of cloud and PaaS (platform as a service) technologies (e.g., Amazon Web Services).

What is the difference between DevOps and Agile?

One tenet of the Agile development process is to deliver working software in smaller and more frequent increments, as opposed to the the “big bang” approach of the waterfall method. This is most evident in the Agile goal of having potentially shippable features at the end of each sprint (typically every two weeks). High deployment rates will often pile up in front of IT Operations for deployment.

Clyde Logue, founder of StreamStep, is attributed as saying “Agile was instrumental in Development regaining the trust in the business, but it unintentionally left IT Operations behind. DevOps is a way for the business to regain trust in the entire IT organization as a whole.” DevOps is especially complementary to the Agile software development process, as it extends and completes the continuous integration and release process by ensuring the code is production ready and providing value to the customer.

DevOps enables a far more continuous flow of work into IT Operations. When code is not promoted into production as it is developed (e.g., Development delivers code every two weeks, but is deployed only every two months), deployments will pile up in front of IT Operations, customers don’t get value, and the deployments often result in chaos and disruption. DevOps has an inherent cultural change component, as it modifies the the flow of work and local measurements of Development and IT Operations.

How does DevOps relate to ITIL?

Although many people view DevOps as backlash to ITIL (IT Infrastructure Library) or ITSM (IT Service Management), there are a number of different opinions in this field. ITIL and ITSM still are best codifications of the business processes that underpin IT Operations, and actually describe many of the capabilities needed into order for IT Operations to support a DevOps-style work stream.

Agile and continuous integration and release are the outputs of Development, which are the inputs into IT Operations. In order to accommodate the faster release cadence associated with DevOps, many areas of the ITIL processes require automation, specifically around the change, configuration and release processes.

The goal of DevOps is not just to increase the rate of change, but to successfully deploy features into production without causing chaos and disrupting other services, while quickly detecting and correcting incidents when they occur. This brings in the ITIL disciplines of service design, incident and problem management.

What is the Value of DevOps?

Most practitioners agree that there are three main drivers of DevOps:

1. Faster time to market (i.e., reduced cycle times and higher deploy rates). Companies who are able to adopt DevOps can typically do deployments four to five times faster than ‘traditional’ IT organisations. In today’s competitive market, there is little doubt that being able to deploy solutions quicker than everyone else will provide a competitive advantage.
2. Increased quality (i.e., increased availability, increased change success rate, fewer failures, etc.). If any mistakes are made during the development phase, they are frequently only discovered after testing testing in ‘live’ production environments. By deploying faster and quicker, mistakes don’t build up on each other, but are discovered quicker and can be dealt with instantaneously.
3. Increased organizational effectiveness (e.g., increased time spent on value adding activities vs. waste, increased amount of value being delivered to the customer). By aligning IT Operations into the same way of working and and the same culture as the development team, both teams in Development and Operations will obtain a shared purpose. Instead of the “We-versus-They” a shared identity is created, which greatly enhances the overall organizational effectiveness.

What about DevOps and Information Security?

High deployment rates typically associated with DevOps work streams will often put enormous pressure Information Security. Consider the case where Development is doing ten deploys per day, while information security requires a four month lead time to turn around application security reviews. At first glance, there appears to be a fundamental mismatch between the rate of code development and security code testing.

The good news for Information Security is that Development organisations capable of sustaining high deploy rates are likely using continual integration and release practices, which often goes hand in hand with a culture of requiring continuous testing. In other words, whenever code is checked in, automated tests are automatically run, and issues must be fixed right away, just as a developer checked in code that didn’t compile. By integrating functional, integration and information security testing into the daily operations of Development, defects are found and fixed more quickly than ever.

Learn more.