A Transformation of Necessity: The Post-Recessionary Imperatives for IT
It’s interesting to watch the themes emerging from this year’s IT conferences—clearly, there’s a transformation underway and it’s happening fast.
That’s because it’s a transformation of necessity.
During today’s opening keynote address at Forrester’s IT Infrastructure and Operations Forum, automation analyst Glenn O’Donnell laid down the post-recession imperatives for enterprise IT. His point? Traumatic macro events forever transform the status quo. To wit: Last year’s Great Recession was the catalyst for the fundamental transformation in IT taking place today.
Glenn told what he called a “love story”—a love triangle, really—involving three people:
First, Ian: The IT ops director, beholden to traditional goals of stability and control.
Next, Eric: The business guy with fire, ambition and urgency to get it done, now.
It was a typical dysfunctional relationship between business lines and IT: conflicted and tenuous, if not outright hostile. But it wasn’t an issue of right or wrong; they just had very different goals and motivations. They were incompatible.
Then comes Yuri, the maverick developer—”the artist”—willing to bend rules and do what it takes to make it happen for Eric. Yuri was Eric’s answer.
Needless to say, Yuri and Eric did an end-run around Ian—in the interest of speed.
Incidentally, this same dynamic is why, according to cloud analyst James Staten, enterprise IT and application development report dramatically different rates of cloud adoption: 5% and 24%, respectively. Both figures are probably accurate. Dev is simply following the path of least resistance to satisfy the needs (and speed) of business.
This is all by way of saying that IT is being forced to change—to transform.
If you ask Glenn, he’ll tell you that three things need to happen for IT to transform:
• “Strategic Rightsourcing”—IT must get out from under the weight of commodity infrastructure and processes. If it isn’t core or differentiating, automate it or outsource it!
• “Industrialize Infrastructure and Operations”—”Fast and flawed and you fail. Prompt and precise and you prevail.” This poetic alliteration is Glenn’s way of saying that IT must deeply engineer and automate IT systems. You can’t effectively automate what isn’t controlled and consistent. (We couldn’t agree more!)
• Adopt Agile methods—extending these principles into the operational context, allowing development to move fast—and change—on behalf of business lines.
While there are several transformations taking place in IT today, the more you look at them, the more they look like one. Cloud, virtualization, lean IT, DevOps—they’re all converging on the same goals (speed, efficiency and cost control) and by the same means (removing the dev/ops bottleneck, consolidating, outsourcing and automating).
Forbes.com: Application Complexity Pushes Virtualization’s Limits
Dan Woods at Forbes.com wrote a great article today about Virtualization’s Limits.
His point? The complexity of applications will become the constraining factor to the overall value of virtualization and cloud. Today, how applications are deployed is ad hoc, trial and error—twiddle, fiddle, tweak, tune until it works.
Woods sees this as a nonstarter in the age of virtualization and cloud where “you must be able to set up an application environment to execute a workload automatically, the first time. No do overs.” He goes on to mention rPath as one of the companies addressing automated, conflict-free deployments.
What he stops short of exploring in depth—which is perhaps even thornier than the deployment issue—is how to enable conflict-free change in the same automated, hands-off way. How do you ensure that patches and updates don’t send worlds colliding when the impact of change—which is buried deeply in the complexity of the application—isn’t clearly understood?
As virtualization and cloud compound the number of systems that need to be provisioned, it’s both the initial set up and the ongoing maintenance that will swamp enterprise IT.
Cutting to the Chase: Cloud is an Application-centric Operational Model
Every once in a while someone says something that is so incisive and resonant that it captures the essence of a complex idea in a way that all the ramblings and gesticulations—interesting as they may be—simply never could. Thank you, James Urquhart for summing up in a few short words what so many treatises on cloud never could quite capture: “Cloud is an application-centric operational model.”
Yes!
I recently wrote on this very topic, envisioning the application-centric data center, which is where IT reorients from infrastructure to applications and business services. Our view is that this is the transformation underway. Also our view: This transformation can’t take place without deep transparency and control of software systems. You cannot abstract to applications and services without deep control of the entire system stack.
Why? Because software infrastructure never goes away—it’s still required to enable applications and business services. But, today, IT spends far too much time mucking around in the weeds to provision and maintain this infrastructure. rPath allows IT to focus on applications that include all the infrastructure they require to run across physical, virtual or cloud environments. Complete, self-contained and self-healing systems that are set free to run on any server, hypervisor or cloud.
rPath provides the control and consistency IT requires to make this shift from infrastructure- to application-centric operations.
IT Management 2.0: New Answers to New Questions
Today, most IT leaders have a relatively clear idea about what they must grow up to become—highly responsive, agile and lean service providers. Of course, they’ve known this for some time—only now, the transformation seems more imminent than ever.
It’s the combination of necessity and invention that has made this so: necessity, in the form of changing economics and market realities, and invention, in the form of new tools.
For most, the necessity part is clear as day—painfully so. But the tools? The tools remain cloudy—in many cases, literally.
In part, we have ourselves to blame for this rampant “cloud washing” that has swept across the vendor landscape over the last year or two. (Although, I’m quite proud of rPath’s discipline on this front. Certainly, cloud is an amplifier to our value, but we’ve consciously avoided being labeled “a cloud company” in the service of clarity and focus.)
Read more
Shared Content is the Glue that Binds Dev and Ops
Kris Buytaert, one of the voices behind the DevOps movement, wrote an interesting and timely post that suggests the fragmentation of operational roles puts pressure on the release process—and the dev/ops relationship in general. His point? Most IT organizations are made up of specialists responsible for specific layers of the stack—for example, OS, middleware, application—or specific crosscutting disciplines—for example, security, network, storage. The lack of coordination between these groups creates delay, cost and risk in the release process.
From our perspective, we see the definitive software library as the glue that binds these fragmented groups. Rather than building a system in isolation, everyone contributes to a unified and version-controlled repository. Each party draws from the correct set of bits and clearly documents dependencies, policies, configurations and metadata as the system moves through development, testing and into production. In a recent post, I compared this dynamic to the principles of knowledge management, where shared, authoritative content becomes the basis for effective collaboration between fragment and interdependent teams.
Our view? Shared content is the glue that binds dev and ops.
eWeek Feature on Intelligent System Automation
Last week, I wrote about the three factors converging to make DevOps one of the key movements of the day. Specifically: Lean mandates, the need for speed, and the tidal wave of system scale.
These same factors are the reason that new, more reliable approaches to system automation are under close examination by IT today.
To better understand what intelligent system automation is all about, see the slide show eWeek published on the topic. It’s a quick, bite-sized survey of what makes this new model-driven approach to automation different–and better–than script-based approaches of yore.
DevOps: Why now?
There’s tremendous passion surrounding this 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.
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.
And each of these pressures converges 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.
