Ed Scannell’s recent SearchCIO.com piece on server provisioning is an insightful discussion on the failure of provisioning methods to keep pace in the age of cloud. His explanation of the problem is among the best on the subject, but his proposed solution comes with its own issues.
Quoted in the story, Dan Olds of Gabriel Consulting Group sets up the problem:
“[A lack of sophisticated provisioning tools] is a dirty little secret in the industry. Traditional provisioning done by hand—and even when it is done with scripts—takes too long. People are moving workloads across hundreds of servers at a time into the cloud and then back again. They need provisioning solutions that can be implemented faster and that can scale high enough to address Web 2.0-level problems.”
How software systems are constructed, deployed and maintained is undoubtedly a key chokepoint to large-scale and dynamic compute environments—and the key problem that rPath addresses.
Automation, the story argues, is the only way to counter compounding scale and the need to provision and scale systems on demand—without delay and without conflict. Credit is due for probing deeper and challenging the adequacy of script-based approaches to automation:
“Scripted provisioning is faster than the traditional approach and reduces technical and human costs, but it is not without drawbacks. First, it takes time to write a script that will shift an entire, sometimes complex workload seamlessly to the cloud. Second, scripts must be continually updated to accommodate the constant changes being made to dozens of host and targeted servers.”
IT administrator Jack Henderson agrees:
“Script-based provisioning can be a pretty good solution for smaller companies that have low data volumes, or where speed in moving workloads around is the most important thing. But in a company of our size, the sheer number of machines and workloads we need to bring up quickly makes scripts irrelevant in the cloud age.”
We beat this drum regularly, so it’s nice to see strong agreement on the subject.
Scannell proposes image-based provisioning as an alternative—a simple way to lay down software and to rapidly boot a machine. True enough. But golden images have their own issues:
“The problem … is that the golden image (a bootable image that represents the corporate standard for a particular system type) for one server might not transfer and work exactly the same on any other server, even servers with the identical hardware specifications of the host system.”
What Scannell doesn’t tackle is the fact that focusing on golden images only begs the question: What software goes on that image? How can you be sure it’s the right software? How do you accommodate divergent requirements without allowing the golden image to fracture into many different golden images? How do you keep track of where these images are being used? What has changed? Whether they’re up to date? How do avoid the very real issue of image sprawl?
The answer is a mature operational process for constructing images and keeping them consistent over time. With rPath, this doesn’t start with the image itself—it starts upstream, with the system definition: a blueprint that describes the all of the software, dependencies and policies that go on an image. This blueprint becomes the basis for managing the system over time. When updates and patches must be applied, simply make the change to the blueprint—and synchronize that change with the running system. The change can be made incrementally to a system that’s already deployed or a fresh image can be generated from the blueprint on demand. Easy.
Images themselves can be thrown away after a system is booted. They’re nothing more than a vehicle for rapid deployment. The idea is to create a repeatable process and supply chain instead of managing an inventory of finished goods. It’s idea with deep roots in modern manufacturing practices.
The reality is that managing images is only part of the problem.
The solution? The process for creating and maintaining these images in the first place.
