by this trough of disillusionment. Once deployed, people find out that a) it’s hard and b) oddly, they are spending all this money on storage.

simon cRosBY: I agree with that. Solving storage is the hardest problem of all. It’s the big bear in the room.

From an infrastructural cost perspective, you have to consider the human cost: The number of administrators still grows linearly with the number of VMs (virtual machines). Server-con-solidation costs are very real. However, as virtualization addresses the mainstream production workload, costs are still going to be driven by the number of administrators. Unless the administrator problem is solved, IT has not re-

threaded has taken off at all.

tom BishoP: I think that is the elephant in the room. We as an industry haven’t built the correct abstraction which can fungibly apply computing to a domain and allow dynamic apportioning of computing capacity to the problems to be solved. Storage is a piece of it, but ultimately it’s more complex than just that.

If you take virtual memory as an example, we spent approximately 20 years trying to figure out the correct abstraction for memory. One can define memory consumption using one abstraction and build a set of automated mechanisms to dynamically allocate a much smaller physical resource

amount of demand, and I want to satisfy that demand with my capacity, using an affordable cost equation in a way that is moment-to-moment optimal for heterogeneous systems.

GustaV: The beauty of having a good
working abstraction of an underlying
function is that the operating system
can give you less than you asked for
and still provide acceptable results.
Virtual memory is a good example.
mache cReeGeR: So how does this ap-
ply to the poor guy who’s struggling
in a small to medium-size company?
What is he supposed to take away from
all this?

simon cRosBY: The single-server notion of virtualization—server con-

tom Bishop

ally been transformed.

GustaV: Fully using all the cores on the die is one of the biggest things that drive the need for virtualization. In the not-too-distant future we are going to be forced to buy eight-core CPUs. Because our computational problem has not grown as fast as the ability to throw CPU resources at it, we will not be able to keep all those cores fully utilized.

 

photoGraphs by Jason Gardner

It’s not an issue of power savings, as Intel will nicely power down the unused cores. The real benefit of multi-core CPUs is to be able to address the huge legacy of single-threaded processes in parallel.

simon cRosBY: I think that should be the high-order bit. There are 35 million servers out there, all of which are single threaded. So let’s just admit that, run one VM per core, and have a model that actually works. I don’t think multi-

simon crosby

 

to a much larger virtual demand and
still achieve optimal performance mo-
ment-to-moment. We have not found
that same abstraction for the core IT
mission of delivering application ser-
vices.
simon cRosBY: But isn’t determining
the biting constraint the fundamental
problem with any one of these things?
I don’t care about optimizing some-
thing that is not a biting constraint. It
may be memory, CPU, storage, and/or
power—I have no clue. Different points
of the operating spectrum might have
different views on what is or is not a
biting constraint. The grid guys, the
network guys—all have different views
and needs.

tom BishoP: I predict we will develop a workable abstraction for representing the basic IT mission: I’ve got a certain amount of capacity, a certain

steve herrod

 

solidation—is very well established and basically free. It will be part of every server, an emergent property of Moore’s Law, and multiple vendors will give it to you.

The orchestrated assignment of resources across the boundaries of multiple servers or even multiple different resources is a major problem and I don’t think we really have begun to understand it as yet.

tom BishoP: Regarding vendor lock-in, I think there is a body of experience, certainly in the companies I speak to, that says the heck with vendor lock-in. If my chance of getting a solution I can live with is better if I limit myself to a single vendor, I’m prepared to accept that trade-off.

GustaV: If you have a relatively small number of servers, there is no problem that you have that virtualization