January 23, 2015
by Evan Powell
This post originally appeared January 22, 2015 on VentureBeat.
IT is undergoing its most important shift in at least 20 years, and devops is at the core of this transformation. Devops is moving to the enterprise, but barriers to adoption still remain. Enterprises should take these challenges into account when they are attempting to achieve the enhanced agility that top operators have obtained.
In this article, I discuss some of these under-appreciated barriers. In a subsequent article, I’ll dig into approaches I’ve seen effective in addresses these barriers.
Here are a few points worth raising that enterprises need to understand before assuming the path to devops will be an easy one:
1. The bleeding edge is more different than the “mainstream” has previously been
The playbook devops software projects and related companies are executing on — to learn from the Facebooks of the world and to sell to the banks and other enterprises — is not a new one. Many technology diffusion cycles since the time of the Homebrew Computer Club have followed this pattern. The difference now is that the new way of software development and operations (yes, devops), plus the great deal of cash available in the economy, has led to the mushroom-like growth of very important companies that have embraced radically different approaches to building and operating technology. These companies — including Facebook, Amazon, Google, GitHub, Uber, Stripe, Twilio, and Slack — are more different than the “mainstream” has previously been. How, you might ask?
2. The talent needed to go from agile development to devops operations is rare, and only unicorns possess it
One basic difference between the top operators and mainstream enterprises is that these top operators are able to attract some of the top devops engineers in the world. These companies know that being able to write and deploy software and other technologies much faster is important to their ability to compete. Filled with many of these practitioners, the operators can quickly build the systems they need to be able to move even faster. Devops is a new way of working and communicating as much as it is a set of tools, and the top practitioners are comfortable working in this new way. I know of a couple “too big to fail banks” with “infinite money” that have considered opening operations centers in the Bay Area. The motives: finding and holding onto this talent and gaining a devops culture infusion at the same time. Companies like Walmart have spent years and a significant amount of resources on this approach. And yet, when companies do open operations here, too often these outposts become jumping off points for their best IT engineers.
3. Legacy systems are often unable to be devops-friendly, and unicorns are blissfully unburdened by legacy systems
It was revolutionary several years ago, when my prior company, Nexenta, proved to certain large financial and government agencies (and other traditionally conservative buyers of storage hardware) that they could keep their data safe and serve it up quickly while running on white-box hardware. From that experience, I recognized the rise of software and the utter commoditization of hardware — a perspective that is rather common place now. Implicit in that perspective is the idea that new approaches to delivering IT systems are as good technically as the legacy approaches, but are more open, less expensive, and so forth. It wasn’t until recently that I realized how incomplete that picture is. Legacy systems are truly “legacy” — they are fundamental barriers to big enterprises adopting devops not only because they hoover up the IT budget, but also because legacy systems stand in the way, as they cannot easily fit into the devops approach. “Infrastructure as code” and being able to “change control” of every configuration in your environment is fundamental to devops. Legacy software and other systems were not written with these requirements in mind and often must be fundamentally rewritten to adapt.
Devops adoption by enterprises faces some real burdens — and I didn’t even rehash the important point that devops represents a cultural change as well. Whether it is the skills of their top IT engineers (“devops engineers”?) or the technical burdens they must maintain, enterprises must overcome hurdles to begin to approach the agility and productivity of top devops practitioners. Meanwhile, some of these top practitioners are starting to take the market away from the traditional enterprises. This is why software is eating everything and why IT definitely does matter today.
We are already hacking around with enterprises that are addressing both their skills shortages and the tremendous weight of their legacy systems. I don’t foresee a bank that will ever be as “cool” to today’s top engineers as a trendy mobile app, but the strengths of these older organizations can be harnessed to achieve devops like customer responsiveness despite the aforementioned challenges. And that’s what I’ll write about in my next article.