Tech Insights

DevOps: A collaborative mindset for rapid and reliable app delivery

Why DevOps Mmtters

Faster time to market

In today’s world, software plays a key role in helping businesses learn what their customer need. Given all the complex relationships between distributed components in most enterprise applications, a mature DevOps practice can avoid miscommunication and delays, and make it simpler for teams to ship software. According to the 2016 State of DevOps Report, organizations practicing DevOps have (on average) 200x more frequent deployments and can handle 2555x shorter lead times (time between the intent to deploy code and the code being in production). Comcast is benefitting from this type of approach.

Comcast has seen a 50% improvement in developer velocity, a 90% reduction in technical debt, a 50% reduction in reported incidents, and reduced server farms by 75%.

Similar findings are showing up in other industry studies, as the chart below from Gartner shows, which lists even more benefits to shifting to a DevOps approach.

Question: Which of these outcomes has DevOps created for your organization?

Respondents: n=95 Gartner Research Circle members practicing DevOps

[Source: Gartner; Five Questions I&O Leaders Should Ask Before Funding a DevOps Initiative; October 2016]

Observed Outcomes With DevOps

Lower risk and smoother deployments

Coordinating and managing the development, deployment, scaling, securing, patching, and high availability of modern applications is hard, riddled with potential sources of failure. A DevOps practice is made up of a collaborative culture and automation for packaging, deployment, monitoring, and management of software. The result? Consistency and speed in pushing new code and updates to production. Coupled with continuous learning, DevOps teams can identify and eliminate roadblocks and establish a more robust, streamlined, repeatable, and mature release process that enables uneventful software deployments.

Faster recoveries

When code does break in production or cause downtime, a DevOps practice is well prepared to diagnose and recover from it. With significant automation and monitoring powering most of the release and management processes, a DevOps team can quickly collaborate to trace and determine the source of the failure, and rollback changes or issue fixes. In fact, the 2016 State of DevOps Report suggests that such quick and structured responses to unexpected production problems yield a 24x faster mean time to recovery in organizations practicing DevOps as well as a 3x lower change failure rate.

Higher customer satisfaction and better product-market fit

Releasing features or bug fixes rapidly and reliably not only leads to higher responsiveness and customer satisfaction, but also to rapid feedback and faster identification of the capabilities customers care about most. A DevOps practice lies at the heart of continuous delivery and fast cycle times. Without continual and tight collaboration between developers, IT operators, and business stakeholders, shipping useful functionality consistently, at a rapid pace, would be impossible.

DevOps versus traditional approaches

DevOps introduces a different mindset and new processes into software organizations. The following are some of the key differences that distinguish organizations practicing DevOps compared to more traditional approaches.

The Big Differences: DevOps Versus Traditional Approaches
DevOps Practices Are...
Traditional Approaches Are...
Collaboration oriented. Successful DevOps relies on the ability of software developers and IT Operations teams to collaborate closely in a successful and ongoing manner to ensure software is developed and delivered quickly and reliably. Silo driven. Traditional approaches rely on the “throw-over-the-wall” metaphor for collaboration, where IT Ops is charged with deploying and managing software in production with minimal assistance or insight from the team that developed it.
Structured and substantially (or wholly) automated. DevOps practices rely on automation to provide speed, consistency, and repeatability in environment provisioning and configuration such that what works in a development environment is guaranteed to work in a production environment. Structured approaches also make failure recovery faster as repeatable automation makes rollback and recovery easier. Snowflake driven and mostly manual. Traditional approaches rely on an ad-hoc combination of scripting and manual processes (with servers as unique as “snowflakes”) to provision and configure infrastructure. This makes it hard to get right, repeat reliably, or do quickly. Such approaches tend to encounter many problems that are rooted in the inability to quickly and consistently provision development and production infrastructure with configuration parity.
Self-service oriented. DevOps-driven organizations establish frameworks for collaboration and automation to empower developers and IT Ops to act independently without getting in each other’s way (e.g., developers can provision dev/test environments quickly through automated means without waiting for manual provisioning by IT Ops). “IT ticket” oriented. Traditional enterprise approaches require IT Ops to manage administrative overhead for IT tickets and perform repetitive, manual, complex provisioning and configuration that can easily be automated. This introduces significant complexity and delays in provisioning, deployment, scaling, and other software delivery and management activities.
Business focused. DevOps organizations are focused on jointly making the business successful. Therefore, they focus on taking joint responsibility for software delivery success. Function focused. Traditional approaches require the development and IT operations teams to focus on performing their function, with little connection or responsibility for the overall success. As a result, problems and failures lead to lots of finger pointing and organizational friction.
Designed for change. DevOps practices are designed to be automated, repeatable, and fast. They are built to handle rapid change as well as to recover quickly during a failure. They are built to go fast. Change averse. Traditional approaches try to avoid changing the production deployments, for fear of breaking it and not being able to recover quickly. They try to minimize changes and updates, and indirectly encourage the organization to go slow.