There lingers the misperception that DevOps is mostly for companies that sport ping-pong tables and have free sushi for lunch. Trendy Web giants out on the technology bleeding edge. Firms that manufacture construction equipment and have large swaths of legacy computer code? Not so much, writes Gordon Haff, Technology Evangelist, Red Hat.
It’s really not surprising that this misperception exists. A traditional IT organisation glances at a company like Netflix and they may see a unique entity, a “unicorn,” wholly unlike themselves. They’re not even entirely wrong. More extreme implementations of approaches such as microservices or near-continuous production releases likely won’t become the universal norm—especially in the “classic IT” (aka Mode 1, to use the terminology of research firm Gartner) parts of their infrastructure. However, that doesn’t mean DevOps principles can’t also benefit the conservative IT of conservative firms.
It’s about the software
The first reason that DevOps practices apply outside of greenfield, cloud-native (aka Gartner’s Mode 2) IT is that the rules are changing. Venture capitalist Marc Andreesen’s “software is eating the world” meme has become something of a cliche but it’s no less true for that. As my Red Hat colleague James Labocki wrote recently, “Bank of America is not just a bank, they are a transaction processing company. Exxon Mobil, is not only an oil and gas company, they are a GIS company. With each passing day Walgreens business is more reliant on electronic health records.”
Furthermore, these shifts in technology and how business is transacted are creating new competitors that come at established firms from non-obvious directions and places. Barriers created by capital requirements, transaction costs, or even just brand become less relevant when a mobile app can change the landscape in a relative blink of an eye. (Think of all the new next-day or same-day approaches to delivery being trialed that could emerge as competition to the logistics incumbents.)
Therefore, while the priorities for classic IT may be different from those of cloud-native, business-as-usual needs to evolve. Even calling traditional IT “legacy” is a dangerous and misleading turn of phrase as it implies static and in need of wholesale replacement.
Rather, this “low speed” IT may prioritize stability over rapid change but it still needs to increase its relevance to new organizational initiatives and reduce complexity. To increase relevance, it needs to deliver environments for developers in minutes instead of days or weeks. To reduce complexity, it needs to implement policy-driven automation that reduces the need for manual (and error-prone) tasks.
Getting there requires a combination of policy-based hybrid cloud management and DevOps approaches.
DevOps thinking is proven to work in traditional industries
DevOps as we usually talk about it today is indeed rather new. It’s the child of pervasive open source, continuous integration technologies, platform-as-a-service (PaaS), software-defined infrastructures, and a host of other relatively modern technologies–which taken as a whole are quite recent. However, DevOps as a general approach has many analogs going back decades in manufacturing and other industries.
Consider some of the terminology associated with DevOps such as “automation of process” and “culture of collaboration.” These very much describe the transformation of the automobile industry to the modern age. Concepts such as kaizen (loosely, continuous improvement), just-in-time inventory, build-to-order manufacturing, and most of all the systems thinking embodied in the “Toyota Way” invite many parallels to DevOps.
Indeed standardised and reusable parts—which have similarities the small reusable services commonly associated with DevOps–date to the Système Gribeauval for cannons in 1765. For their part, the processes and machinery that Brunel and Maudlay applied to sailing blocks to standardise production at the beginning of the 19th century look a lot like the repeatable automatable workflows we associate with DevOps.
But cultural shift that emphasizes flexibility, cooperation, and transparency may be the most important similarity. When Jeffrey Liker wrote “The Toyota Way has been driven so deeply into the psyche of employees at all levels that it has morphed from a strategy into an important element of the company’s culture,” he was talking about an automobile manufacturer. DevOps likewise requires putting in place incentives, structure, and organization to create the right kind of culture.
Where should organisations use DevOps?
The lesson here is that DevOps is broadly relevant.
Oh, the details of how DevOps principles are applied will differ both between organizations and within a given organization just as the rigor of some manufacturing processes will depend on what is being built. Failing fast is fine as a general concept but the nature and bounds of acceptable failure need to be built into the overall process.
But there are universals and this brings us back to the fact that, while DevOps is largely built around innovative open source toolchains, it is at least as much about an approach and a culture as on specific tooling. A focus on continuous improvement. An ethos of sharing information and enabling experimentation. The creation of repeatable and automated processes wherever possible.
These apply whether stability or speed is the priority for the organisation in question. As a result, many analysts and other industry watchers expect DevOps to become widely used even in more traditional IT environments over the coming years.
Click below to share this article