Taking The DevOps Dive
The Gartner IT Glossary defines DevOps as “…a change in IT culture, focusing on rapid IT service delivery through the adoption of agile, lean practices in the context of a system-oriented approach. DevOps emphasizes people (and culture), and seeks to improve collaboration between operations and development teams. DevOps implementations utilize technology — especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspective”
Maturation of DevOps practices in an organization can have a significant positive impact to business continuity within the organization. One of the core DevOps practices is the concept of using automation to continuously test and integrate code in development and staging environments that are production-like. Successfully doing so can lead to a lower chance of business disruption, as well as the ability to recover from incidents more quickly when they do occur.
Deploying and Testing
Developing and testing code in environments that mirror production vastly reduces the number of bugs that are missed due to environmental variables. Continuously testing and integrating code in an automated fashion reduces the risk that bugs are passed into the production environment or that non-functional requirements, such as capacity constraints or security requirements, are missed during the development process. If these types of non-functional requirement gaps are uncovered by malicious hackers who exploit the vulnerabilities to bring down websites or steal sensitive data, the organization will face multiple business continuity issues. DevOps practices help proactively reduce the likelihood of these issues occurring.
A key outcome of implementing DevOps is the ability to release code at an incredibly high frequency. These small releases have two major advantages from a business continuity standpoint – First, when a release leads to a business disruption, it is much easier to determine the exact cause of the disruption, resulting in a faster mean time to resolution (MTTR.) Second, the length of the disruption that occurs during the release window is much smaller. This is particularly important for organizations that rely on extremely high systems availability. In these cases, it isn’t feasible to bring an ecosystem of applications down for five hours while a push to production is taking place. This approach to releasing code represents a step change in the risk that is associated with each release to production. Releases shift from events taking months of planning with the potential to make the front-page news, should something go wrong, to non-events that can take place during normal working hours.
Business Continuity Planning
Tightly coupled systems represent a major challenge for business continuity planning and response within many organizations. A change in a single component of a tightly coupled system generally demands changes to other components in the system, in addition to the need for comprehensive integrated testing to determine if the change has any negative effects. On the other hand, in a loosely coupled system, it is much easier to make changes in a single module, isolate the effects of the changes, and ensure the outputs of the module have not changed. If any changes result in issues once the change is live, it is very easy to roll back to a previous state and resolve the issue. Imagine a tightly coupled system as a factory that produces many widgets in which all of the operations for the single factory are tied together by common control systems, environmental systems, and labor force. Conversely, a loosely coupled system would be composed of multiple small factories that produce the same set of widgets, but may not be constrained by the common components. A fire in one of the small factories, doesn’t stop the output of the other factories. A change in process, or technology within a small factory doesn’t necessitate testing the new technology or process across all the other small factories. An enabling factor for the implementation of DevOps practices is the loose coupling of systems. The effort of adopting DevOps will naturally lead to improved business continuity outcomes because the architecture needed to support DevOps is an architecture that enables faster identification and resolution of the root causes of the disruptions.
“The effort of adopting DevOps will naturally lead to improved business continuity.”
Lastly, the underpinning culture of teams that successfully practice DevOps is one of collaboration and continuous improvement. This culture supports identifying potential risks to business operations due to system disruptions, mitigating those risks, and working cross-functionally to resolve issues when they do appear.
Ultimately, DevOps represents a significant shift in the way that enterprises organize, plan, and implement the work of IT groups. The road to successful DevOps implementations is challenging and often requires meaningful changes in the perceptions that people inside and outside IT hold about how to do their jobs. However, the business continuity benefits of moving to a truly DevOps-based mindset accrue across a number of potential sources of business interruption and are significant in nature.
By Evan Golly, Director of Enaxis Consulting