Johannesburg, 27 Feb 2020
If this were 2014, and Netflix went down for an hour, it would have lost $200 000. That figure is undoubtedly much larger today. But Netflix doesn't go down often today, at least not because of internal incompatibilities when it develops features and products; and it can thank DevOps for that.
DevOps is a very intimidating phrase. It smacks of technicality, akin to an obscure piece of military or engineering jargon. Yet this masks the fact that the concept provides a huge amount of value to the entire business. It prepares an organisation to embrace and manage change.
"DevOps enables a quicker way to respond to change, which is one of the biggest challenges businesses face today," says Muggie van Staden, CEO of Obsidian. "The days of 10-year plans are just not applicable anymore."
Ten years? Not even three years, he adds. The laborious demands of two- and three-year projects are now often overtaken by the realities of a high-speed world. It's prompting a rethink about how to create lasting results while still moving at speed. Again, DevOps is the answer, because it strikes at the hot core of deliverables.
When Operations meets Development
DevOps is a portmanteau of Developer and Operations. These are the two distinct technical arms within an organisation, and they rely heavily on each other. Operations require development to build the systems and processes it uses, while development without operations is just technology for the sake of technology: zero-value for the organisation.
They are symbiotic, yet the two traditionally operate with a wall between them, over which developers throw code for operations to catch and implement. This metaphor is popular among DevOps supporters because it acutely describes the nature of the problem DevOps sets out to solve.
There are several YouTube videos explaining DevOps. One of these deploys the concept of a robot. The developer creates a robot at the office, based on the spec required. He then ships it to the garden of an operations friend, but the robot turns out to be useless. The environment has changed too much for it. Had the robot been developed using a collaborative loop between development and operations, the deployment could have been successful. But that wall between them instead caused failure and delays.
In a company, the robot represents software, tailored by developers to serve the needs of operations. If problematic code is introduced into the production environment, it breaks things and results in downtime. This is particularly relevant and devastating since modern companies rely heavily on their underlying systems.
"At some point, people looked at this and realised they could do this better," explains Van Staden. "They can do this better by moving those two cultures and different ways of working closer together. And I think from there people have gone: 'Hang on. This is actually a good thing because it allows us to react and change a lot quicker.' "
DevOps beyond technology
DevOps focuses on technology and engineering environments because it is closely associated with software development. Yet DevOps as a culture offers a sweeping transformation to any organisation.
"Embracing change and creating understanding is the big challenge," says Van Staden. "It's about hearing the other side's challenges and understanding that what we do here affects that side. DevOps gets us to respond to change a lot quicker."
Van Staden is a proponent of CALMS, a DevOps model created by Jez Humble, co-author of The DevOps Handbook 'How to create world-class agility, reliability, and security in technology organizations', with Gene Kim, John Willis and Patrick Debois. This framework stands for Culture, Automation, Lean, Measurement, and Sharing. Understanding the five elements illuminates DevOps' broader impact.
Culture drives that notion of shared responsibility; that what one group does will affect another. Automation speaks to how DevOps aims to automate mundane and repeatable tasks, particularly for operations. Lean picks up the pace of delivery, focusing on shorter projects and output value. Measurement represents reporting capabilities and using those to inform all collaborators. Finally, Sharing underpins the culture of shared responsibility through metrics, automation, and ongoing communication.
All these elements are in play to bring operations and development closer together. But CALMS serves as a blueprint to build an organisation's ability to manage change. Van Staden points out that some even refer to DevOps as "standardised change".
"It's a way to change really quickly, but still in a governance-standardised way, so that you tick all the necessary business requirements that still exist," he says. "It doesn't change the fact that you still need governance, you still need security. Those things don't go away because you have moved towards DevOps. DevOps just forces you to rethink some of those things so that you can react to change a lot quicker."
The DevOps concept deserves more unpacking. How it can be deployed, and what are the nuances between Ops and Devs that make them so different? But don't disregard it as a technology trend or a matter left alone in the dark rooms of back-office activity. DevOps may be a primarily technical exercise, but its spirit reverberates across the company and its culture.
You shouldn't ignore DevOps, if only to avoid downtime. Recently, Amazon did go down for an hour, and that cost between $72 million and $99 million. Throwing code at the wall between development and operations can be costly. And not embracing change also has a cost. DevOps can help avoid both.
Share