For IT, Version Control Enables Change Management
Running IT operations would be easy if nothing ever changed. Set it up once, lock the door, and go surfing. Maybe once in a while you’ll replace a hard drive or power supply, but, on the whole, large systems will keep turning stable input into stable output.
Of course, there is no such thing as an unchanging environment. Applications change constantly, security vulnerabilities are discovered, hardware fails, load changes … the list is endless. All of this turns the role of IT ops into the role of change management. Some change has to happen (or some change has happened externally) and ops has to manage that change while keeping everything stable.
Three things are involved in change management: the old state, the change itself, and the new state. In order to truly understand what has changed and what is changing, you to need to track and control two of the three (since the third is the result of the other two).
Tracking the new state is clearly a good idea; you ought to know what your systems look like right now. Once you can describe the new state, you can capture the old state as well; just make sure you record it before you apply the change. As long as you have a place to record all of these states, you’ve captured change.
Now take all of those states, give each a version number, and toss them into a single repository. All of your historical systems are explicitly described, and the changes from one to another are implicitly described. You can inspect, query, and report on change in your operational environment. With just a touch of automatic provisioning, you can deploy changes from the repository into operational environment to get controlled migrations. If something goes wrong, you can undo those changes.
All of this depends on an ability to describe (model) what systems should look like. This type of modeling is fundamental to getting change under management.
But the state of the practice in IT today is far different than what I’ve described. What software deployments should look like is rarely defined at all. What is running and what is changing are equally opaque. And how do you bring a system into compliance or to reverse a change to bring it back to a previous state? These are things that are just plain hard to accomplish in IT today.
Of course, the problem only gets worse as scale compounds and change accelerates. I founded rPath to solve this problem–and to bring control to system management and change. In my view, it all starts with deep system modeling and a version control repository. Once that is in place, dealing with change–even at massive scale–is consistent, predictable and economical.
“Getting Lean” Means Just-in-Time System Images
You’re probably familiar with the concept of VM sprawl—the no-longer-hidden cost of virtualization and cloud computing—where the proliferation of system images threatens to wash out the savings promised by these technologies.
As the story goes, virtualization and cloud are an escape value for pent up IT demand, making compute capacity cheap and accessible. As Aristotle taught us, nature abhors a vacuum—when space is made available, it’s quickly filled in.
The result is a sea of system images. Since these images are typically created and modified by hand, image inventories are an unruly and unmanageable mess.
Storage vendors promise to solve the problem through automated de-duplication, which seems to have become the most common answer to the VM sprawl issue. Why? Because large storage vendors have invested heavily in getting us to see it that way. Storage vendors love VM sprawl because it drives storage spending, which is both the truth and perhaps EMC’s investment thesis for VMware.
But treating image sprawl as a storage problem is shortsighted. It addresses the symptom, rather than the underlying cause of the problem itself.
The underlying cause of the problem is the way images are produced in the first place. Today, they’re constructed and tweaked by hand without any mechanism for consistency or control. They’re handcrafted, one-of-a-kind artifacts. Snowflakes.
A better answer is automation—and the total elimination of image inventories!
Consider how automation has completely commoditized books in their physical form. Books were once treasured assets. Not necessarily the content, but the physical book itself. The cost of producing a book made this so. The printing process—even post-Guttenberg and his movable type—was painstaking and laborious.
Fast forward to present day and the book-as-physical-asset is a quaint anachronism. The content may be treasured, but the book itself is a commodity.
Why? Because automation allowed the focus to shift from the book—the thing you can drop on your foot—to the content itself. In this context, the author’s content is the pattern and the book is nothing more than cheap output.
Thanks to automation, this output is generated automatically and in any format. The content is fundamentally reproducible—consistently and automatically.
And that’s exactly what needs to take place in enterprise IT: Images should be generated on demand from patterns—cheaply, consistently and automatically.
Organizations must shift their focus from managing image inventories to managing system blueprints—version controlled patterns that provide detailed instructions for how the image should be constructed.
Need to deploy a system? Generate an image from a blueprint.
Need a slightly different image? Create a new version of the blueprint.
Done with an image? Throw it away! They’re cheap to reproduce.
There’s a strong precedent for this approach in modern manufacturing: Just-in-time production. One of the key tenets of lean manufacturing, just-in-time dramatically reduces inventory holding costs by shifting the focus from managing in-process and on-hand inventories to managing manifests, bills of material, and deeply automating the supply and demand chains.
Manufacturing has taught us that deep description and automation is a better alternative to managing inventories. As scale compounds and budgets contract, today’s IT organizations are wise to rethink VM sprawl—and to recognize that the solution is not in masking the symptom, but in addressing the cause itself.
Breakthrough insight is often about applying an old idea to a new context. For IT, this means looking to principles of manufacturing. In doing so, the idea of managing image inventories becomes nothing short of quaint and anachronistic.
Automation, Economics and the Birth of Market-Driven IT
Recently, I had a conversation with a well-known industry analyst—a very creative guy drawn to big ideas. He got me thinking about a big idea that has been rattling around in my brain to some degree of distraction. In my estimation, the idea is nothing short of transformational to the economics of enterprise computing.
It’s a story about taking back control of IT and truly rationalizing costs.
The story has two parts:
Part 1: Returning control and flexibility to IT by making system workloads autonomous, self-healing and portable across deployment environments.
rPath, for example, does this today.
Part 2: Allowing IT leadership to make dynamic decisions about where workloads should run based on optimizations for price and service levels.
Think of this as the logical evolution of IT financial management.
In combination, these two concepts have the potential to change everything.
IT has long been beholden to outsourced service providers for managing systems. In some cases, the comparative cost of outsourcing system management is lower due to scale economies and other built-in efficiencies. But, more often than not, it’s the predictability of a contract relationship that IT leadership covets: fixed bid contracts are easily forecast and service level agreements allow IT to share some risk.
But the cost of admission is exceptionally high—for a very large company a contract may exceed $40 or $50 million … a year.
Why have CIOs been willing to spend this much?
• Efficiency—traditionally, it has been more efficient to throw systems “over the wall” due to service providers’ comparative cost advantage through specialization.
• Switching costs—once your systems are deployed, it has been too expensive to move them to a new provider; you’re locked in—and so is your price.
• Liquidity—or the absence thereof. Traditional pricing models have forced enterprises to engage in onerous, long-term commitments, removing the liquidity that drives market-efficient pricing.
But this is changing—fast:
• Efficiency—emerging approaches to automation make system scale and complexity far less prohibitive and intimidating for enterprise IT organizations to handle in house.
• Switching costs—deep automation also allows you to regenerate systems that are ready to deploy to new environments, setting workloads free to run anywhere.
• Liquidity—At the same time, elastic computing models allow you to pay as you go. Systems can be moved and capacity can be consumed on demand.
IT efficiency increases, switching costs decrease, liquidity emerges, and a true market is born. Then, introduce decision support for driving price and SLA optimizations and CIOs can dramatically improve the efficiency of IT spending.
As context for what is possible, consider the achievements we’ve seen in modern manufacturing. Supply and capacity are dynamically shifted to the highest-yield demand. Capacity is allocated based on contract values, delivery commitments, and the on-hand availability of raw materials. Raw materials are procured based on competitive bids. Production runs are scheduled against available capacity.
The entire manufacturing process is automated and dynamically optimized.
Why shouldn’t this be the inspiration for the future of enterprise IT?
Next Up for rPath: Automation for .NET
Why is .NET such a hugely popular platform for in-house development? One reason is Microsoft’s optimization of .NET for the developer experience. .NET programmers have a broad, consistent platform at their fingertips and excellent integrated tools, including version control, team collaboration, and a single-click ability to deploy a fresh app directly into production.
But what about operations? Read more
