hours. They are still ahead on cost, giv-
en the alternative of having to purchase
the hardware outright and build it up to
support a peak load.
cReeGeR: So, the analogy would be to
analyze the cost of either purchasing
a car or taking taxis to meet personal
VoGeLs: Engineers are not well
trained to think about end-to-end cost.
MapReduce and other examples have
shown us that the end-to-end picture
of cost looks very different from what
you would normally expect. We have
to learn to think about the whole pack-
age—at storage, computation, and what
the application needs to do—and really
reason about what the axis of scale and
cost really is.
cReeGeR: I’d like to go around the
room once and give some final recommendations to the folks who are struggling to try to make sense of all this.
RAmLeTh: This is not a technology
game but a change-management game.
The goal is to get people to understand
that it is not dangerous to think this
way. We have three rules:
Think about what you can do that ˲
can benefit service delivery in aggregate; don’t focus on the small subcom-ponents that can lead to suboptimal
Don’t think about how you’re go- ˲
ing to distribute your costs before you
start any effort. Make sure that internal
charging mechanisms (allocations) are
not obstacles for change and progress.
Don’t think about and design fu- ˲
ture organization changes. Base decisions on organizational benefit and not
on increased power to you as a manager
or to your organization.
If you think about these three things,
it’s amazing what an organization can
BADRos: The beauty of what we’re
talking about is that it’s so easy to try.
You don’t need a big budget or approvals to get started. The fact that you can
do this so simply enables innovation
that would be unavailable if you needed to purchase a big piece of hardware
ahead of time.
TucKeR: As services move into the
Internet, they become easier and more
cost effective. This also means a shift in
power in IT away from those who control capital resources to the users and
developers who use self-service to pro-
vision their own applications. When
FedEx went online, people were taken
out of the support loop and custom-
ers could find their package status in-
formation themselves whenever it was
needed. You can now apply the same
principle to the provisioning of com-
puting resources. A developer can have
a server provisioned to run an applica-
tion without having to contact a hu-
man. That cuts the most costly aspect
of computing out of the equation.
oLsen: Cloud computing presents a
compelling opportunity for consumers
of information technology and produc-
ers of information services. Applica-
tion builders should take advantage of
existing functionality they can buy as
opposed to the past practice of build-
ing their own and focus their resources
on the unique capability they alone
can deliver. Consumers of information
technology have got to rethink where
they look for functionality. If they don’t
adapt their service delivery models,
then they will quickly become obsolete.
cReeGeR: Reducing cost and enabling
overall agility are what I believe you all
are trying to say. Cloud computing has
the potential for removing business
friction to make more services possible
and to do so much more easily, with less
risk and capital outlay. I think that is as
good a summary as any for something
as transformative as cloud computing.
Thank you all very much for your time,
talent, and wisdom.
For the complete version of this CTO
Roundtable discussion, visit
Describing the Elephant
Ian Foster and Steven Tuecke
Enterprise Software as Service
CTO Roundtable: Virtualization
Mache Creeger (moderator)
Mache Creeger ( email@example.com) is a technology
industry veteran based in silicon Valley. along with
being a columnist for ACM Queue, he is the principal
of emergent technology associates, marketing and
business development consultants to technology