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
simon cRosBY: The single-server
notion of virtualization—server con-
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-
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-
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
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
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
GustaV: If you have a relatively small
number of servers, there is no problem that you have that virtualization