Jake Sorofman is chief marketing officer for rPath and can be contacted email@example.com.
There's tremendous passion surrounding the burgeoning DevOps movement, which aspires to address the longstanding bottleneck between development and operations. It's no surprise, because the cause is worthwhile: This bottleneck is the primary barrier to agility, responsiveness, and delivering business value.
DevOps is a reaction against the dysfunction in most enterprises today: Code is "thrown over the wall," and IT is left to figure out how to construct, provision and maintain resulting systems. Dependencies are poorly documented, systems often fall over at deployment, and change is avoided at all costs. In the meantime, deadlines are missed, lines of business wait, and blame is assigned:
IT operations: "The application folks handed me a poorly documented pile of goo that has dependencies beyond our supported OS and middleware platforms."
App dev: "The platform version we built this against supported all of our dependencies. IT never makes us aware of platform changes. It's their issue."
But more than a few have raised the question: How in the world is this new? It's a fair question; dev and ops have long been divided by conflicting cultures, goals, processes, and tools. And the motivation to bridge this gap is far from new. What is new is an organized movement to shine a light on the problem space and emerging solution patterns. A community is finally organizing around the issue.
But why now? Because the time is right -- for several reasons:
- Lean mandates. Last year's crushing recession forced us to do more with less. Automation became the necessary alternative to headcount. It also made us smarter and more efficient at scaling without adding people. This is one of the reasons that economists are predicting a "jobless recovery" in 2010. Automation remains necessary and very much in vogue.
- The need for speed. IT as competitive advantage is nothing new, but many companies are realizing that the velocity created by Agile hits a brick wall when it comes time to deploy an application -- which is when business value is realized. That's why agility needs to be extended into the operational context. At the same time, emerging self-service and elastic computing initiatives dictate the need for zero-latency provisioning -- automated, policy-driven and conflict-free.
- Crushing scale. IT is staring down a tidal wave of scale as systems transition from physical to virtual to cloud. What they're realizing is that these new architectures are a cap ex boon and an op ex bust -- every dime of ROI realized could be washed out by attendant growth in op ex costs as the management burden is shifted to these new architectures, which promise compounding growth in system volume.
The DevOps future depends on:
- A version-controlled software library which ensures all system artifacts are well defined, consistently shared, and up to date across the release lifecycle. Development and QA organizations draw from the same platform version, and production groups deploy the exact same version that has been certified by QA.
- Deeply modeled systems where a versioned system manifest describes all of the components, policies and dependencies related to a software system, making it simple to reproduce a system on demand or to introduce change without conflicts.
- Automation of manual tasks taking the manual effort out of processes like dependency discovery and resolution, system construction, provisioning, update and rollback. Automation -- not hoards of people -- becomes the basis for command and control of high-velocity, conflict-free and massive-scale system administration.
And all of these pressures converge on the gap between dev and ops. So, is the pain new? No, but it's more acute than ever and it's only getting worse.
That's why the time is right for DevOps.