Channels ▼
RSS

Design

Other Voices: DevOps -- Why Now?


Jake Sorofman is chief marketing officer for rPath and can be contacted jsorofman@rpath.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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video