On the Future of IT, Part II: Saying Yes to DevOps
| DevOps |
How to Say Yes to DevOps?
Yesterday, I wrote about the idea that uncomfortable change often results in improved outcomes, and questioned whether we are looking at a moment of such change in the IT and security space as a result of the DevOps movement.
Today, I want to spend some time reflecting on this, and do so by considering a parallel trend I was witness to during my time at CloudLock (a great team, by the way, and leaders in helping companies secure end-user cloud applications like Google Apps and Salesforce). In a nutshell, the argument I am making is that DevOps is to modern IT as cloud was in the last technology cycle.
The Growth of Cloud – An Object Lesson
Seven years ago, Google launched Google Apps for businesses; it was the first time they made publicly available a set of tools (mail, calendaring, IM, and an early version of their office suite) that competed directly with the legacy tools that office workers had become used to — Outlook and Lotus, Office and its competitors, and so on. Over the course of the next few years, adoption of the tool, in part because it offered users an experience that was more collaborative and productive than was possible with the on-disk equivalents from Microsoft, IBM, Corel, and other older vendors.
There was a similar trend in sales automation and CRM tooling running in parallel, vis a vis Salesforce. While its roots are in the late 1990s, Salesforce released their developer platform in 2007, and since then their revenues grew to over $4b; largely purchased by sales management rather than IT, the platform has found its way into many companies infrastructures without having been procured through traditional channels.
What made both of these possible was the utility and efficiency that the products offered, coupled with direct adoption by their target communities. When they were engaged, IT and InfoSec reactions ranged from confusion to hostility, especially in the early days of these products’ growth. What has changed over the intervening 7 years is both the acceptance of the technologies (and the emergence of competitors, naturally), as well as the establishment of a market that provides those same IT and security professionals with the monitoring and security tools needed to meet both regulatory and organizational requirements around their use.
Nothing New Under The Sun
Flash forward to today. The DevOps movement, fueled by efforts of development and operations staff to make their workflows faster, their jobs easier, and their efficiency greater, is incredibly similar to what we saw with end-user adoption of cloud in the last decade. Tools like Puppet, Chef, and SaltStack are driving new infrastructure design and deployment; operations are segmenting out their environments via Docker and VMWare; development teams are building and testing software with Continuous Integration workflows via Jenkins, replacing SVN with GitHub, and otherwise choosing entire toolchains based on their needs rather than IT’s vendor management process.
What has not yet happened is the clear definition of the threat surface surrounding these decisions, or the subsequent creation of responses to ensure that organizations undergoing DevOps transformations are secure and safe. While understandable, closing this gap is critically important if DevOps is truly going to redefine the landscape for companies moving forwards.
Tomorrow, in the third and final part of this series, we’ll look at what the threat surface itself is and how to address it. I would love to hear from you as well – you drop me a line directly at [email protected].