Executive’s Guide To Cloud Computing

User Manual:

Open the PDF directly: View PDF PDF.
Page Count: 289 [warning: Documents this large are best viewed by clicking the View PDF Link!]

E1FFIRS 03/02/2010 12:49:45 Page 3
Executive’s Guide to
Cloud Computing
Eric A. Marks
Bob Lozano
John Wiley & Sons, Inc.
E1FFIRS 03/02/2010 12:49:45 Page 4
Copyright #2010 by Eric A. Marks and Roberto R. Lozano. All rights reserved.
Published by John Wiley & Sons, Inc., Hoboken, New Jersey.
Published simultaneously in Canada.
No part of this publication may be reproduced, stored in a retrieval system, or transmitted in
any form or by any means, electronic, mechanical, photocopying, recording, scanning, or
otherwise, except as permitted under Section 107 or 108 of the 1976 United States Copyright
Act, without either the prior written permission of the Publisher, or authorization through
payment of the appropriate per-copy fee to the Copyright Clearance Center, Inc., 222
Rosewood Drive, Danvers, MA 01923, (978) 750-8400, fax (978) 646-8600, or on the Web at
www.copyright.com. Requests to the Publisher for permission should be addressed to the
Permissions Department, John Wiley & Sons, Inc., 111 River Street, Hoboken, NJ 07030,
(201) 748-6011, fax (201) 748-6008, or online at www.wiley.com/go/permissions.
Limit of Liability/Disclaimer of Warranty: While the publisher and author have used their best
efforts in preparing this book, they make no representations or warranties with respect to the
accuracy or completeness of the contents of this book and specifically disclaim any implied
warranties of merchantability or fitness for a particular purpose. No warranty may be created or
extended by sales representatives or written sales materials. The advice and strategies
contained herein may not be suitable for your situation. You should consult with a professional
where appropriate. Neither the publisher nor author shall be liable for any loss of profit or any
other commercial damages, including but not limited to special, incidental, consequential, or
other damages.
For general information on our other products and services or for technical support, please
contact our Customer Care Department within the United States at (800) 762-2974, outside the
United States at (317) 572-3993 or fax (317) 572-4002.
Wiley also publishes its books in a variety of electronic formats. Some content that appears in
print may not be available in electronic books. For more information about Wiley products,
visit our web site at www.wiley.com.
Library of Congress Cataloging-in-Publication Data:
Marks, Eric A.
Executive’s guide to cloud computing / Eric A. Marks, Bob Lozano.
p. cm.
Includes bibliographical references and index.
ISBN 978-0-470-52172-4 (cloth)
1. Business enterprises—Computer networks—Management. 2. Information
technology—Management. 3. Cloud computing. I. Lozano, Bob, 1957- II. Title.
HD30.37.M36427 2010
004.3
0
6—dc22 2010002002
Printed in the United States of America
10987654321
E1FTOC 03/02/2010 12:56:9 Page 7
Contents
Preface xi
CHAPTER 1 THE SOUND OF INEVITABILITY 1
A Persistent Vision 5
A Little History 6
Three Ages of Computing 6
Broad Enablers 15
Big Contributions 20
Limitations 21
I Want One of Those 22
Back to the Future? 22
Notes 23
CHAPTER 2 CONCEPTS, TERMINOLOGY,
AND STANDARDS 25
Basic Concepts: The Big Stuff 27
Major Layers 34
Where They Live (Deployment Models) 36
Geographic Location 39
Datacenter Innovation 39
The Quest for Green 40
Standards 41
Much Sound and Fury . . . 42
Parting Thoughts 42
Notes 43
vii
E1FTOC 03/02/2010 12:56:9 Page 8
CHAPTER 3 CLOUD COMPUTING AND
EVERYTHING ELSE 45
The Neighborhood 45
Parting Thoughts 66
Notes 67
CHAPTER 4 STRATEGIC IMPLICATIONS OF CLOUD
COMPUTING 69
A Survey of Cloud Implications 70
Business Benefits of Cloud Computing 78
Cloud-Based Business Models 82
Cloud-Enabled Business Models 83
Strategic Implications of Cloud
Computing 86
Evolving from SOA into the Cloud 91
When to Do SOA versus Cloud? 98
Cloud Computing Adoption Obstacles 107
Parting Thoughts: Things to Do Tomorrow 109
Notes 110
CHAPTER 5 CLOUD ADOPTION
LIFECYCLE 111
Cloud Adoption Lifecycle and Cloud
Modeling Framework: Two Necessary
Tools for Cloud Success 112
Cloud Adoption Lifecycle 114
Cloud Adoption Lifecycle Summary 144
Parting Thoughts 145
CHAPTER 6 CLOUD ARCHITECTURE, MODELING,
AND DESIGN 147
Cloud Adoption Lifecycle Model:
Role of Cloud Modeling and Architecture 147
Cloud Industry Standards 149
Standards Monitoring Framework 154
A Cloud Computing Reference Model 155
Exploring the Cloud Computing Logical
Architecture 157
viii Contents
E1FTOC 03/02/2010 12:56:9 Page 9
Developing a Holistic Cloud Computing
Reference Model 162
Cloud Deployment Model 170
Cloud Governance and
Operations Model 174
Cloud Ecosystem Model (Supporting
the Cloud Reference Model) 179
Consumption of Cloud-Enabled and
Cloud Enablement Resources 184
Cloud Computing Reference
Model Summary 187
Cloud Computing Technical
Reference Architecture 188
Parting Thoughts 192
Notes 193
CHAPTER 7 WHERE TO BEGIN WITH
CLOUD COMPUTING 195
Cloud Adoption Lifecycle 195
Where to Begin with Cloud: Using the
Cloud Adoption Lifecycle 199
Where to Begin with Cloud: Deployment
Model Scenarios 200
Cloud Business Adoption Patterns 204
Where to Begin with Cloud: Consumers
and Internal Cloud Providers 209
Cloud Patterns Mapped to Common
Cloud Use Cases 213
Parting Thoughts 224
CHAPTER 8 ALL THINGS DATA 227
The Status Quo 228
Cracks in the Monolith 230
Cloud Scale 232
The Core Issues 234
Lessons Learned 237
Solutions and Technologies: A Few
Examples 239
Contents ix
E1FTOC 03/02/2010 12:56:9 Page 10
A Look Below: Need for Combined
Computation/Storage 242
Parting Thoughts 243
Notes 243
CHAPTER 9 WHY INEVITABILITY IS . . . INEVITABLE 245
Driving Scale 247
Objections and Concerns 248
Overwhelming Rationality 253
A Natural Evolution 257
Parting Thoughts 259
Notes 260
APPENDIX THE CLOUD COMPUTING
VENDOR LANDSCAPE 263
Infrastructure as a Service (IaaS) 264
Platforms as a Service (PaaS) 264
Software as a Service (SaaS) 265
Systems Integrators 265
Analysts and Services Providers 266
Parting Thoughts 266
Note 266
About the Authors 267
Index 269
x Contents
E1FPREF 03/02/2010 12:58:42 Page 11
Preface
What is cloud computing? Is this real, or simply another over-
wrought marketing phenomena, which the thoughtful person should
best simply let run its course? Suppose it is real—how important is
this, what does it mean to our organization, what should we do, and
how should we do it?
Thesequestionsandmoreareontheminds,orshouldbeon
the minds, of senior executives, leaders of many kinds and at many
levels, and clear-thinking leaders-in-the-making at a wide range of
organizations around the world.
As with any other area in which there is rapid innovation—and
cloud computing is certainly such an area—there are many compet-
ing voices with a wide range of views, which can seem to be little more
than a discordant cacophony. Fortunately, there are some valuable
lessons that have already been learned; fundamental technologies,
operational models, and business processes that have already been
developed; real possibilities that have already been seen; these
realities simply should not—no, must not—be ignored.
With all this in mind we set out to provide some basic under-
standing, clear guidance about the realities of cloud computing:
what it is, why it has happened, and what best to do about it.
The term cloud computing is of relatively recent vintage. In fact, it
was as recent as April 2008 when the nascent cloud community was
roiled by a short-lived U.S. trademark on the term itself. The trade-
mark was wisely abandoned quickly by the firm that had originally
obtained it, thereby giving name to something which the participants
all knew had become very real—not all at once, but gradually, in the
convergence of a number of technical, business, even cultural, and
sociological developments.
Yet those who had been working on some of the key technical
developments had known for some time–five years, in some cases
xi
E1FPREF 03/02/2010 12:58:42 Page 12
more–that there was something real here, something almost difficult
to comprehend in the disruptive potential on the business of com-
puting, something enormously exciting in the nearly breathtaking
potential impact on the organizations dependent upon, enabled by,
and all too often constrained by the then-present economics and
capabilities of traditional computing technologies.
These are indeed exciting times in the computing world—cloud
computing is, in fact, a real nexus, a moment when the endeavor of
utilizing computing fundamentally changes. We have been in the
thick of these developments since 2001, and through a fortuitous
confluence of events were brought together to write this book.
That is the need and our intent—what about the book itself?
In many ways this is really ‘‘books within a book,’’ and we believe
a wide range of people with a wide range of backgrounds and interests
will find it helpful.
The beginning of the book (Chapters 1 through 3) and the end
(Chapters 8 and 9) are of general interest: While some technical
perspective is inevitable, just skip whatever may be a bit too detailed.
Take care to understand the main points, particularly of Chapters 1,
2, and 9. Chapters 4 through 6 will be most helpful for the more
technology-savvy in a variety of roles, from strategic planner to IT
professional. Chapter 7 falls somewhere in between, and should be
read as your background suggests.
In any case, here are each of the chapters and a brief description:
Chapter 1, The Sound of Inevitability: This lays the historical
context of the broad trends and developments that have led
to cloud computing.
Chapter 2, Concepts, Terminology, and Standards: Names the
basics, establishes a common language for what is what.
Chapter 3, Cloud Computing and Everything Else: More context,
placing cloud computing in relation with everything from
virtualization to service-oriented architecture (SOA).
Chapter 4, Strategic Implications of Cloud Computing: Why exec-
utives should care.
Chapter 5, Cloud Adoption Lifecycle: An adoption model for the
enterprise, with special comments for the startup.
Chapter 6, Cloud Architecture, Modeling, and Design: Focus
on creating cloud-enabled applications that work equally well
xii Preface
E1FPREF 03/02/2010 12:58:42 Page 13
on both private or public clouds; interoperable private and
public clouds; and operational models that make use of the
potential elasticity, scalability, reliability, and cost reductions.
Chapter 7, Where to Begin with Cloud Computing: Practical
steps for planning, executing, and measuring incorporation
of cloud computing in a wide variety of organizations.
Chapter 8, All Things Data: Explores how the inexorable drive
toward ‘‘big data’’ is fundamentally changing nearly every-
thing about how data is stored, found, and manipulated.
Chapter 9, Why Inevitability Is . . . Inevitable: The fundamental
reasons why cloud computing is happening, will happen, and
consequently is well worth understanding.
In addition there is a brief Appendix that describes the basic
categories within the vendor community. Note that it is our intent to
maintain a directory of sorts on www.execsguidetocloud.com with
vendor descriptions, current cloud-related news, and so forth.
An effort like this does not happen without the help of many. To
our customers who have continuously asked ‘‘why?’’; our friends,
competitors, and erstwhile compatriots throughout the industry; our
friends and colleagues at both Appistry and AgilePath who are
turning these ideas into practical realities; our editors Sheck Cho
and Stacey Rivera and the rest of the team at Wiley; and of course to
our families whose contributions are both sublime and essential; to
all we acknowledge deep appreciation and offer our thanks for all
that you have done to support, challenge, and call us to do better.
It is our sincere hope that this volume will help you gain a deeper
understanding of what cloud computing is, why it is, and what
you may reasonably do to make good use of what is a truly historic
opportunity.
Bob Lozano Eric Marks
www.thoughtsoncomputing.com emarks@agile-path.com
www.execsguidetocloud.com www.execsguidetocloud.com
boblozano (twitter) ericmarks (twitter)
Preface xiii
E1C01 02/21/2010 Page 1
1
CHAPTER
The Sound of Inevitability
There have been very few fundamental changes in computing.
On the surface, that may sound like the statement of a madman,
or perhaps at least someone from an alternate universe. Nonethe-
less, it is true.
Sure there have been, are, and will likely continue to be a nearly
incomprehensible fire hose of particular changes, some rather fla-
shy in and of themselves. Simple things like pocket-sized flash drives
that store more than the corporate mainframes of 30 years ago, or
perhaps ubiquitous mobile devices for everything from the mun-
danely practical—e-mail, calendars, and contacts—to the cheerfully
sublime. Much more complex developments such as the open
source movement; the advent of relational databases; and the rise
(and fall) of whole operating systems and their surrounding ecosys-
tems, even those whose perpetual dominance once seemed assured
(how many desktop machines are running CP/M these days?).
These have come and gone, perhaps lingering in some niche, for-
gotten by all but a few fanatical devotees.
But truly fundamental change—the tectonic shift that literally
changes our landscape—happens only once in a long while, per-
haps every ten or more years, even in the computing business. Fun-
damental change of this magnitude requires a number of smaller
innovations to pile up until a true nexus is reached, and we all start
marching down a different road.
Of course, as historians are fond of lecturing the rest of us mere
mortals, these sort of fundamental changes are nearly impossible to
1
E1C01 02/21/2010 Page 2
recognizewhileweareinthemiddleofthem,evenastheyloom
imminently.
When researchers at the University of Pennsylvania were fever-
ishly working on ENIAC—generally recognized as the first program-
mable, general-purpose electronic computer—as the future of the
world hung in the balance in the midst of World War II, do you
think they envisioned computers embedded in nearly everything,
from greeting cards to automobiles, from microwaves to MRIs?
When researchers at the University of California, Los Angeles, and
elsewhere in the midst of the Cold War strove to make computer
networks more resilient in the face of nuclear attack,
1
do you think
any of them envisioned the Internet as we see it today? Likewise,
when Tim Berners-Lee and other researchers at CERN were trying
to come up with an easy way to create and display content over this
new, literally nuclear-grade network, do you think they envisioned
the impact on everyday life (both personal and professional) their
new creation would have, or even the simple breadth and depth of
stuff—from the sublime to the silly—that would be available on this
new, supercharged ‘‘Internet’’ ? One estimate is that there are more
than 500 exabytes—that’s 500 billion gigabytes—in this ‘‘digital uni-
verse,’’ and that this will double every 18 months.
2
The simple truth is that very few, if any, of the people involved in
these developments had much of an idea of the consequences of
their creations, of the impact on our personal lives, our culture,
even the society in which we live—from how we interact with our
families to how we conduct business.
Whether you are ‘‘technologically modest,’’ or are either by age
or temperament not ashamed to let it be known, at least in certain
circles, that you are a bit of a geek . . . either way, it is pretty much a
given that developments in computing are having a big impact on
our society, and more to the point, an even bigger impact on how
we conduct our business.
And bigger changes—tectonic shift–scale changes—will have at
least commensurate impact on our lives in every dimension, includ-
ing the fields of commerce. One example, perhaps a seemingly sim-
ple one, yet central to many of the changes now underway, will
suffice to illustrate this point.
Consider for a moment newspapers. We now face the very real
prospect—actually the near-certainty—of at least one (and probably
many) major metropolitan area in the United States without a
2 The Sound of Inevitability
E1C01 02/21/2010 Page 3
traditional (local, general purpose, print, widely circulated) newspa-
per. While this eventuality may be stayed—perhaps for quite some
time—via government intervention, the fact that this will eventually
occur is not in doubt. In a culture still echoing with such reporte-
resque icons as Clark Kent, or at least the more prosaic Bernstein and
Woodward, this was once unthinkable. Now it is simply inevitable.
There was a time when the technology of newspapers—cheap
newsprint (paper), high volume printing presses, delivery networks
including everything from trucks to kids on bicycles—was the only
reasonable means for mass distribution of information. In fact, with
help from some of the newer technologies there was even a new na-
tional newspaper (USA Today) founded in the United States as late
as 1982. But with the advent of alternative delivery channels—first
radio, then broadcast cable, and satellite television—increasing
amounts of pressure were put on the newspapers.
The immediacy of the newer channels led to the widespread
death of afternoon newspapers in most markets; anything delivered
to the dinner table in a physical paper was hopelessly out of date
with the evening news on television or radio. The morning papers
had the advantage of broad coverage collected while most people
slept, and as a result have held on longer.
However, at the same time intrinsic limitations of the newer
technologies made them better for certain types of information,
though not as useful for others. For example, a two-minute video
from a war zone could convey the brutal reality of combat far more
effectively than reams of newsprint, but did little to describe the
complex strategic elements—political, economic, cultural—of the
conflict itself. As a result, a certain stasis had been reached in which
newspapers carved out what appeared to be a sustainable role in the
delivery of news.
Then came the Internet.
In particular, the effectively free and ubiquitous—and yes, near-
instantaneous—delivery of all sorts of information mortally wounded
the newspaper business. As the first round of the web ecosystem
grew, the only remaining stronghold of the traditional newspapers—
their ad-based revenue model—was made largely irrelevant. eBay,
Craigslist, and freecycle (among others) replaced the classifieds, and
online ads took out most of what was left.
Some newspapers will undoubtedly manage the transition in
some manner or another, perhaps even emerging as something
The Sound of Inevitability 3
E1C01 02/21/2010 Page 4
fairly recognizable—particularly national/international properties
such as the Wall Street Journal and the previously mentioned USA
Today—and perhaps even financially sound.
But those that do will likely largely do so without their original
distribution technologies, and more important, many will not make
the transition at all.
Allofthisupheavalinnewsdelivery—theenormouschanges
that have already occurred and that which is yet to come—have
been enabled by developments in computing technologies, with the
widespread adoption of everything from the Internet to the iPhone.
It is probably worth remembering that all of this has occurred
largely without cloud computing, and as a result we are probably
less than 10% of the way through this transition in news delivery,
and this is only one industry. One industry, one example, with
entire economies yet to transform.
Even so, some things have not changed much, even in the deliv-
ery of news. The computing infrastructures range from the stodgy
(server, even mainframe-based systems within many newspapers) to
circa-2009 state of the art (which we might as well start referring to
as ‘‘legacy web,’’ web 2.0, old-school web, something like that). By
and large these systems still cost too much to acquire, do not adapt
to changes in demand nearly easily enough, are not reliable
enough, and remain way too complex and costly to operate. Even
the few systems that do not suffer from all of these problems are not
ideal, to say the least: Some are proprietary, and most are either too
complex to create new application software, or simply do not scale
well enough, at least for the sort of software that researchers are
hard at work developing. In particular, with the first generation of
electronic news infrastructures focused on just delivering the news,
the next generation will be focusedonsiftingthroughallofthat
content, looking for just the right stuff.
All of that sifting and sorting and searching will take orders of
magnitude more computing capacity than we have anywhere today.
How will we pay for hundreds and thousands, perhaps even tens
of thousands times more servers and storage than we have today—
almost unimaginable quantities of computing? How will we operate
them? Write new software for them? It is fair to wonder how we will
even power all that gear. Assuming that all of these concerns are
resolved, then, we will face a larger question still, one which we
4 The Sound of Inevitability
E1C01 02/21/2010 Page 5
presume has many answers: What sort of business models are
enabled by all of this, and how do we get there?
Before we leave this example, it is probably worth considering
our present circumstances just a bit more. In particular, most of the
history of both economics and engineering can be understood by
thinking about managing scarcity. In other words, how do I get the
most done with the least stuff, or within certain limits? For example,
that underlying drive to dealing with scarcity, at its core, drives the
startup team to work harder and pay less, the Fortune 500 enter-
prise to optimize manufacturing processes, and entire nations to set
energy policies. Allocating scarcity is just Economics 101. Of course,
it is also Engineering 101. Dealing with scarcity causes communica-
tions engineers to develop better video compression schemes, im-
prove CPU designs to get more done in the same amount of time,
and even rethink server packaging to reduce power consumption
and labor costs.
While scarcity may be the nemesis of some, it is quite literally a
prime mover behind the developments that have together come to
be known as cloud computing. What does this mean, and how can it
be possible?
A Persistent Vision
Better, faster, cheaper is often heard in technology circles. More
than a policy, more than a philosophy, this is literally a way of life
within technology communities. In an ideal world imagine that:
Computing—computation, storage, communication—is relatively free,
scales up or down as needed, scales as much as needed, operates itself, and
always works.
To one degree or another, this is the persistent vision that drives
many of those who are developing cloud computing. Is all of this
presently possible? Of course not; yet we are inexorably on this path.
Achieving this vision is, of course, a complex endeavor with far
more to it than may meet the eye at first glance. That is why there is
the rest of this book, for starters!
Before we go further let us elaborate a bit on the dimensions of
this vision.
Engineers and mathematicians talk about something being
‘‘within epsilon of zero.’’ This is a term that comes from calculus. It
A Persistent Vision 5
E1C01 02/21/2010 Page 6
simply means the process of approaching a particular limit, from
wherever you started to the limit itself. In the case of the cost of
computing infrastructure, that limit is zero. For most of computing
history the costs of infrastructure have dominated decisions about
what to deploy when: How much will those servers cost? How about
that storage farm? That network? Now, however, we can start think-
ing about those costs being ‘‘within epsilon of zero’’; that is, over
time the computing infrastructure comes closer and closer to being
free. That leaves other costs as the new, more significant considera-
tions—software licensing, data acquisition, for just two examples—
and this will be examined more closely later in the book.
A Little History
In one sense the evolution of computing has been one long blur,
with change piling on change, products that are ‘‘long in the tooth’’
in less than a year and virtually classic soon after, and with new
concepts—Moore’s Law, for example—created simply so that we
can describe, understand, and effectively institutionalize this relent-
less rate of change.
But there are times when these changes pile up in such number,
in particular combinations of new capabilities and logical conse-
quences, that the whole industry does head off in a new direction—
when the very conversations, the underlying concepts, even the pos-
sibilities themselves change.
To help understand the import of our current transition into a
computing world dominated by cloud computing, think a bit about
where we have been, where we are now (at least just slightly before
exactly right now), and both how and why we have travelled these
paths. While there are clearly many ways that the history of comput-
ing can be written, this one will only focus on the big changes—the
nexi
3
themselves—where the very possibilities change.
Three Ages of Computing
While there many ways to get a handle on the evolution of com-
puting, in order to gain an initial understanding just where cloud
computing fits, of just how significant and, yes, disruptive it is and
will be, it is sufficient to consider the broad sweep of computing
history.
6 The Sound of Inevitability
E1C01 02/21/2010 Page 7
First Age
Think about the role of computing within the typical organization
prior to the widespread adoption of the Internet. The focus was on
automating particular operations, creating supporting business pro-
cesses, and of course, always improving efficiency.
Notice that the focus was within individual organizations, by
and large. Yes there were purpose-built networks for interacting
between organizations, some of them even fairly large and impor-
tant (stock trading and manufacturer-specific EDI [electronic data
interchange] networks are two notable examples), and even for
certain organizations to interact with their customers (e.g., credit
card authorization networks), but each of these tended to have a
very specific, rather narrow focus. Even more important, these
examples were relatively few and far between, and very difficult to
achieve.
This was the first age of computing, in which organizations
looked internally for the big wins. For the most part the edges of
each organization remained the same as they had always been.
At the beginning of the first age the focus was on big infrastructure—
mainframes, big point-to-point networks, centralized databases, and
big batch jobs. Toward the end, terminals evolved into personal
computers, networks went from hierarchical (with the mainframes
at the center of each network) to decentralized, with a broader, gen-
erally more numerous collection of servers and storage scattered
throughout an organization. While batch work still existed, many
programs became interactive through this first age, eventually gain-
ing much more visual interfaces along the way.
Infrastructure tended to be associated with particular applica-
tions—a practice since pejoratively known as ‘‘application silos’’—
and important applications generally demanded enterprise-grade
(read: expensive) infrastructure—mainframes or big servers, and so
forth.
Application architectures tended to follow the same evolution-
ary path, with earlier applications being generally centralized, large
and heavy, while client-server and distributed application architec-
tures became mainstream toward the end.
This period also saw the rise of databases, along with the begin-
nings of specialized storage infrastructure upon which those data-
bases relied.
Three Ages of Computing 7
E1C01 02/21/2010 Page 8
Technologies such as parallel computing, artificial intelligence,
and even semantic processing remained exotic tools that were
employed in only the most demanding problems, where ‘‘cost was
no object’’ (at least in theory), where the goal was simply to solve
ever-bigger, ever-thornier problems—places like the nuclear weap-
ons laboratories, national intelligence agencies, scientific research
institutions, and the like.
Despite the rapid, consistent improvements in individual hard-
ware and software technologies throughout this period, the limita-
tions and complaints remained nearly constant. In particular, no
matter how much was poured into the IT budget, the foul nemesis
of ‘‘application backlog’’ was heard in the hallways of nearly every
enterprise. Who did not constantly complain about how much IT
was costing?
Still, it was at least (generally speaking) possible to automate
crucial operations within a company, and as a result overall corpo-
rate efficiency steadily increased. More autos were made with less
labor, more packages delivered with the same number of employ-
ees, higher revenues per store per employee, and so forth.
This period covered about four decades, from the roots of enter-
prise computing in the 1950s until the rise of the Internet in the
mid-1990s. As with all major shifts in a society, its culture and tech-
nology, the roots of the end of the first age of computing were sown
years before the second age began.
Second Age
The second age of computing is really the story of the rise of the
Internet—Sun, Cisco, Mosaic (which became Netscape), web 1.0,
eBay, Yahoo, baby.com, and the first Internet Bubble—all of it,
good and bad, all of the tumultuous commotion of the first Internet
land rush.
While many advances contributed to the beginning of the sec-
ond age, the two most crucial were the development of the Internet
itself, and the development and near-ubiquity of easy-to-use, visually
attractive devices that could be used by nearly everyone.
The story of the development of the Internet is well known
4
—
starting from a research question (Can we build a more resilient
network, one that can survive a nuclear attack?), to a more loosely
coupled set of higher level communications protocols (e.g., ftp for
8 The Sound of Inevitability
E1C01 02/21/2010 Page 9
file transfers, smtp for e-mail, http for web content) built on top of
this newly resilient foundation, then to a whole ecosystem of new
software. From browsers to web servers, among many others, the
Internet quickly went from ‘‘who cares?’’ to ‘‘must have!’’. By the
early 1990s this new, sort of crazy idea began to dominate even
mainstream business thought, to the point that normally sane, ratio-
nal people predicted such improbably outcomes as the elimination
of all brick-and-mortar stores, the irrelevance of a nation’s manufac-
turing base, and in some cases the irrelevance of nations themselves.
This in turn led to truly historic business hysteria: the Internet
Bubble. (Truth be told, if not for macro-level economic problems
that started in late 2008 the onset of cloud computing may have trig-
gered Internet Bubble 2.0.)
But as the dust settled and all calmed down, it was clear that the
world had shifted. Any enterprise intending to prosper now had to
consider how best to reach their customers and their ecosystem of
suppliers, and where to look for their newest competitors, all in the
face of the newest reality—ubiquitous connectivity.
Likewise, the ubiquity of visually rich devices—at first stationary,
then evolving to include the ‘‘handheld slabs of glass’’ (iPhone, an-
droid phones, Palm pre, and their successors) made it possible for
the non-geek to care. While command lines and text terminals were
enough for many of the early adopters, the simple reality is that au-
dience is, by definition, limited.
There were people—including one of the authors—who went
from cards, to command line, to modern bit-mapped displays (along
with a mouse, laser printer, and local area network, all part of the
experimental Alto workstations from Xerox PARC
5
), all well within
the span of a single year—1979. At the beginning of that year most
work was done on a mainframe via cards, printers, and batch jobs;
halfway through 1979 work moved to interactive command-line ac-
cess via dumb terminals; and by the end of the year you could sit in
front of a Xerox Altos, mesmerized by mice, bit-mapped displays,
and early networked games (Mazewars
6
being a great example).
While both of these trace their earliest roots—at least in forms
that we would largely recognize today—to the mid-1970s, they each
took 15 to 20 years to gestate sufficiently to have broad impact.
Overall, the biggest technical contribution of the second age
was perhaps the network itself. Forced to deal with the possibility of
massive network failures caused by a nuclear attack, researchers
Three Ages of Computing 9
E1C01 02/21/2010 Page 10
endowed their invention with the ability to self-organize, to seek
out alternate routes for traffic, to adapt to all sorts of unforeseen
circumstances.
In doing so (perhaps with only partial intent) these researchers
removed the single point of failure that was typical of mainframe-
inspired networks: and as a consequence in one fell swoop they
removed the biggest technological barrier to scaling–the mainframe-
centric network itself. Even more telling, foreshadowing changes
that would usher in the third age-when they enabled the networks
to take care of themselves-these researchers also removed the big-
gest obstacle to growth—they made these new networks much easier
to operate.
It is hard to overestimate the importance of two fundamental
realities: (1) with the Internet it was now true that everyone was con-
nected to everyone else, anytime, anywhere; and (2) with the ubiq-
uity of visually attractive devices, the data and services available over
that pervasive network could actually be used by mere mortals.
Typical technologies included the J2EE application servers
(often in clusters) along with relational databases, themselves often
in clusters. Developers and researchers everywhere strove to stretch,
push, pull, morph—everything but blowing them up and starting
over—to make these application architectures more flexible, scal-
able, more resilient to failure, and so forth, but were mostly un-
successful, or at least not successful enough.
There were plenty of innovations in software architectures, rang-
ing from improved data techniques to the first forays into what
became service-oriented architectures in the early part of the new
millennia.
Butwhathadnotchanged?Fartoomuchremainedasitalways
had, as things turned out. For starters, infrastructure remained
expensive, chunky, siloed, and by modern standards phenome-
nally overengineered (after all, the infrastructure really should not
fail), and consequently even more expensive. Great strides were
being made in distributed software architectures, but (outside of
the foundational TCP/IP networks themselves) most applications
and infrastructure software remained difficult to configure, com-
plex to create, and brittle when faced with failure. As a result, oper-
ations remained enormously difficult and therefore both costly
and error prone, which in the final analysis was the cruelest con-
stant reality of all.
10 The Sound of Inevitability
E1C01 02/21/2010 Page 11
Before we continue in this narrative, let us take a step back to
consider two more constants in computing—the drive for ever-in-
creasing scale and the drive for ever-lower expenditures (i.e., the
‘‘drive for cheap’’).
Drive for Scale Remember back to the middle of the first age, in
the 1970s and 1980s—most computing was done on relatively mun-
dane, large-scale individual computers, or perhaps in small clusters
of relatively big machines. Even then, for the researchers, scientists,
or perhaps intelligence agencies who were simply trying to solve the
biggest problems possible, this was never enough; for that matter,
nothing was ever enough, no matter how big and fast. Those folks
were the ones who were exploring the edges of parallel computing
and distributed architectures, who were thinking of highly pipe-
lined supercomputers and vector processors.
Yet in the mid-1980s another thread of investigation took root—
inspired by biological systems themselves—which started by combin-
ing large numbers of relatively slow computers, sometimes loosely
coupled via a local area network (these came to be often known as
grids) and sometimes linked internally via specialized connections
(such as the exotic Connection Machine 1, produced by Thinking
Machines, Inc., which was the effort to commercialize the doctoral
work of Daniel Hillis). In all cases these alternative architectures were
difficult to develop software for, cranky to operate, and enormously
expensive. Even though most of those efforts eventually evaporated,
they did at least make one very important contribution: They showed
that it was indeed possible, particularly for certain applications, to
build very large computing facilities out of very modest components.
This drive for scale went mainstream along with the Internet.
This was true in many dimensions, but for one easy example just
think of the indexing problem itself—whereas an early (circa 1994)
Yahoo index might have had less than a hundred, or at most a few
hundred entries, and could be manually created, by the beginning
of 1995 the number of web sites was doubling every 53 days
7
and
was passing anyone’s ability to manually index. This growth then
created the need for computing infrastructures that could scale at
the same rates or faster, as well as application and data storage archi-
tectures that could also scale apace.
Yet there was one fly in the ointment that occurred about this
same time—the silicon companies (Intel, competitors, and friends)
Three Ages of Computing 11
E1C01 02/21/2010 Page 12
began to reach their practical limit for scaling individual execution
units (which came to be known as ‘‘cores’’). In fact, this problem
had been looming for some time, but the processor designers
tended to solve the problem the way they had always done: Throw
more hardware at it and hope it would go away. In late 2004 Intel
announced that they were largely abandoning their push to increase
the ‘‘clock speed’’ of individual processing elements, and going for-
ward would instead be, increasing the number of individual process-
ing units (or cores). While, at least in theory, this drive for increased
core counts can deliver the same raw computing capacity, in prac-
tice it is much more difficult to write application software that can
make use of all of these cores.
This is, in essence, the ‘‘parallelization problem,’’ which in
many ways is the same no matter whether you are writing software
for multiple cores within a single piece of silicon, multiple cores on
multiple processors within a single computing system, or multiple
cores on multiple processors on multiple computing systems within
a single grid/cluster/fabric/cloud.
Sound complex? To be honest, it is—successfully writing a paral-
lelizable application can be enormously complex, difficult to do
well, even more difficult to do reliably, and more difficult still to
make it also easy to operate. In other words, the silicon and systems
designers had punted, shifting the burden for scaling to the applica-
tion software and operational communities.
Drive for Cheap Of course one drive that remains true in every age
and in every domain is the drive to reduce costs—cost to acquire,
cost to deploy, cost to operate, cost here, cost there, cost any-
where—just reduce them all.
In the midst of the rubble of the first Internet Bubble (burst-
ing), many different groups began to wonder just how to make use
of these increasingly capable commodity computers for problems
that we really cared about—mission-critical problems, the ones that
‘‘absolutely, positively, have to work.’’
8
For example, the roots of Appistry (a company founded by one
of the authors) lie in just such a question. When building a digital
recording studio out of purely commodity parts (no label, cheapest
fastest stuff that money could buy), after running benchmarks the
obvious question came up: Why are we not using cheap stuff like
12 The Sound of Inevitability
E1C01 02/21/2010 Page 13
this (meaning the plain label, pure commodity computing parts)
for problems that ‘‘we really care about’’?
The answers to that question—how to ensure that commodity
infrastructure could be ultimately reliable, easy to operate, easy to
bring software into and so on—led to multiple patents, products,
and companies, and is a question whose answers are definitely
worthwhile.
The economics of utilizing commodity components are compel-
ling, if—and only if—you can safely answer those key questions. The
economies of scale with commodity infrastructure, such as general-
purpose processors, are simply overwhelming when compared to
specialty designs. It is common for a collection of commodity com-
puters to deliver the same capacity for less than 10% of the cost—
sometimes far less than 10%—of enterprise-grade servers and
mainframes.
It is no longer a question of ‘‘is this possible,’’ but rather ‘‘how,
when, and where.’’
That same question—How can we use commodity infrastructure
for problems that we care about?—is being asked and answered in
various ways by forward-thinking technologists and executives every-
where in the relentless pursuit for ‘‘cheaper, faster, better,’’ and is
integral in the transitions to cloud.
Third Age
Now let us resume our narrative. Early in the second age Yahoo had
made a name for itself by ‘‘indexing the Internet,’’ which for some
time was mostly manually done. While this was sufficient for a while,
it soon became apparent that manually built indices could never
keep up with the growth of the Internet itself.
Several other indexing efforts began, including AltaVista, Google,
and others, but it was Google that brought everything together.
While a full understanding of why Google became so dominant–at
least as of this writing-is beyond the scope of this book, several key
factors can be easily understood.
First, the collection of data about the current state of the In-
ternet, and the processing of that data had to be as absolutely
automated as possible.
Three Ages of Computing 13
E1C01 02/21/2010 Page 14
In order to save as much money as possible, the infrastructure
would be constructed out of commodity components, out of
‘‘cheap stuff that breaks.’’
Data storage needed to be done in a simple, yet fairly reliable
manner to facilitate scaling (the Google File System, or GFS—
notice the lack of a traditional database, but more on that
later).
New types of application development architecture(s) would
be required, which came to include the so-called map-reduce
family (which inspired open source descendants such as
Hadoop) among others.
Operations needed to be as automatic and dependable as
possible.
Outages in the application were tolerable; after all this
was search, and who would miss a few results if an outage
occurred?
So almost before anyone really knew what was happening, in or-
der to scale a basic search facility and do so cheaply, Google had
created much of what we could probably first recognize as a cloud.
Another interesting case is Amazon. In the first six or seven
years Amazon largely built its computing infrastructure the tradi-
tional way, out of big, heavy servers, with traditional relational data-
bases scattered liberally throughout. That was fine in the early days,
and definitely fine during the first couple of years after the Internet
Bubble burst (particularly since much high-end hardware could be
had for pennies on the dollar after the first bubble), but as com-
merce on the Internet began to gain some real momentum it be-
came abundantly clear that the Amazon computing architecture(s)
had to change.
At the same time, in order to build customer and vendor sticki-
ness Amazon had begun exposing individual services, even select
customer data as callable services—one of the key application les-
sons that is leading to the third age—and so had accelerated decom-
posing many of their applications into dozens, or sometimes
hundreds, of individually callable services.
About that time (2001–2003) Amazon began to adopt many of
thesameprinciplesasGooglehaddoneearlyon,butthenthey
took things a step further. Instead of simply offering entire services
such as search, e-mail, maps, photo, and so forth with various
14 The Sound of Inevitability
E1C01 02/21/2010 Page 15
services exposed for calling from outside, in 2006 Amazon began to
offer basic computing resources: computing, storage, and network
bandwidth in highly flexible, easily provisioned, services, all of
which could be paid for ‘‘by the drink.’’
Others offered public cloud services that made certain unique
contributions, including Salesforce.com, which was probably the
first public cloud service that was targeted at the enterprise cus-
tomer and required those customers to store very sensitive data out-
side of their own facilities. While many thought that sale was not
doable, that no enterprise large or small would risk their customer
data on something so unproven, the allure of an easy, pay as you go
CRM (customer relationship management) implementation led to
the rise of Salesforce.com (and competitors, in the sincerest form
of flattery), emphatically proving otherwise, that the enterprise cus-
tomer could trust these services. That their initial rise to meaningful
market share and then eventual dominance came largely at the
expense of the traditional, install-in-your-own-shop application with
an overwrought, often painful, and unintentionally costly imple-
mentation was simply a bonus.
While each of these examples have their roots firmly in the mid-
dle of the second age, either their original or subsequent decisions
played crucial roles in bringing together the beginning of the third
age, the age of cloud computing.
It is during this era that that persistent vision that we discussed
earlier can finally begin to become true:
Computing—computation, storage, communication—is relatively free,
scales up or down as needed, scales as much as needed, operates itself, and
always works.
With that in mind, let us step back and take a look at some of the
particular developments that are enabling this persistent vision to
begin to become reality.
Broad Enablers
Over the course of the 1980s and 1990s there were key advances that
came together to enable the transition to the cloud computing
era—the third age. We are at the cusp of this transition as we com-
plete the first decade of the new millennium. While not a compre-
hensive list, these are some of the more notable enablers:
Broad Enablers 15
E1C01 02/21/2010 Page 16
Commodity Hardware. In the three basic areas of computing
components—chips (processors, memory, etc.), storage
(mostly disc drives), and network (both within a datacenter,
wide area, and wireless)—there have been large strides made
in the capabilities of what is by historical standards throw-away
equipment. For example, a client of one of the authors was
able to match a competitor’s industry-leading, mainframe-
based performance in processing high-volume customer trans-
action with less than a dozen cheap commodity boxes sitting
on a repurposed kitchen rack. Total bill? Less than $10,000.
Yes it works, and it works very well. The key, of course, was in
how the applications were constructed and how that set of ma-
chines is reliably managed. In any case, there will be more on
this example as well as others later in the book.
Network Speed. While network performance has not increased
at the same rate as either processor or storage performance
(which will lead to interesting problems as clouds develop—we
will cover the details of this in depth in Chapter 8, All Things
Data), huge strides have been made in both the connections
within a datacenter and those outside.
For example, by the time you are reading this a ‘‘gigE’’
network card (for use by a commodity computer within a data-
center) will be less than $10 each in small quantities. To put
that in perspective, that is about 400% faster than the internal bus
connections
9
(the key internal connectivity within server com-
puters) of the typical big servers of the early 1980s. Also as you
are reading this, a 10 Mbps wired connection for the home or
office will average less than $50 per month in the United
States, and even less than that in many parts of the world.
Mainstream mobile wireless (for those ubiquitous ‘‘slab of
glass’’ mobile devices that make accessing all these services so
pleasant) speeds will be closer to 7 Mbps, at the cost of only a
modest part of the typical monthly cell phone budget. The
point is simple: Whether within the datacenter, at fixed loca-
tions throughout the world, or on mobile devices, cheap, fast,
reliable, and ubiquitous network connections are a fact of life.
Virtualization. Virtualization started as a way to share the use
of very expensive mainframes among otherwise incompatible
operating systems, then flowered in the later similar trend to
consolidate large numbers of small servers (each typically
16 The Sound of Inevitability
E1C01 02/21/2010 Page 17
dedicated to one or two specific applications). It is the ability
to operate particular resources (such as computers, networks,
and so forth) largely independent of the physical infra-
structure upon which they are deployed. This can be a tremen-
dous boon for operations.
For example, the initial configuration of the operating sys-
tem for a server, along with the applications to run on that
server can take hours, if not days. With virtualization that ini-
tial work is done once and the results put on the shelf, to be
deployed onto physical hardware when needed. This process,
sometimes referred to as hydration, can be done in as little as a
few seconds to minutes and repeated as often as needed,
thereby enabling the possibility of easily deploying basic soft-
ware to large numbers of computers.
Application Architectures. Beginning with the development
of object-oriented languages and tools in the 1980s and 1990s,
and continuing on through the beginning of web services and
service-oriented architectures during this decade, software ar-
chitectures have made many strides toward the eternal goal of
software reusability, itself driven by the desire to make it easier
to construct software. A key characteristic of typical cloud ap-
plications has been the fine-grained components, with an ex-
posed application programming interface (API) or interface
(i.e., the ability to make use of that portion of an application
from nearly anywhere on the Internet—any place that makes
sense, and probably even a few places that are just for show!).
This ability to mix and match relatively independent soft-
ware services is crucial in making software more useful. For
many, this has been the practical realization of service-oriented
architectures (SOA), an interesting topic that we will explore
in more detail later the book. (A more detailed discussion of
the relationship between SOA and Cloud, and industry adop-
tion trends for both, is explored in detail in Chapter 5.)
In addition, there have been significant advances in creat-
ing more resilient, self-organizing application platforms that
are inherently at home on top of the very fluid, commoditized
infrastructure typical in cloud computing.
Finally, the need to become more adept at parallelization
in order to effectively use multi-core processors is beginning
to have an impact.
Broad Enablers 17
E1C01 02/21/2010 Page 18
Data Storage Architectures. The first two ages of computing
were very much dominated (for very good reasons) by the
database systems—relational databases such as Oracle,
MySQL, SQLServer, Postgress, and others. Entire (data man-
agement) organizations exist in most enterprises to manage
the structure of this relational data within these repositories;
with strict rules about how such data is accessed, updated, and
so forth. Unfortunately, what we have learned from abundant
experience is that at some point the block to scaling any given
application will nearly always be the relational database itself.
As a result the whole approach to reliably storing, process-
ing, and managing data at large scale is being rethought, re-
sulting in a number of innovative, novel technologies that
show significant promise.
Wearealsobeginningtoseesomesignificantimprove-
ments in the underlying storage infrastructure itself, both in
composition and operations. In any case, this whole area will
be explored in much more depth in Chapter 8, All Things
Data.
Pervasive High Quality Access. The reality—quality, variety,
quantity—of high quality, visually attractive, widely available
devices has had a tremendous impact on the development of
cloud computing. Typical devices include fixed desktops with
one or more flat panels; laptops and netbooks of every size,
price range, and performance; ubiquitous, sometimes special-
ized, and nearly always relatively inexpensive handheld devices
such as the iPhone and its growing range of competitors (such
as the rapidly-expanding rangeofdevicesrunningtheAn-
droid operating system from Google). Perhaps most impor-
tantly, these devices share in common a wide range of wireless
high-speed Internet access.
Taking all this into account, this plethora of high quality,
pervasive, always-connected devices has greatly increased the
number of customers for services and content—the data and
applications sold on the cloud—and has also increased each
customer’s appetite for even more services and data.
Consider one small example. In March 2008 Apple an-
nounced that they would create a marketplace from which
third-party developers could sell applications to owners of
an iPhone. Despite a tremendous amount of uncertainty—
18 The Sound of Inevitability
E1C01 02/21/2010 Page 19
including many who thought that the whole concept would
simply fizzle out for any of a number of reasons—within
the first nine months Apple was able to sell
10
more than one
billion individual applications; the second billion came in
about six months; the third in just over three months. From
zero to a billion in less than a year, then six months, then
three, then . . . well, regardless of what is next, that is a nearly
incomprehensible rate of growth, a reality worth pondering
for a moment.
Culture. We have become conditioned by the expectation
(quite often the reality as well) that everything is available all
the time—that Google and others will be able to tell you where
any place is, and that you can then reach your friends (no mat-
ter the time or place) to tell them about it. Perhaps all that
seems too obvious to think about much anymore, but take a
moment and ponder what this assumption, this daily reality,
has wrought on society. While an in-depth study of this phe-
nomenon is outside the scope of this book, it is such an impor-
tant factor that it must be considered.
After all, in some sense culture is a measure of how mem-
bers of a society interact with each other, and the transition to
the era of cloud computing is bringing incalculable changes
to this very arena.
That in our culture—for that matter, nearly any culture
around the world today—this means of communication is sim-
ply a given. The fact that we all take it for granted is a pro-
found enabler for future services, for future proliferation of
cloud-based services.
For example, consider that even such a venerable, ancient
institution as the Catholic Church has launched a number of
initiatives in the social media (including Facebook, Twitter,
YouTube, and more), and the present Pope has even encour-
aged young people to ‘‘evangelize the Gospel into these new
societies’’ and ‘‘into this new continent’’ (speaking of the
communities that are formed in the various social networks),
and that this is ‘‘a very high priority.’’
Ponder this carefully: If a 2,000-year-old institution that
has rarely been accused of haste can understand the funda-
mental nature of these changes and act on them, can any orga-
nization afford to do less?
Broad Enablers 19
E1C01 02/21/2010 Page 20
After all, this is what our cultures now expect; this is what people
demand; this is how people interact.
To recap, there have been several key factors that have enabled
the development of cloud computing at this time, in this place. Now
let us turn our attention to what some of these early clouds have
contributed to our understanding of cloud computing, of just what
is possible.
Big Contributions
Whilemostoftheseenablerscameaboutfordifferentreasons,it
has really been the combination of ‘‘all of the above’’ that enabled
cloud computing to get started. Once started, of course, the pace of
innovation began to increase significantly, and that increase in the
rate of change is itself continuing to increase—that whole ‘‘critical
mass’’ notion all over again.
For example, once actual clouds began to be deployed, utilized,
liked, and then as a result scaled up even more, then the early ideas
about cloud-optimal application architectures needed to be ad-
vanced even further. Likewise, the very need to scale has pushed the
innovative data models even further, which enables more scale.
Yet in addition to this self-fulfilling innovation there have been a
few, perhaps unexpected ‘‘bonus’’ advances. In particular:
Operational Models. In order to deal with the scale there has
been some significant development of novel operational mod-
els, with a degree of automation far beyond any prior.
Flexibility. From the beginning these infrastructures needed
to be able to scale up easily; then it became clear that they also
need to be able to scale down just as easily. This led to auto-
mated mechanisms for requesting more and releasing unused
infrastructure, and in some cases going further and simply al-
lowing policy-driven, automated scale changes with no human
intervention. These capabilities are wrapped in APIs and avail-
able via the web, of course.
Consistent Infrastructure. In order to facilitate the scale, flexi-
bility, and ease of operations most clouds have a relatively
small number of physical building blocks from which they are
constructed. Rather than the hundreds of unique servers,
20 The Sound of Inevitability
E1C01 02/21/2010 Page 21
versions of servers, and configurations of versions of servers
that populate the typical, pre-cloud datacenter, even the larg-
est cloud computing datacenter may have no more than a
handful, perhaps as few as three or four different possibilities.
Packaging and Construction. With consistency a given, the
next step is to consider more efficient, higher density packag-
ing and datacenter construction. Innovations in this area in-
clude everything from the very cheap—naked computer
motherboards mounted open air (no cases) on sheets of ply-
wood, all arranged in stacks and rows—to the more costly
(though highly engineered for space and cooling effi-
ciency)—stackable, semi-trailer sized containers stuffed full of
the actual computing infrastructure. There are now entire
datacenters designed to accept a number of these preconfig-
ured, stackable containers, with hardly a month or two passing
before someone presents yet a more efficient, even more radi-
cal, highly scalable modular datacenter.
All of these advances work with each other, in turn depending
on another and then enabling yet another. The interactions are fas-
cinating and useful, and will be explored in more detail in Chapter 2,
Concepts, Terminology, and Standards, and again in Chapter 8, All
Things Data, and Chapter 9, Why Inevitability Is . . . Inevitable.
Limitations
Of course, with all of the excitement there remain substantive limita-
tions. In particular, much of the early thought leadership (such as in
The Big Switch, a seminal cloud computing book by Nicholas Carr
11
),
orintheideascontainedin‘‘RedshiftComputing,’’asetofconcepts
put forth by Greg Papadopolous, then Chief Technology Officer of
Sun (prior to the acquisition of Sun by Oracle), who claimed that all
computing would eventually go into a small number of extremely
large public clouds. Papadopolous went so far as to initially predict
that eventually there will only be, in essence, five computers!
Upon calming down a bit and thinking through the implica-
tions a little more clearly, it began to become clear that while public
clouds of various types will play very important roles as the cloud
computing landscape develops, they will not work alone. Rather,
the public clouds will interoperate and work interchangeably
Limitations 21
E1C01 02/21/2010 Page 22
(where appropriate) with private clouds built and operated on the
same cloud computing principles. Some organizations will create
their own clouds for any of a number of reasons including control,
privacy, security, and reliability, among others, or perhaps do so for
data issues—data retention, reliability, and access to computing re-
sources (in order to enable even larger scales, better efficiencies, etc.).
The realization of these concerns with the early Utopian vision
of a small number of purely public clouds—and nothing else—is
leading to the development of a much richer, more textured cloud
computing landscape, with variationsthatcanaddresstheseand
other considerations as necessary, sharing common foundations yet
differing where necessary.
The best part? Each organization has a wide range of choices
from which to choose, with the ability to pick and choose as each
need dictates.
I Want One of Those
As a result of all this—the promise of reduced costs, easier scale,
greater flexibility, reduced deployment cycles and more, much
more—over the past couple of years it has become very common,
almost a litany, across many organizations to say in one form or
another, that ‘‘We want what Google and Amazon have, except that
we want it inside our organization, while at the same time interoper-
ating and in other ways working very closely with those very public
clouds, and we want to be able to use any of these clouds when
WE choose, as best suits OUR needs.’’
Back to the Future?
A few years ago a friend of ours was given a tour of a large, technol-
ogy-dependent Fortune 500 company that was trying to win her
business. She was taken to what was an extremely large (for those
days) datacenter, with row after row of large ‘‘excelsior class’’ main-
frames (a figure of speech for very large and costly stuff, but it
works, particularly here).
The salesperson, obviously proud of the datacenter pointed to
all of this ‘‘big iron’’ and went on and on about how they could
meet her needs, no matter what. They even were double-especially
proud of the empty floor space in the datacenter, with tape outlines
stretching as far as the eye could see marking the places where
22 The Sound of Inevitability
E1C01 02/21/2010 Page 23
future, planned excelsior-class mainframes would be delivered early
and often to handle growth.
‘‘See, we can handle any need you might have.’’
Our friend was, on the inside, simply appalled. Turns out that
she already had a taste of what cloud computing could be, so all she
could see as she looked out across that floor was an enormous
amount of fixed costs, with high operational costs at least partially
driven by the legions of highly skilled technicians hovering about
each precious mainframe, all these costs growing inexorably over
time with no end in sight, and very little ability to actually scale up
fast if her business did anything like what she was hoping.
Sensing her distraction, the salesperson reiterated that ‘‘they
could handle growth with this gargantuan facility, that this Fortune
500 organization was most definitely futureproof.’’
No, our still-polite friend thought, I am just not looking at the
future . . . this is a monument to the past.
It is just a matter of time.
Notes
1. Leiner, Cerf, et al., A Brief History of the Internet, last revised December 10,
2003; Internet Society: www.isoc.org/internet/history/brief.shtml
2. IDC Digital Universe White Paper, sponsored by EMC, May 2009.
3. Nexi is a slightly stylized plural of nexus—those crucial points where every-
thing converges and fundamental change occurs.
4. A good starting place to find more is the ‘‘Histories of the Internet’’ section of
the Internet Society site (www.isoc.org), where you will find several excellent
histories.
5. Xerox Palo Alto Research Center, research lab made famous by luminaries
such as Alan Kay and John Warnock (Adobe) as the home of such innovations
as the bit-mapped display, highly visual user interfaces for normal computing,
mice, local area networks, WISIWYG editing, Smalltalk, and more—all rou-
tinely used everyday now.
6. See A 30 Year Mazewar Retrospective at www.digibarn.com/collections/
games/xerox-maze-war/index.html.
7. Kill the 53 Day Meme, Jakob Nielsen’s Alertbox for September, 1995.
8. Inspired by and with apologies to that famous FedEx tagline ‘‘When it abso-
lutely, positively, has to be there . . . ’’
9. A Vax 11/780 had 1200 nanosecond memory, with a synchronous 32-bit bus.
10. Note that this number includes free as well as paid applications, some of which
are either ad-supported or involve generating revenue through some other
means.
11. Norton, 2008.
Notes 23
E1C02 02/21/2010 Page 25
2
CHAPTER
Concepts, Terminology,
and Standards
Some revel in the controversies, others decry the commotion as
so much wasted energy—but no matter what you think about the
seemingly endless discussions about what is and is not cloud com-
puting, what to call the constituent components, what terms may be
adopted from what has gone before, and what needs something
new . . . well, these discussions have served a very useful purpose.
In particular, this is how the industry has been coming to grips
with what is at its core fundamentally new terrain.
Still, some of us have had some fun with the whole thing. One
of our favorite contributions comes from Sam Charrington and
Noreen Barczweski, colleagues and frequent cloud computing pun-
dits, who captured the spirit of the debate in this (only somewhat)
tongue in cheek rhyme:
The Blind Men and the Cloud
It was six men of Info Tech
To learning much inclined,
Who went to see the Cloud
(Though all of them were blind),
That each by observation
Might satisfy his mind
The First approached the Cloud,
So sure that he was boasting
25
E1C02 02/21/2010 Page 26
‘‘I know exactly what this is . . .
This Cloud is simply Hosting.’’
The Second grasped within the Cloud,
Saying, ‘‘No it’s obvious to me,
This Cloud is grid computing . . .
Servers working together in harmony!’’
The Third, in need of an answer,
Cried, ‘‘Ho! I know its source of power
It’s a utility computing solution
Which charges by the hour.’’
The Fourth reached out to touch it,
It was there, but it was not
‘‘Virtualization,’’ said he.
‘‘That’s precisely what we’ve got!’’
The Fifth, so sure the rest were wrong
Declared ‘‘It’s you fools,
Applications with no installation
It’s breaking all the rules!’’
The Sixth (whose name was Benioff),
Felt the future he did know,
He made haste in boldly stating,
‘‘This ISWeb 3.0.’’
And so these men of Info Tech
Disputed loud and long,
Each in his own opinion
Exceeding stiff and strong,
Though each was partly in the right,
And all were partly wrong!
Sam Charrington & Noreen Barczweski
#2009, Appistry, Inc.
1
While poking and prodding a bit here and there, Sam and
Noreen were making a serious point—for many folks, what precisely
constitutes cloud computing depends on where they come from, and
what sort of concerns—primarily, but not exclusively technical—
occupy them.
26 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 27
Keeping that in mind, what we will do in this chapter is lay down
a few of the more significant cloud computing concepts—building
on the growing industry consensus, where it applies—and illustrate
the most essential characteristics.
Basic Concepts: The Big Stuff
For many their first exposure to cloud computing comes from using
a service from Google, Amazon, or the like, and so on first thought a
definition like this one
2
might seem sufficient:
cloud computing Cloud computing is on-demand access to vir-
tualized IT resources that are housed outside of your own data
center, shared by others, simple to use, paid for via subscrip-
tion, and accessed over the Web.
While this does reflect a common experience, in reality it is a
fairly limiting definition. For example, what about the requirement
that everything is provided ‘‘as a service over the Internet?’’
That might seem attractive at first, yet it does not allow for the
reality that there are many applications—for sound, unemotional,
pragmatic considerations—that will require a private deployment
(off the Internet).
In any case, let us keep thinking.
A team at the National Institute of Standards and Technology
(NIST) has been doing some very good work to bring some order to
these discussions. Here is their working definition:
3
Cloud computing is a model for enabling convenient, on-de-
mand network access to a shared pool of configurable comput-
ing resources (e.g., networks, servers, storage, applications, and
services) that can be rapidly provisioned and released with min-
imal management effort or service provider interaction. This
cloud model promotes availability and is composed of five
essential characteristics, three delivery models, and four deploy-
ment models.
This definition is more precise, definitely more technical, yet
still missing some of the practical realities that are crucial to the
Basic Concepts: The Big Stuff 27
E1C02 02/21/2010 Page 28
reality of cloud computing. For example, take a look at the largest,
most successful cloud deployments and (among many other things)
two more characteristics are immediately obvious: (1) almost every-
thing is built out of commodity stuff, and (2) there are only a few
basic building blocks (no matter what the scale).
To help bring about consensus in the industry, though, we have
generally followed the organizational structure of the NIST effort in
painting the picture.
A Definition
Therefore,
Cloud computing is a type of computing that provides simple,
on-demand access to pools of highly elastic computing re-
sources. These resources are provided as a service over a net-
work (often the Internet), and are now possible due to a series
of innovations across computing technologies, operations, and
business models. Cloud enables the consumers of the technol-
ogy to think of computing as effectively limitless, of minimal
cost, and reliable, as well as not be concerned about how it is
constructed, how it works, who operates it, or where it is located.
or even more succinctly:
Cloud computing is a style of computing where computing re-
sources and are easy to obtain and access, simple to use, cheap,
and just work.
It is this last definition that most clearly articulates what anyone
outside of computing really needs to know when trying to under-
stand what to make of cloud, and how it may impact their own oper-
ations. To gain perspective on these questions, simply compare and
contrast this view with the present state of affairs.
With these as working definitions, let us look deeper and define
the next layer of detail: the essential and nonessential characteris-
tics, the big chunks (architectural layers), and where all of this will
exist (deployment models). We will then examine the role of com-
modity, datacenter innovation, the ‘‘quest for green,’’ and a few
other interesting cloud concepts; then we will finish the chapter by
considering standards and the state of the industry consensus.
28 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 29
Essential Characteristics
Both in theory and in practice cloud computing has become rela-
tively consistent in a remarkably brief period of time. When looking
at clouds, we define these seven essential characteristics.
Scalable (Aggregate) While many characteristics come to mind
when discussing cloud, probably the first one to affix firmly in the
mind is the relative lack of concern about whether a facility can scale
to handle any particular demand—the implicit assumption is that it
can always scale as needed, at least to meet demand as a whole.
Note that the scalability of individual applications is not an abso-
lute requirement—there are clouds that consist of a large number
of relatively modest applications, and consequently still need to
scale in the aggregate. In fact, this is commonly the case in many
enterprises, certainly in the earlier stages of the adoption cycle.
Elastic One of the biggest criticisms of traditional information
technology (IT) infrastructures is how hard it is to scale resources—
either up or down—in the face of a change in demand for an appli-
cation. Both problems lead to over-allocation of resources—gener-
ally resulting in low utilization of total resources—in order to deal
with peak loads.
By way of reference, a conventional, non-virtualized datacenter
might typically run at 10% utilizations; with modest improvements it
could reach 18%; heavy conventional virtualization (often called
server consolidation) can result in increased utilizations to 25% or so;
aggressive application of the best in class techniques might get to
35%; while Google averages 38%
4
adoption of certain advances in
cloud application platforms (e.g., the Platform as a Service [PaaS]
gains the ability to instruct the infrastructure to power down when
not utilized, and so forth) that can lead to utilizations exceeding 90%.
In order to achieve these higher utilizations (greater than 50%),
it is crucial that the cloud be elastic—that is, it must be able to easily
scale up or down automatically, with no effort required by the oper-
ational personnel at time of need, and preferably minimal to no ef-
fort by the application developers in advance.
Note that in the best cases this level of flexibility is provided for
each and every bit of work done in the cloud—typically measured in
small fractions of a second.
Basic Concepts: The Big Stuff 29
E1C02 02/21/2010 Page 30
Self-Service Perhaps no other characteristic of cloud computing
has captured the imagination of anyone who has ever tried to de-
ploy a new software application sooner than anticipated, prepare
for a planned increase in demand, or cope with a sudden influx of
demand while using a traditional IT model than has self-service.
The process for adding capacity in the traditional model typi-
cally involves budgeting, acquisitions, facilities planning, staffing,
training, and more, with lead times often running into the months
or even years.
In contrast, a self-service capability enables the owner of an ap-
plication to obtain the necessary computing resources—or at least
the potential to use certain computing resources—with a simple re-
quest, no more than a few minutes before the need.
This type of capability is often implemented in web portals, and
stems from the capability that the first public clouds provided: Ac-
quiring infrastructure was no more difficult than ordering a book
from Amazon.
While closely related to elasticity, self-service differs in both
timeframe—minutes, hours, and evendaysversusfractionsofa
second—and intent—primarily about preparing for a range of capaci-
ties versus responding to the needs at any particular point in time.
Ubiquitous Access (Services and More) Another characteristic
essentially inherited as a byproduct of cloud’s ‘‘web heritage’’ is
that of ubiquitous access—all capabilities can be accessed from any-
where using any device (at least to the capabilities of that device)
or application.
Prior to the Internet, about the only universally accessible, tech-
nology-enabled service was the phone system, and that was so only
with difficulty.
With the advent of the Internet anywhere, any time, any device
access went from novelty to expectation seemingly overnight. Tradi-
tional systems were typically wrapped with a web wrapper to make
it accessible to either other software (also known as ‘‘service ori-
ented’’) or to a person. Mobile applications typically combined
both methods.
One interesting byproduct of ubiquitous, service-oriented/web
access to all applications has been the ability for almost anyone to
easily create new, ad-hoc applications—colloquially known as
30 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 31
‘‘mash-ups’’—that mix and match individual applications, data, and
services from anywhere, often in very unintended ways.
Long taken for granted in the web world, and long desired in
the enterprise,
5
the advent of cloud computing is making this a real-
ity inside and outside the enterprise.
Complete Virtualization: Acts as One Much of the history of com-
puting has involved discussion of infrastructure—servers, main-
frames, SANs (storage area networks), NAS (network attached-
storage), and so forth, as well as the software applications running
on top of the infrastructure.
Over the past 10 to 20 years a variety of forms of virtualization
have worked to decouple individual applications from particular
pieces of infrastructure. This has been most successful with proces-
sors, less so with networks and storage, and least of all with
applications.
What has been achieved has had significant impact—simplifying
operations (at least initially) and increasing flexibility, availability,
and utilization.
Eventually widespread adoption of virtualization actually com-
plicated operations immensely—this is the so-called ‘‘vm (virtual
machine) sprawl’’ problem that can be the bane of many IT opera-
tions groups—so something more was needed.
That something more is found in some of the more advanced
cloud technology stacks, namely the ability for the infrastructure
components to act like one, both for the operational groups and
the software developers.
In other words, no matter how large a particular cloud has to
scale, it remains as simple to operate and as easy to develop applica-
tions for as if it were only a single server.
This is what we mean by complete virtualization.
Note that in combination with ubiquitous access, this can lead
to a real sense of location flexibility.
6
Relative Consistency As a practical matter, mostly due to opera-
tional complexity, even the earliest clouds have been built out of
a relatively small number of unique components. Even relatively
advanced IT operations that rely on conventional virtualization
may have hundreds and even thousands of unique infrastructure
Basic Concepts: The Big Stuff 31
E1C02 02/21/2010 Page 32
building blocks (i.e., the servers, operating systems, storage, net-
work components etc.) that must be deployable, and will be found
somewhere in that datacenter.
In contrast, the same capacity can easily be provided with a
handful of unique building blocks—perhaps two or three server
types, one or two network switches, and so forth.
This leads to greatly increased economies of scale, simplified op-
erations, and typically significantly reduced costs.
It is the computing equivalent of the well-known Southwest Air-
line decision to standardize on a single plane in its fleet and struc-
ture its entire operations around that decision. While a radical
departure from conventional thinking, that decision was key to
much of Southwest’s success for many years.
7
In any case, the decision to build a cloud out of a relatively small
number of standardized building blocks has even more advantages
here than it did for an airline, and even fewer limitations.
Commodity While there are those who argue that a cloud can be
composed of any type of infrastructure, from commodity to main-
frames (and in a certain, less complete, and much less effective
sense they are correct), most purpose-built clouds are constructed
from what are traditionally thought of as commodity components,at
least relatively speaking.
The economics are simply too compelling—because of econo-
mies of scale in manufacturing, the cost for each unit of capacity (be
it computing, storage, or network) is radically less expensive (often
less than ten percent of the cost) than that same capacity bought in
a higher-end, ‘‘enterprise-grade’’ version of the same product.
While the enterprise-grade products will likely have a place for
certain, very specialized (or perhaps legacy) applications for some
time to come, for most cloud-based applications—particularly for
those that also exhibit the optional (see the next section) character-
istic of inherent reliability—commodity components will do just
fine, while providing their own unique benefits.
It is worth remembering that this price differential has existed
for some time, yet operational complexities and the difficulties in
constructing software applications to run on a commodity infra-
structure have usually made such a move infeasible.
However, once cost and scaling considerations drove wide-
spread adoption of commodity for some clouds, then technological
32 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 33
innovations made it practical (in most cases) for even the most
demanding applications.
Other Common (though Nonessential) Characteristics
While the previous characteristics are essential to any cloud comput-
ing effort, the following characteristics are optional, at least at this
point in time. It is fairly clear that each of these will probably be-
come standard for most clouds over the next few years, if not sooner.
Measured Service (By the Drink) Nearly all public clouds have al-
ways had the ability to bill for precisely the amount of resources con-
sumed, with no prior commitment. While many shared enterprise
facilities have had measurement/billing systems that enabled vary-
ing costs, those have typically been used simply to enable internal
charge-back allocations within an enterprise. Since most clouds are
generally more elastic, then the measured service needed is neces-
sarily more precise.
Multiple Tenants Thepresenceofmultipletenantsinthesame
cloud is certainly the case for nearly all public clouds—it is a simple
matter of economics. While it is very likely that there will always be
the need for a single-tenant cloud (e.g., imagine a national security
organization) it is also clear that for many applications, deployment
into a multi-tenant cloud will be satisfactory, presuming cost and
other advantages.
This will become increasingly true as the enabling cloud plat-
forms and the supporting operational models become more so-
phisticated. In addition, the simple passage of time and the
accumulation of successes will also increase comfort levels for
multi-tenant deployments.
Multiple Applications Nearly all clouds are inherently multi-appli-
cations (i.e., they run multiple individual software applications on
the same infrastructure). However, there are certain high-value
applications for which a dedicated cloud makes sense.
It is interesting to note that the lower deployment and opera-
tional costs of cloud actually make it more (not less) palatable to
consider a dedicated deployment. While dedicated deployments
should be carefully regulated, it’s good to have the practical option.
Basic Concepts: The Big Stuff 33
E1C02 02/21/2010 Page 34
Scalable (Individual Applications) While all clouds need to have
the innate ability to easily scale as a whole, the ability to enable indi-
vidual applications to achieve ‘‘web scale’’ may clearly be reserved
for those circumstances for which it is required.
As a practical matter this leads to an adoption model where an
organization can adopt cloud and start with applications ‘‘as is’’
(except that they are now running on a cloud), then make individ-
ual applications more ‘‘cloud native’’ (and hence more scalable) as
needs dictate, and both time and budget permit.
Having said that, many organizations were initially driven to de-
velop and/or adopt cloud computing by the need to scale an indi-
vidual application—be it search for Google, e-commerce for
Amazon, or delivery optimizations for Federal Express.
8
Reliable At first glance this may seem a pipe dream, perhaps a ca-
pability best left for those demanding ‘‘corner cases’’—those diffi-
cult, high-cost, stringent applications that attract only the most
daring. However, there are two rather surprising aspects of discuss-
ing (high) reliability with cloud-based software.
First, applications that are able to ensure their own reliable op-
eration may easily be deployed on lower cost, full-commodity infra-
structure—in other words, it will not matter if the underlying
components fail. Therefore, building reliability into the applica-
tions will actually enable an organization to lower their costs.
Second, because of the larger number of components that are
used to build a cloud infrastructure (versus a traditional IT infra-
structure), it is actually possible for clever cloud software to develop
a higher level of reliability than was ever possible in the early days of
high-reliability systems, in the days of Tandem and so forth
9
.
While this type of capability is not yet common in cloud comput-
ing, with the advent of more sophisticated cloud application plat-
forms it will become possible to routinely ensure reliability for
nearly all applications, no matter how aggressively the underlying
infrastructure is commoditized.
Major Layers
Computer architects like to talk about ‘‘layers’’
10
of an architecture,
which correspond (in a certain sense) to the layers of a physical
building. For cloud computing we define three major layers–the
34 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 35
cloud infrastructure (commonly known as Infrastructure as a Service,or
IaaS), cloud application platform (commonly known as Platform as a
Service,orPaaS), and cloud application (commonly known as Software
as a Service,orSaaS) layers
11
—moving from the most foundational
to the top. Taken together, these define—at the broadest level—the
cloud computing ‘‘technology stack.’’
While we are not here to explore and debate the merits of this
stack in any detail, it is important to understand at a high level the
major layers. See Exhibit 2.1 for a visual sense of this stack.
Note that this is a high-level view of the technology stack—in
Chapter 4, Cloud Adoption Lifecycle, through Chapter 7, where to
Begin with Cloud Computing, a more detailed model is developed
and used. Chapter 6 details a Cloud Computing Reference Model
with an expanded view of the layers of a Cloud Technology stack.
Infrastructure as a Service (IaaS)
This layer contains all of the physical and virtual resources used to
construct the cloud, and most closely corresponds to what exists in
the more advanced traditional IT operations.
Resources are provided and managed in fairly chunky units—
whole (physical or virtual) servers, storage pools, and so on—and
are generally unaware of what applications are running on them.
There are many innovations in dealing with the complexities of
deployment and operations of this layer, yet even these new capabil-
ities will have their limitations (mostly due to their lack of knowl-
edge of what is running on top of them).
Platform as a Service (PaaS)
The PaaS layer is a relatively recent addition. Assuming that some
cloud infrastructure layer will provide resources (computers, stor-
age, and network) on which to run, the platform is responsible for
Software as a Service (SaaS)
Platform as a Service (Paas)
Infrastructure as a Service (IaaS)
Exhibit 2.1 Cloud Technology Stack
Major Layers 35
E1C02 02/21/2010 Page 36
organizing and operating all of these resources. In addition, the
PaaS is responsible for providing complete virtualization of the in-
frastructure (i.e., for making all of these resources appear to be as
simple as a single server).
How well that is done will greatly influence the complexity, cost,
and effectiveness of both the operations and any efforts to construct
(in whole or in part) software applications. In addition, it is at this
layer where it is most logical to easily ensure reliability for both
cloud applications and storage.
In Chapter 6, cloud platforms are further broken down into
two layers–the Cloud Operating System and Cloud Platform tiers.
Taken together these two layers include both pre-integrated plat-
forms offered only as a service, as well as the middleware tools and
technologies that enable platforms to be constructed out of any
combination of infrastructures–physical or virtual, private or pub-
lic, and so forth–virtualized, and then easily delivered as an inter-
face-accessible cloud capability. For more details on this
categorization, see Chapter 6.
Software as a Service (SaaS)
The cloud applications/SaaS are at the top of the stack, and when
all is said and done are the reason why any cloud is built in the first
place. That is, it’s the applications that are precisely what anyone
outside of the cloud technology and operations groups requires.
Modern cloud applications are often heavily influenced by and
incorporate web technologies. It is worth noting that many of these
techniques actually shift certain responsibilities to the storage facili-
ties (e.g., databases, etc.), which has some interesting implications
(see Chapter 8, All Things Data, for a fuller discussion).
In addition, bringing existing conventional applications into a
cloud is made much simpler by a good cloud application platform,
as is the task of constructing fully native cloud applications (either
from an existing, conventional application, or from a blank slate).
Where They Live (Deployment Models)
Now that we have covered the broad outlines of the cloud technol-
ogy stack, let us turn our attention to the basic forms in which it is/
will be deployed. While this is an area of rapid innovation—rapid
36 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 37
even by the standards of the cloud computing world—we can
already see the basic options.
Private Cloud
For some time there were many who denied that such a concept as a
private cloud was even possible—they claimed that it was oxymo-
ronic—and indeed, there remain a diminishing few who still main-
tain that this is the case.
But most now recognize that there are many situations where for
strategic, operational, or perhaps simply cultural reasons an organi-
zation may choose to build and operate their own, private cloud.
These private clouds can be built and operated as just what their
name implies: a fully functional cloud that is owned, operated, and
presumably restricted to a particular organization. In fact, there are
an increasing number of software and service offerings designed to
facilitate just this—essentially ‘‘private clouds in a box.’’
Depending on operational/security considerations, private
clouds may be interconnected with public clouds [see the ‘‘Vertical
Clouds (aka Community Clouds)’’ section later in this chapter].
A special case is the virtual private cloud,whichisanyprivate
cloud that is provisioned and operated by an outsourcing/hosting
provider. For some these offer the best of both worlds—the control,
security, and privacy of a private cloud with the ease of deployment
and operations typical in public clouds.
Public Cloud
The first clouds of any kind were mostly public clouds, e.g., Google,
Amazon, and Salesforce are a few notable examples. These are
multi-tenant clouds that have tended to focus on particular layers.
For example, Google and Salesforce have tended to focus (at least
in their public offerings) on cloud application offerings, while
Amazon has tended to focus on the infrastructure layer. In addition,
both Amazon and Google have recently entered the platform mar-
kets as well.
In any case, these can also be thought of as horizontal clouds,
in that they are relatively broad-based offerings of a particular ca-
pability, be it infrastructure, a data service, search, or some other
service.
Where They Live (Deployment Models) 37
E1C02 02/21/2010 Page 38
These are an important and rapidly growing cloud sector, the
source of much innovation, but will not consume all of comput-
ing.
12
That is simply irrational exuberance, which overlooks some
very practical realities.
Vertical Clouds (aka Community Clouds)
An interesting recent development is the emergence of a special-
ized form of public cloud known as a vertical cloud, sometimes
known as a community cloud. These are public clouds organized
around a group of competing/cooperating businesses in a particu-
lar vertical market, such as financial services.
Able to provide industry-specific capabilities (such as govern-
ance, auditing, and security) these can be thought of as a sort of
shopping mall for cloud services, virtually (and perhaps physically)
co-located to help all achieve a critical mass for customers interested
in that vertical.
For example, a financial services vertical cloud could bring to-
gether cloud-based services that provide everything a retail broker
would need to service their customers—from specialized data feeds
to account maintenance to reporting services and more—enabling
those brokers to pick and choose among service providers, easily
pulling together their own unique, customized offerings for their
own customers; while still knowing that all of their industry-specific
security and auditing requirements are met.
Hybrid Clouds
As the name implies, a hybrid cloud is a combination of any/all of
the other types of clouds. In practice, this is what the most robust
enterprise cloud approaches will utilize. While it is possible to dog-
matically stick to only private, only public, or only vertical clouds, the
real question is simply: why?
There is a class of modern platforms emerging that enable an
organization to effectively create their own cloud out of a combina-
tion of particular private, public,andverticalclouds,yetmanage
this hybrid cloud as one, from one place, at the same time.
This approach enables an organization to use the best tool for
each job, while containing the increase in complexity.
For these reasons it is likely that most enterprises will take, by
design or by circumstance, a hybrid cloud approach.
38 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 39
Geographic Location
At first blush it may seem that with cloud computing, we no longer
have to consider geographic location; after all, when is the last time
that you thought about where your search is performed, for
example?
Whileitistruethat(duetotheubiquitous access nature of
cloud computing, itself inherited from the Internet on which it is
based) cloud-based services can be thought of in a certain sense
without regard to their location, this is only a first step.
Nothing in cloud computing has any potential to repeal the laws
of physics—the speed of light remains the speed of light—so conse-
quently delays in transmitting data (known in geek speak as latency)
can become a real problem in delivering a quality service.
That is why a sophisticated cloud strategy takes into account
physical location, and provides controllable, relatively transparent
mechanisms for staging data closer to where it is needed.
In any case, the bottom line is that while in one sense cloud-
based services are inherently global, in another sense the best will
know how to make informed decisions to minimize the negative im-
pacts of geographic distance.
Datacenter Innovation
As a direct result of several cloud characteristics—relative uniform-
ity, commoditization, aggregate scale, and complete virtualization—
there has been a very high degree of innovation in the physical con-
struction and packaging of datacenters, with undoubtedly much
more to come.
Containerized Datacenters
Traditional datacenters have had a relatively high degree of custom-
ization, with particular servers, mainframes, and so forth requiring
careful planning, provisioning of power, cooling and network ac-
cess, then individual installation and operations.
Over time there has been a slow drift toward standardizing the
choices and thereby simplifying the physical processes.
The aggressive consistency of a cloud infrastructure layer has
opened up the possibility of a fully containerized datacenter, in
which prepackaged containers—similar to shipping containers,
Datacenter Innovation 39
E1C02 02/21/2010 Page 40
except already full of a consistent setofservers,storage,andnet-
work components—are delivered into a large, warehouse-like facil-
ity and connected to standardized power, cooling, and network
connections.
This enables some real gains from standardized components, at
least for a given datacenter. Unfortunately, there are not yet any
standards for the containers themselves, so each deployment is rela-
tively unique.
Low-Density Datacenters
Most containerized datacenters have been optimized for a developed
civil infrastructure, in which space is a relatively dominant considera-
tion. Consequently, the goal has generally been to increase density.
Unfortunately, with increased density comes increased heat, which
then becomes perhaps the dominant engineering consideration—
to the point where many datacenters are located near bodies of wa-
ter, similar to power plants. In fact, some proposals have gone so far
as to propose datacenters on ships, though these have some other
significant limitations.
However, in economies where space is relatively plentiful, partic-
ularly with respect to reliable power—typical of much of the devel-
oping world, for example—a diametrically opposite approach will
likely make the most sense: the low-density datacenter.
In this approach equipment is actually spaced far enough apart
to allow for air cooling. While this will consume more space, in
some climates it may be sufficient to essentially build a modest roof
with open fencing around the perimeters (plus sufficient physical
security, of course).
Note that this will actually be much more effective for clouds
that provide reliability in software above the infrastructure—in a
sense, this is the ultimate in commoditization.
The Quest for Green
Whether in the industrialized or developing world, the reality is that
for economic, political, and sociological reasons it makes sense to
minimize the environmental impact of any computing deployment.
Due to all of the characteristics mentioned previously, cloud
computing is uniquely suited to enable significant advances.
40 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 41
In particular, complete virtualization enables the applications to
be indifferent to the type of infrastructure upon which they run;
that infrastructure can then be optimized for the most capacity for
any given power or other resource consumption; and the inherent
elasticity of cloud enables infrastructure to be run at much higher
utilization levels.
All of this makes it practical to greatly improve the amount of
computing capacity provided at any given level of environmental im-
pact, a process that is in reality only just beginning.
Standards
The standards picture in cloud computing is decidedly mixed. On
the positive side there are a number of standards-based web technol-
ogies that form many of the everyday software components used to
build cloud applications.
In addition, there are a number of de facto standards (i.e., prac-
tices, application program interfaces (APIs), and technologies) that
have proven successful for a market leader, and therefore by default
form a sort of standard. For example, over the past few years many
web-based services provided a standardized means by which other
applications could make use of them that was based on a common,
easily-used style called a ReST interface (Representational State
Transfer—see Chapter 3, Cloud Computing and Everything Else, for
more information). As these services evolved into cloud-based ser-
vices the ReST interfaces naturally remained, and because they were
so easy to use, actually spread through the cloud infrastructures. As a
result, ReST-style interfaces have now become the de facto standard
for cloud-based applications, platforms, and infrastructures.
However, there are few formal, cloud-specific standards in any-
thing beyond the earliest stages of discussion. Examples here in-
clude the Cloud Computing Interoperability Forum (CCIF), NIST,
and several others.
In practice, the lack of established, formal standards is not a bar-
rier to adoption, at least not at this stage of the industry. However, as
standards generally facilitate the interchangeability of suppliers,
and therefore reduce the risk for customers and consequently facili-
tate overall industry adoption and growth, at some point it will be
necessary to develop formal, widely-accepted standards. That is why
initial discussions have started in several circles.
Standards 41
E1C02 02/21/2010 Page 42
While a more in-depth discussion of cloud computing standards—
de facto, developing, or simply missing—is included in Chapter 6, at
this point it should suffice simply to remember that the de facto
standards will do for now, industry-wide standards will eventually de-
velop, and in the meantime it’s up to each organization to make use
of technologies such as cloud platforms (PaaS) that will enable
them to make use of any standards as they develop.
Much Sound and Fury . . .
As discussed earlier there have been seemingly endless debates on
exactly what is and is not a cloud, whether such ideas as a private
cloud could ever make sense or was, as some allege, simply a hope-
less oxymoron, and so forth.
There were even some—Nicholas Carr and Greg Papadapo-
lous among others—who argued that this was mostly moot, since
all private datacenters would eventually disappear, and all public
clouds would consolidate until there were, essentially, only a few
big computers (each actually a cloud itself) on which all of the
computing needs of all residents and organizations on the planet
were met.
Still, much of this ideological debate really misses the point.
That is, it is not unsubstantiated, unpersuasive ideological state-
ments that will win these arguments; rather, organizations will use
whatever works best for them.
In other words, the approach that is truly the best will eventually
win out.
Parting Thoughts
Setting aside a few emotion-laden, caffeine-exacerbated debates,
what remains to keep in mind?
Cloud computing:
Has come together relatively quickly
Offers a new technological, operational, and business model
approach
Radically increases scalability, elasticity, and more
Dramatically reduces deployment and operational costs
42 Concepts, Terminology, and Standards
E1C02 02/21/2010 Page 43
Taken together, this paints a fundamentally different picture in
every dimension. Consider the very audacity of anyone from the
computing industry even semi-seriously claiming that any comput-
ing resource could be thought of as ‘‘easy to obtain, cheap, easily
accessible, and just works.’’
Audacious, perhaps . . . yet most definitely true. Yes, this is a
new age in computing. One that is not only possible, but here today.
Notes
1. With apologies to John Godfrey Saxe. This was first presented at the 2008 Next
Generation Datacenter Conference, then appeared in a popular blog post:
www.appistry.com/blogs/sam/the-blind-men-and-cloud.
2. Foley, ‘‘A Definition of Cloud Computing,’’ Information Week, September 26,
2008.
3. Mell and Grance, ‘‘Draft Working Definition of Cloud Computing’’ V14, US
National Institute of Standards, June 2009.
4. ‘‘Clearing the Air on Cloud Computing,’’ McKinsey & Company, March 2009.
5. For a number of years there has been a push within the enterprise for service-
oriented architectures (SOA). In many ways SOA evolved into an important
enabler for cloud computing—while some of the particular technologies and
standards are different, the basic approaches remain very useful. This will be
explored in more detail in Chapter 3, Cloud Computing and Everything Else.
6. Some claim actual location independence, but this is unrealistic as it ignores the
technical realities that stem from the laws of physics. The delays that stem
from distance will always lead to a need to consider location, at least for many
applications.
7. That Southwest faces challenges is primarily due to other factors, including
some that derive from its very success. Of course, a full discussion of their cir-
cumstances is outside the scope of this book.
8. Charrington, ‘‘Cloud Computing for Government Featuring Federal
Express,’’ CloudPulse Blog, August 12, 2009.
9. Tandem ‘‘Non Stop’’ Computers were the most widely used and arguably the
most well-known of a small group of technology providers who’s entire focus
was ultra-high reliability–the so-called ‘‘five nines’’ and beyond–computing
systems. These systems often duplicated every piece of hardware and even
many software components, and found wide usage in certain financial service
applications (like stock-trading platforms) and other similar areas. Such reli-
ability came at a very high price, and as a result these types of technologies
never approached mainstream acceptance.
10. These correspond to what the NIST team calls their ‘‘deployment models.’’
11. Note that Infrastructure as a Service,IaaS, and simply infrastructure are used in-
terchangeably to refer to the bottom tier of the cloud technology stack; Plat-
form as a Service,PaaS,cloud application platform,andsimplyplatform are used
Notes 43
E1C02 02/21/2010 Page 44
interchangeably for the middle tier; in a similar vein Software as a Service,SaaS,
cloud application, and sometimes simply application are generally equivalent for
the top tier.
12. Nicholas Carr in The Big Switch (Norton, 2008) and Greg Papadapolous (Chief
Technology Officer of Sun prior to the acquisition of Sun by Oracle) in vari-
ous talks have each famously argued that all computing will eventually consoli-
date into a small handful of computers/clouds. This is better as a
conversation-starter than a reality, and will be examined in more detail in
Chapter 9, Why Inevitability Is . . . Inevitable.
44 Concepts, Terminology, and Standards
E1C03 02/21/2010 Page 45
3
CHAPTER
Cloud Computing and
Everything Else
As with any fundamentally new innovation cloud computing
does not come into a controlled laboratory environment—rather,
this is the real world, a complicated amalgam of decent systems
that work, slightly out of date facilities that cost too much to run,
are hard to expand, and costly to modify, and those archaic old leg-
acy monstrosities for which we’ve lost the source code, all run by
teamsoffolksarmedwithducttapethatjustpraythattheycan
coax it to work each month and not cause too much pain . . . or as
Clint Eastwood would say, ‘‘the good, the bad, and the ugly.’’
That is what we already have in place—so where does cloud
computing fit in?
In this chapter we will seek to understand the relationships be-
tween cloud computing and all the other stuff in and around the
technology infrastructure of the enterprise (i.e., service-oriented
architecture [SOA], web services, grid computing, clusters, etc.).
You can read this chapter in just about any order, all at once or in
bite-sized chunks.
The Neighborhood
In this first section we will focus on tangible and abstract entities,
those existing architectures, software, and physical components
that either have been or are currently common in the enterprise
technology infrastructure.
45
E1C03 02/21/2010 Page 46
Service-Oriented Architectures
In the earliest days of computing, application software was often built
in a large, complex, tightly integrated fashion, often with circuitous
internal structures. Since these applications were relatively difficult
to maintain and even harder to evolve, during the 1980s and 1990s
the industry increasingly adopted ‘‘object-oriented’’ techniques.
In object-oriented software development each application—
while still quite large itself—is built from a relatively large number
of small components, with each component formally defined. This
tended to significantly help by narrowing the functionality of each
individual component, making each component easier to maintain
and evolve, and when done well, these benefits extended to the
entire application. In fact, an entire market of software develop-
ment tooling developed, as did many development methodologies.
In essence, what made this evolution work was that many of the
unnecessary dependencies between objects were removed from
within the application. Still, this was not enough—first, the individ-
ual objects still tended to be too dependent on each other (too
‘‘tightly coupled’’); second, it was still difficult to make use of useful
functionality within an application without involving nearly the
entire application; finally, even applications that had been built
entirely in the object-oriented style were not necessarily easy to dis-
tribute across multiple machines within an enterprise, much less
across the Internet.
So at the beginning of the new millennium the industry began
to take the next step in this drive toward independence between
software components, and this next step came to be known as ser-
vice-oriented architectures (SOA).
In the SOA approach, the key structure is the ‘‘service’’ (i.e., a
bit of application software that can do something useful (service im-
plementation), has a formal mechanism that specifies how to invoke
the service (service interface, e.g. WSDL or REST) and which can be
invoked across a network whether across a network within an enter-
prise or across the Internet does not). In the SOA paradigm, a ser-
vice contract specifies both the service interface, as described above,
as well as the contractual terms of the consumer-provider relation-
ship, the quality of service committed to by the provider and
expected by the consumer, and the detailed service level agreement
(SLA) requirements for security, uptime, availability, response time,
46 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 47
et cetera. The concept of a contract and SLAs are directly relevant
in the context of cloud computing.
There are many different approaches for defining these individ-
ual services, for discovering where they may be found within a net-
work, and for invoking them. Some of these are more formal, others
less so; some tightly controlled, others more inherently flexible. Re-
gardless of which precise form of service-oriented architecture one
chooses, the main point is that individual services are generally
more independent from one another than before (more ‘‘loosely
coupled’’ in geek speak).
It is worth noting that, by design, the specification for a service
does not say much about the sort of computer on which that service
runs, nor how much a particular instance of a service is capable of
scaling (i.e., how much work it can handle). As long at the service
provider can meet the terms of the service contract, and the speci-
fied quality of service (QoS), and other requirements of the SLA,
the service consumer will be satisfied. This was done in the name of
increasing independence, but led to an interesting problem, which
we like to think of as the ‘‘unintentionally mission critical’’ service.
Too Much of a Good Thing The idea of ‘‘unintentionally mission
critical’’ can best be understood by way of example.
Suppose that an application developer at Amazon (in the early
days, of course, when services were still running on more traditional
infrastructures) was assigned to create the facility for handling digi-
tal music sales. As part of that effort, the developer decided to im-
plement a service that did a particularly good job of detecting and
avoiding credit card fraud.
So they dutifully build and deploy the fraud detection service,
planning for the capacity anticipated for the new digital music store.
All is well until the results are in, and word circulates amongst the
owners of the other commerce facilities that this particular fraud
detection algorithm is superior to their own.
What happens next is interesting.
Since the details about the fraud detection service are not visible
to the calling applications, and since how to invoke the service is
both well understood and works well across the internal network,
each of the other owners will tend to do the obvious: They will begin
using the new, superior fraud detection service, even though this
was not taken into account in the initial creation and deployment
The Neighborhood 47
E1C03 02/21/2010 Page 48
of that new service. This seems rational, and since the SOA makes
the actual software integration trivial, then this is what will tend to
happen.
However, no matter how cleanly the SOA defined the relation-
ships between the services and the responsibilities of each one, the
service itself still has to be built and physically run somewhere. If
this is done with one of the dominant enterprise software architec-
tures prior to cloud computing, then this will simply lead to capacity
problems (at best), or near-chaos at worst. As much as estimating
capacity for business applications is more art than science, estimat-
ing capacity requirements for SOA services, especially a large quan-
tity of services, is even more challenging.
While it is true that careful SOA governance can avoid (or at
least reduce) the possibility of chaos, services built and deployed on
traditional architectures will, of course, retain all of the scalability,
reliability, and flexibility of the architectures on which they reside.
APerfectFit This is where cloud computing and SOA come to-
gether. In short, services defined within an SOA are best deployed
within a cloud (public, private, or hybrid), and in doing so will gain
all of the advantages of cloud-based software. Thus, with a cloud as
the hosting environment for SOA services the SOA paradigm can
better deal with unanticipated demand for services, and better sup-
port many SLAs for multiple service consumers in a more elegant
fashion. Conversely, while it is not strictly necessary to define cloud
applications in terms of services (within a SOA), experience has
shown us that cloud applications are at their best when defined this
way—so much so that many see the two as inseparable.
1
This perfect fit is explored in much more detail in Chapter 4,
Strategic Implications of Cloud Computing, and Chapter 5, Cloud
Adoption Lifecycle.
Web Services
For many the term ‘‘web services’’ is entirely synonymous with SOA,
but for this discussion we are going to highlight the internet-breed-
ing of web services.
In particular, even as the transition to object-oriented software
design was underway, efforts continued to enable objects to be dis-
tributed across many machines.
2
These efforts led rather naturally
48 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 49
to hints of distributing basic services across the Internet. For exam-
ple, in 1996 Marc Andreesen (at that point a newly minted entrepre-
neur and co-founder of Netscape, a seminal purveyor of Internet
technologies) wrote a note entitled ‘‘IIOP and the Distributed
Objects Model’’ which posited this very idea: basic services in a sense
‘‘published’’ across the fledgling Internet, available to all to use as
they saw fit.
As this idea began to take shape, there were many voices calling
for formal standards, which were just plain common sense—if this
would be how companies interacted in the future, there had to be a
lingua franca acceptable to all. After all, it was the creation of TCP/
IP in the 1970s and a handful of protocols in the 1980s and early
1990s (http, html, etc.) that had led to the Internet itself. With that
in mind a vigorous effort was undertaken by many to define formal
web services standards, which came to be known as the WS-family
of protocols.
The WS-family of protocols came to be known as that because
the definitions themselves proliferated rapidly (‘‘’’ being the tech-
nical symbol for ‘‘wildcard,’’ meaning anything could go there). WS-
MetadataExchange, WS-Coordination, WS-I, WS-CAF, WS-Atomic-
Transactions, WS-ReliableMessaging, WS-Basic Security Profile, WS-
DL, WS-BusinessActivity, WS-MakeConnection, WS-Star, WS-Reliabil-
ity, WS-Security, WS-TX, SOAP, WS-Policy, WS-Addressing, WS-Trust,
WS-Transfer—these were only a few of the standards defined. Many
efforts were made to make sense of all this, leading to complex
poster-sized maps, and so forth.
3
These maps look interesting to be sure, but upon closer exami-
nation they are rather sobering: dozens upon dozens of boxes, each
representing at least one WS-standard, each with its own detailed
definition of how to use it, when to use what, how they interacted
with each other and the outside world, and so forth.
The unfortunate reality is that while the WS-world was techni-
cally correct in a certain sense, it introduced a level of complexity
that was difficult for nearly anyone to really understand well, lead-
ing to a learning curve that started way up in the . . . well, way up in
the clouds. This led to a real barrier to entry that significantly inhib-
ited adoption. There were many other issues as well,
4
but those are
outside of the scope of this discussion.
In search of a simpler, easier to use approach to web services the
industry developed a relatively simple extension to basic web
The Neighborhood 49
E1C03 02/21/2010 Page 50
protocols known as ReST
5
—a development ‘‘style’’ –that is part phi-
losophy, part technology, part discipline. ReST was proposed in
2000, and ReST-style web services began appearing around 2002.
Part and parcel with the web, ReST was indeed simpler to use and
understand (for a number of reasons, including the simple fact that
there were a lot less standards, and therefore less to learn before a
developer could get started), promoted greater independence be-
tween individual services, and generally encouraged experimenta-
tion and flexibility.
With all that in mind, it should come as no surprise that ReST–
style web services quickly came to dominate web services. In fact, as
early as April 2003 it was reported that (speaking of what developers
were actually using) ‘‘Amazon has both SOAP and ReST interfaces
to their web services, and 85% of their usage is of the ReST inter-
face.’’
6
That early momentum continues to this day, to the point
where ReST is likely to become the de facto standard (or at least
‘‘dominant style’’
7
) for web services.
So then, web services in this sense are part of the DNA of cloud
computing—this is simply how native cloud applications tend to be
thought about, built, and accessed, whether or not there is a com-
prehensive SOA-anything in place. While it is possible to run an ap-
plication in a cloud without making portions available via one or
more ReST-style web services, it just is not done that often . . . and
that is a good thing.
Web 2.0
The first 20 or so years of the Internet (before 2000) were mostly a
struggle simply to connect—to develop the basic plumbing and in-
frastructure to allow the Internet to even exist. As the early Internet
began to take shape the very hint of the possibilities led to the first
Internet Bubble and its demise in 2000—famously foreshadowed as
‘‘irrational exuberance’’ by then U.S. Federal Reserve Chairman
Alan Greenspan.
It is ironic to look back now and consider the impact of the
bursting of that Internet Bubble. Many considered the Internet it-
self a bust, hype whose heyday had come and gone, a sort of market
and technology best remembered over drinks, if at all. Yet the reality
was quite the opposite: While the financial calamity for many had
50 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 51
been real, the simple truth was that the Internet had barely begun
taking its first ‘‘baby steps.’’
At some point around 2003 to 2004 enough web-based services
(that had no equivalent outside of the Internet) existed—Google,
Amazon, blogs of all kinds, Yahoo, Wikipedia, MySpace, eBay, and
so forth—that there was a qualitatively different feel to the Inter-
net, more possibilities for both personal and business use, more to
what it all meant. Note that it was also during this period that
Salesforce.com began to gain some serious traction (credibility
and market acceptance), the first Software as a Service (SaaS)
offering specifically aimed at enterprise customers to reach
milestone.
So gradually the term ‘‘web 2.0’’ came into use, which while
pushed and pulled by many in one direction or another, in time
came to refer to this new phase of the Internet.
8
There were certain
characteristics that were common to many of these new services. In
particular, many of these services had a:
Natural sense of scale
Certain flexibility/dynamicism
Universal ‘‘anywhere’’ accessibility
Ability to mix and match one service with another by anyone
Fostered collaboration
Some were stronger in one characteristic or another, but over
time most services either tended to adopt all of these characteristics
or they disappeared.
The ability to mix and match one service with the other was
enabled by the wrapping of these services with a ReST interface, also
known as an application programming interface (API), and this
turned out to be a key development. Sometimes the ‘‘mixing and
matching’’ is done in client-based applications (often resident within
a browser), sometimes in traditional server-based applications, or
sometimes in applications themselves resident with a web services
provider. While it is not the only way to create these composite appli-
cations, the ad-hoc approach came to be known as a ‘‘mash-up.’’
9
In addition, there were two other characteristics that ironically
owed much of their existence to the financial challenges resulting
from the bursting of the Internet Bubble.
The Neighborhood 51
E1C03 02/21/2010 Page 52
First, the best of these services had an aggressive sense of com-
modity for the infrastructure. For example, Google was famous for
building racks of very cheap boxes rather than simply using the tra-
ditional sturdy servers. Combined with the need for flexibility and
scale, this encouraged the development of new types of application
architectures, operations, and so forth.
Second, the need for business models that could financially sup-
port the growth of these services was acute, and as much as any tech-
nical contribution, the development of a viable advertising supported
business model fueled the explosive growth of Google, which of
course proliferated rapidly. Eventually this mixed with subscription
models, leading to such hybrids as the ‘‘freemium’’ model (i.e., a
free, advertising supported basic service to promote easy adoption,
combined with subscription-supported premium offerings).
It is clear that much of what transpired in web 2.0 was a natural
progenitor of cloud computing. While modern cloud computing in-
cludes much more, nearly all of web 2.0 can now reasonably be un-
derstood as cloud-based.
Agile Development
During the middle 1990s there were a number of efforts to begin
developing software development methodologies that were more ef-
ficient (‘‘lighter weight’’) and more effective (making it more likely
that the software would do what was needed and do it well), yet re-
tained strong management controls and accountability. Over time
these came to be known as ‘‘agile development methodologies,’’ or
simply ‘‘agile development.’’
One of the hallmarks of most agile development methodologies
is the idea that development is done in relatively short chunks
known as ‘‘iterations,’’ typically on the order of two or three weeks.
A key reason for this is to enable adaptation to changing conditions,
to knowledge gained about requirements and surrounding systems,
and so forth.
This type of rapid iteration, with relatively fine-grained correc-
tions in direction, makes good use of the idea of data and services
being exposed via web services, and also tends to further encourage
the growth of these services and APIs.
In many ways agile development is a far more natural fit with the
malleable nature of web services, so while not required to either
52 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 53
create or make use of web services, agile development tools and
methodologies are used in the creation of and consumption of
most web services.
As a consequence, it is only natural to make use of agile develop-
ment tools and methodologies when creating, maintaining, operat-
ing, and supporting cloud-based applications, platforms, and
infrastructures, whether those are in a public, private, or hybrid
cloud.
Application Servers
Toward the end of the 1990s the drive toward building out web-
enabled applications created a need for a set of common services
that would ease the task of the application developers. These rapidly
developed into numerous products and a few standards: By 1999
there were more than 30 startups offering products in this area—
and within a couple of years this consolidated into a mature market
with a handful of dominant players.
10
In fact, this domination was so
complete that as one of the authors raised money for a startup
11
in
2003 and 2004 it was common wisdom that the world of software
development was now complete—it would be impossible to con-
vince any enterprise to consider any approach other than the big
application servers for any enterprise application.
An interesting thing happened in the short transition from in-
novation to: In the rush to add features and capabilities, a growing
contingent were dissatisfied with the relative ‘‘weight’’ (perform-
ance penalty and effort needed by a developer) and complexity of
the then-modern application servers. This led to the development
of frameworks
12
that could enable a developer to pay less attention
to the requirements of each application server, to effectively decou-
ple the applications from the application servers themselves, as well
as attempt to simplify life for developers.
As these frameworks gained popularity it became more com-
mon for applications that had previously been built and deployed
on classic applications platforms to make use of smaller, relatively
lightweight app servers such as Tomcat,
13
Jetty, and others. In fact,
by late 2007 Tomcat was being used by 64% of enterprise Java
developers.
14
Besides the relatively heavy performance and development taxes
imposed by the classic application server, there was an even more
The Neighborhood 53
E1C03 02/21/2010 Page 54
fundamental problem—a dissonance of assumptions. The classic
application server was intended to run on an enterprise cluster, a
relatively small number (2 to 4, sometimes up to 8) of relatively
costly, high performance servers. This was the world of the typical
large Unix server. This led to certain architectural and design deci-
sions that did not adapt well to a world of large numbers of relatively
cheap, small, lightweight commodity computers. Many attempts
have been made to make that transition, but at this point there is
broad consensus that such efforts will not be sufficiently productive.
Taken together, these trends are leading to the gradual emer-
gence of the cloud application platform (aka Platform as a
Service)–the true successor to the classic application server. Com-
bining lightweight application containers (language- and some-
times problem-specific), a variety of storage, messaging, and other
useful core facilities, along with self-operational capabilities, all of
which are intended for the large number of small computers (physi-
cal or virtual) that are typical of cloud infrastructures, these cloud
application platforms are advancing rapidly.
Messaging and Transactional Middleware
Message-queuing middleware (such as an enterprise service bus)
has traditionally been one of the key approaches in providing the
glue that holds many enterprise applications together, the founda-
tion upon which disparate applications have been integrated. They
have provided some elements of reliability across distributed sys-
tems, among other technical contributions.
The transition to cloud computing will generally reduce the
need for traditional messaging middleware for two reasons. First,
one of the roles of a cloud platform is to radically reduce the com-
plexity of the infrastructure, at least in its appearance to the devel-
oper. Consequently there are fewer individual components to
coordinate for the messaging layer. In other words, if a messaging
layer is used to communicate between systems it will have quite a bit
less to do. As you can see in Exhibit 3.1, rather than relying on the
messaging layer to communicate between individual servers (physi-
cal or virtual), it need only communicate between major services.
Second, the actual communication is increasingly occurring via
web service invocation directly. One of the reasons that this is practi-
cal with web services that are deployed on cloud application
54 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 55
Exhibit 3.1 Overview
55
E1C03 02/21/2010 Page 56
platforms is that they are much more adept at handling high-de-
mand bursts, minimizing the need for another historically useful as-
pect of messaging middleware.
Easy on the State In a related trend, for reliability and scale rea-
sons there has been a broad trend toward relaxing transactional
requirements in many applications, moving toward a set of ap-
proaches that implement ‘‘eventual consistency.’’ That is, the appli-
cations maintain everything that is needed to ensure accurate
results, but this may take time (seconds, minutes, or perhaps lon-
ger) for the accurate results to be reflected consistently throughout
the enterprise. While this will not be applicable to every situation,
‘‘eventual consistency’’ is often quite helpful.
Note that this goes hand in hand with a general trend toward
‘‘stateless programming,’’ in which individual operations are exe-
cuted independent of one another. This is a requirement, for exam-
ple, of ReST-style web services.
Finally, cloud application platforms are generally providing one
or more state mechanisms of their own, as well as having the ability
to easily host others.
All Together It is safe to say that this is one area that will change
the most in the transition to cloud. For a variety of reasons much of
the need for both messaging and transactional middleware facilities
(as now conceived) will decrease, and what remains may be handled
by lighter-weight facilities, perhaps integrated into the cloud appli-
cation platform directly.
Dynamic Languages
One of the more surprising developments in computing during the
past 10 or 20 years has been renewed innovation in the area of pro-
gramming languages. For many years it has been an a priori assump-
tion that software would be written in a static language such as Java,
C/C++, C#, and so on. But recently there has been a growing trend
toward using dynamic/scripting languages.
In a certain sense these dynamic languages are part and parcel
of the whole dynamic nature of web applications, which as we have
discussed are themselves instrumental in native cloud applications.
For example, much of the code that presents the ‘‘face’’ of a web
56 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 57
service is written in Javascript, which despite its name is actually very
much a dynamic language. Other dynamic languages common in
web development are PHP, Perl, Ruby, and a whole litany of others.
While their heritage may be modest (dynamic languages used to
be derided as unstructured, unmaintainable, not proper for ‘‘seri-
ous software’’), dynamic languages are carving out significant roles
in the cloud computing ecosystem. From their beginnings as script-
ing languages, dynamic languages have always been used to glue
applications together; with the decomposition of applications into
sets of web services, this becomes an increasingly significant role.
There has been and will continue to be significant innovation in
this area for some time.
However, at the same time there are many situations for which a
traditional static language remains preferable. For this reason most
cloud application platforms just assume that software will be written
in a variety of languages, and that all resident software should be
able to reasonably interoperate. Look no farther than Google’s
entrant, Google App Engine: It was initially launched with support
only for services written in Python, but over time support for Java-
based services was added as well. Other offerings, such as the Appis-
try CloudIQ platform support services written in a wide variety of
dynamic and static languages have also been added.
In short, dynamic languages match much of the intrinsic nature
of cloud’s roots, and as such have an important (though not exclu-
sive) role to play in creating the services and applications native to
cloud computing.
Databases, Data Warehouses, and Storage
It is in the business of storing and accessing data (particularly at
scale) that the transition to cloud computing will have the largest
impact . . . so much so that Chapter 8, All Things Data, of this book
is dedicated to this topic. So for a more detailed sense of the
changes that will occur, refer to that chapter. Here we will briefly
cover the relationship of existing databases, data warehouses, and
storage facilities to cloud computing.
The headline is simple: Most existing databases, data ware-
houses, and enterprise storage facilities can be utilized by a cloud-
based application, provided that application is operating within a
private cloud, or in a properly secure hybrid cloud. At a high level
The Neighborhood 57
E1C03 02/21/2010 Page 58
these applications will appear essentially the same as any other exist-
ing enterprise application to the database, data warehouse, or enter-
prise storage facility, which is very helpful in and of itself.
Having said that, there are several issues that will quickly be-
come apparent. First, the computing capabilities in a private cloud
will tend to pressure the storage infrastructure—first the network-
ing interconnect, then the database/storage servers themselves—
and this will lead quickly to performance and capacity limitations.
This will be particularly true if the applications are relatively ‘‘cloud
native.’’
Second, databases that are resident on large server clusters and
mainframes will tend to have a large penalty for accessing the data
outside of that cluster or mainframe.
Third, many existing databases are severely handicapped
by having application logic embedded within the database itself
(this was a big trend in the 1980s and 1990s). While this may have
madesenseatthetimeitwasdone(andwasoftendonewithout
real knowledge of the consequences), it can be a real impediment
to scale, and therefore to meaningful accessibility to cloud-based
applications.
All of these caveats lead to the discussion that is Chapter 8,
All Things Data. So what is the bottom line? Regarding accessing
existing databases, data warehouses, and enterprise storage facili-
ties, cloud-based applications (particularly those in a private or
hybrid cloud) are on an equal footing with other enterprise appli-
cations that are not resident on the database, data warehouse, or
storage facility itself—no better or no worse—and that is a fine
place to begin.
Mainframes, Clusters, Big Servers, and Legacy Applications
Let us go ahead and ask the question right now that many wonder
about: Will cloud computing finally bring about the death of the
mainframe? (Of course, by extension this could also be applied
[with caveats] to the big servers, clusters of those servers, and the
legacy applications that run on them all.)
Well, in a word the answer is: no.
15
While this may seem counterintuitive, particularly when one
considers all of the many advantages of cloud computing, there are
58 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 59
two large issues that drive the stickiness of these mainframe and big
servers.
First and foremost is the data resident on these machines, partic-
ularly that resident within a database of some kind. While this data
can nearly always be migrated to a cloud-based facility, it is not al-
ways prudent to do so at this time.
16
Second are the applications themselves. While these tend to
closely follow the data, there are many practical limitations to
migrating applications. The world of computing in the enterprise is
replete with stories of applications for which no source exists; appli-
cations for which sources exist but the required supporting tools are
no longer supported; and applications for which sources and sup-
porting tools do and are supported, but for which no living person
has any reasonable ability to understand enough about the applica-
tion to even hope to modify, much less move the application. These
stories are real; these applications exist.
Well then, what can we do?
For this there are two words: integration and interaction. First,
either by using existing integration points or by creating new ones
(preferably wrapped within a web service), the legacy application
can be made available to the cloud-based applications within the
enterprise as they are created. Second, those integration points can
then be used to allow the newer cloud-based applications to natu-
rally interact with the legacy applications, to include them in the
evolving workflow. This will ease the introduction of and progressive
transition to cloud-based applications.
As a practical matter this transition is not likely to have a specific
horizon, though a particularly aggressive organization may choose
to define a particular horizon (timeframe for retirement) for cost,
competitive, or other strategic reasons. In addition, note that exis-
tence of a mainframe facility will tend to drive an enterprise toward
the hybrid or private cloud options, though not necessarily so.
In any case, the reality is that each enterprise will migrate what
makes sense as it makes sense. While some may choose to call their
mainframes and big servers part of their private cloud, that does not
really make sense as it tends to obscure the real issues involved and
the real gains to be made by implementing such a cloud.
So the bottom line: mainframes, big servers, and legacy applica-
tions can cooperate and coexist with cloud-based applications, but
are not otherwise themselves within the cloud directly.
The Neighborhood 59
E1C03 02/21/2010 Page 60
Grid and High-Performance Computing
The drive for scale is very old in computing (i.e., there has long
been a quest to do more). More data, more analysis, more often.
These goals have ever been the elusive quarry of the computing in-
dustry and research scientists.
In the late 1970s and 1980s this led to rise of supercomputers
and attached vector processors, with Cray being preeminent in the
former and Floating Point Systems in the latter. During the late
1980s and early 1990s another persistent idea kept emerging: Can
this be done with large numbers of cheaper, even commodity
components?
Initially this led to a series of startups that built larger and larger
servers with multiple relatively cheap processors–These included Se-
quent, Masspar, Thinking Machines, and others. This was the initial
motivation for many entry level and mid-tier servers from many
companies. Eventually even many large-scale cloud server providers
claimed that they were using ‘‘commodity components’’ in some
sense (but that claim tended to be undercut by expensive internal
architecture, a discussion beyond the scope of this book).
In any case, the dream to build collections of large numbers of
commodity computers into a usable facility to solve large problems
finally took serious root in the late 1990s and the early part of the
next decade.
Because of this history, these systemstendedtobebatch-ori-
ented without much of a sense of either reliability or transactional
integrity—these were after all generally large computer problems—
and also complex for both developers and operational people. All of
these considerations were generally acceptable for several reasons:
First, it was fine for the problems in question; and second, the na-
tional laboratories, research institutions, and universities generally
had the personnel to deal with the complexity.
Since many of the infrastructures were either relatively rare or
expensive, over time there was a drive to create grids in which excess
capacity could be shared (with the name itself coming from the idea
ofpowergrids,whichareoftenusedasametaphorforpublic
clouds). Unfortunately while that seemed attractive at first, the grid
concept usually exacerbated the inherent operational complexity
and time predictability of these systems. As a result, these have
tended to only be useful for long-term scientific research questions,
60 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 61
such as searching for cures for cancer or intelligent life beyond
earth.
17
With the rise of cloud computing some of these efforts are
naturally focused on making themselves ‘‘cloud friendly,’’ and
are in various stages of progress in that effort. As a practical mat-
ter, some of the programming models and APIs
18
may make that
transition for the specialized research problems that they address
well, but most of the others will tend to be supplanted by cloud-
based technologies.
Virtualization/Server Consolidation
There are many forms of virtualization, yet all forms share a com-
mon characteristic: They provide some level of insulation, of inde-
pendence, of . . . well, virtualization between a physical set of
resources (such as a server, or a network, or a storage array) and the
ordinary consumers of those resources.
For example, in server virtualization many operating systems can
each run on a single physical server at the same time, each thinking
that a physical machine entirely to itself. They can each go about
their business blissfully unaware that other operating systems
are each going about their business, with none interfering with an-
other, even though none of the operating systems (and the applica-
tions that run upon them) were designed to cooperate with each
other.
In this way an enterprise can, for example, take many small
physical servers (typically scattered both physically as well as orga-
nizationally, almost always running at low utilization rates) and
consolidate them onto a smaller number of servers, usually cen-
trally located and managed. This is called server consolidation,
and has been helpful in battling server sprawl, a bane for many an
enterprise. Server sprawl is discussed in more detail later in this
section.
Cost savings vary, of course, but can be meaningful (on the or-
der of 20% to 50%) when compared to non-consolidated infra-
structure. Some of these savings come from reduction in capital
and operational expenses that can accrue due to the reduction in
numbers of servers, and some come simply from the reduction in
labor costs. Note that these reductions are partially reduced by the
costs of the virtualization technology as well as its impact on the
The Neighborhood 61
E1C03 02/21/2010 Page 62
computing infrastructure, and the tendency to acquire larger serv-
ers to support consolidation.
As with anything there are limits to how much this helps. While
no change is needed either to the operating systems or the applica-
tions that run upon the virtualized servers, the virtualization layer
does nothing to help the applications either—they remain precisely
as they were, no better and no worse. If the applications already had
scalability and reliability problems before, then they still have those
same scalability and reliability problems after.
19
The same can be said of the early forms of application virtualiza-
tion, in which an application can be easily moved about from one
server to another (either physical or a virtual server instance, a
‘‘slice’’ of a physical server). While this adds a bit of flexibility, it
does not help much when a spike in demand requires an applica-
tion to scale . . . and scale . . . and scale, nor does it help, for exam-
ple, when infrastructure failures cause the application itself to fail
and work in progress is lost.
There is also another problem that often begins to plague an
enterprise that has heavily invested in server virtualization: a phe-
nomenon known as server sprawl.Likekudzu,thatnoxiousweed
that grows more than 30cm each day,
20
server sprawl can quickly
dominate the operational landscape of an enterprise by adding
significant operational complexity. Added complexity nearly al-
ways mean added expense and reduced reliability and availability
(from an increase in the number of errors). Ironically this prob-
lem stems in part from the ease in which the server virtualization
layer enables users to create new server instances (much easier
than going through an acquisitionprocessandstandingupanew
server!), and partly from the inability of many applications to
safely coexist with each other on the same server (this is itself a
form of dependency).
So how does all this relate to cloud computing?
Imagine an enterprise that has invested heavily in virtualization
of every traditional form, and has developed both the technological
expertise and the operational knowledge to use all that technology.
They are able to move applications around the physical infra-
structure easily, and are able to provide a measure of elasticity (the
flexibility to scale up and down with changes in demand) for the
best applications.
62 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 63
By taking a couple of key steps they will be able to create a pri-
vate cloud, itself easily expandable to a hybrid cloud (thus gaining
the option of utilizing public cloud resources as well). In particular,
if the enterprise takes these steps:
Implement a cloud application platform (aka PaaS). This ena-
bles all of the infrastructure (physical and virtual) to appear
to be a single, albeit exceedingly high capacity and reliable
server/mainframe; to operate itself, adapt to failures and
changing load; and to be provisioned either by an application
or simply by a web request (self-service capabilities).
(Optionally) select one or more public cloud providers.
Gradually shift the physical infrastructure to a larger number
of smaller, cheaper, essentially disposable servers with fewer
variations–in other words, stick with one or two simple, cheap,
commodity ‘‘servers.’’
Simplify and adapt supporting business and operational
policies.
With these steps, the enterprise will have made the transition
and will be able to gain the cost, elasticity, scalability, reliability, and
other benefits of a cloud-computing technical infrastructure.
This is a high-level view. For more detail on moving an existing
IT environment to a private/hybrid cloud, see Chapter 5, Cloud
Adoption Lifecycle, and Chapter 7, Where to Begin with Cloud
Computing.
There is an interesting caveat to this example. In yet another
ironic twist, when an enterprise decides to take the steps to go
from virtualization to a private cloud, the original server virtualiza-
tion technologies become unnecessary over time. It is true that
they may continue to be used and add some value (providing an
additional sense of isolation between the cloud application plat-
form and the physical commodity servers), but it is also true that
the much greater sense of virtualization (all of the underlying phys-
ical and virtual server instances look and act like one single ginor-
mous [extraordinarily large] server/mainframe, albeit the most
reliable one ever seen) completely supersedes the earlier server
and application virtualization layers. Consequently, the enterprise
is free to do without those earlier layers as well, freeing those
The Neighborhood 63
E1C03 02/21/2010 Page 64
investments for redeployment, and increasing the efficiency of the
infrastructure investment.
Datacenters
Is cloud computing the harbinger of the end of the enterprise
datacenter?
Among the most ardent proponents of public cloud comput-
ing, the answer to this question is a foregone conclusion: ‘‘yes/of
course/absolutely/etc.’’
21
The thinking generally runs along
these lines: In the transition to a cloud-based infrastructure, the
economies of scale and expertise derived by the largest providers
will dwarf those of even the largest enterprise, making the transi-
tion inevitable and making those who resist seem like modern-day
Luddites.
However, while public clouds will have a significant role for most
enterprises, they are unlikely to completely dominate for several
reasons:
It will become easier to build private, community/vertical, and
hybrid clouds. This is primarily due to the advent of PaaS, pre-
packaged commodity hardware (including racks, pods, and
containers), and so forth. This will become even easier as
more applications become more ‘‘cloud native.’’
Security, continuity, control, and other business require-
ments may dictate other than public clouds in particular
circumstances.
Location, location, location. Latency—the amount of time it
takes for data to travel from where it is to where it needs to be
consumed—will become an extraordinarily significant consid-
eration, particularly as technical infrastructures transition to
cloud (since it will become progressively easier to geograph-
ically disperse infrastructure).
Culture. There are particular organizational cultures which
will favor more direct control of infrastructure for the foresee-
able future. Right, wrong, or indifferent, this is simply a fact.
Rather than have a non-productive argument bordering on the
dogmatic, we suggest that since the new class of cloud application
64 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 65
platforms will make this discussion essentially moot, a more produc-
tive approach is to simply realize that each organization will do as it
sees fit, and deal with it.
In any case, we believe that a mix along these lines is more likely
over the next few years:
Startups have already almost entirely made the transition, and
at least initially nearly always begin on a public cloud of some
sort.
Small to medium businesses will gradually make the transition
to a mostly public cloud infrastructure. While in a sense they
have the most to gain, small to medium businesses are also the
most dependent on applications and technology providers to
enable the transition.
Large enterprises will tend towards hybrid clouds, utilizing
public, private, and community/vertical clouds as appropriate.
Public clouds will begin to play a significant role in the enter-
prise landscape and that role will expand.
Civilian government agencies will transition relatively aggres-
sively to public cloud providers.
Defense and intelligence government agencies will tend to pri-
vate cloud almost entirely, though at those scales the secure
community/vertical clouds will effectively be their own public
clouds.
In other words, as all of the cloud choices mature (albeit with
different characteristics) then it is only natural that organizations
will do what is in their own best interest.
Datacenters will continue to exist, though over time the private
clouds will increasingly resemble their public counterparts: Simpli-
fied but at larger scale, with more consistent, modular, even con-
tainerized commodity components tied together with functional
cloud application platforms that will enable greater interoperability
and therefore choice.
Managed Services
This industry originated from very simple beginnings, as an option
for locating physical infrastructure someplace other than a facility
The Neighborhood 65
E1C03 02/21/2010 Page 66
already owned by the enterprise. Over time what have now come to
be known as managed service providers began moving up the stack,
and now offer a wide variety of operations, provisioning, network,
and other services, all primarily targeted at enterprises of various
forms. As such, many of the offerings also reflect the limitations of
the current, dominant enterprise IT ethos: difficulty in scaling of
both individual applications as well as aggregate capacity, sluggish
response to change, uneven reliability, smothering complexity, and
so forth.
As you might expect that is beginning to change, with the trans-
formation beginning to a new ‘‘cloud ethos for the enterprise,’’
one driven by the notion of self-service—that is, capacity available
ondemand,attherequestofthecustomer,flexiblymovingup
and down.
This is naturally beginning with the infrastructure (Infra-
structure as a Service [IaaS]), and will gradually move up the stack.
Next stop will be the platform (PaaS).
This evolution has and will continue to loosely track the evolu-
tion of the enterprise datacenter, with the general opportunity to
provide the whole spectrum of enterprise-friendly clouds—private,
public, vertical/community, and hybrid.
Parting Thoughts
In this chapter we have touched only on the highlights, of course. A
full accounting of the existing information technology landscape
and the effect of cloud computing upon it would require an entire
volume of its own, or perhaps several. Still, it is our hope that this
overview has given you a sense of the transformation in progress,
and at the same time highlighted some of the more important
aspects.
In the Darwinian Evolution of Species sense, this is the new, supe-
rior species, the pervasive mammals—as opposed to the lumbering
stegosaurus and kin that are unable to adapt to a landscape that has
changed unalterably.
Some of the existing players in the landscape will adapt, some
will thrive, others will struggle but remain (perhaps in a diminished
role), yet none can remain as they were before.
This change is underway at this very moment—and that is good
news, very good indeed.
66 Cloud Computing and Everything Else
E1C03 02/21/2010 Page 67
Notes
1. Many will agree that at least web services, if not a full service-oriented architec-
ture, are part and parcel with cloud-computing applications.
2. Such as Common Object Request Broker Architecture (CORBA).
3. As an example see the ‘‘Web Services Standards Overview’’ poster created by
innoQ, www.innoq.com/soa/ws-standards/poster/
4. For example, all of these standards created a number of dependencies be-
tween components, which tended to make applications less flexible and more
brittle (error prone) than necessary. This is the exact opposite of the broad
trend toward less dependence.
5. Representational State Transfer, an architectural style first proposed by Roy
Thomas Fielding in his PhD dissertation ‘‘Architectural Styles and the Design
of Network-Based Software Architectures,’’ University of California Irvine,
2000.
6. Tim O’Reilly reporting on a conversation with Jeff Barr, Chief Web Services
Evangelist, Amazon in his blog post REST vs. SOAP at Amazon, www.oreilly-
net.com/pub/wlg/3005
7. While the WS-protocols and SOAP really are a set of standards, ReST is really
more of an ‘‘architectural style’’ that makes uses of existing web standards in a
particular way. Having said that, for most common web services it really comes
down to choosing WS-and SOAP versus ReST—it is in this sense that some
people talk about ‘‘de facto standards’’ . . . that is, in the sense that ‘‘ReST is
what most folks are actually using for their web services.’’
8. Some point to the first O’Reilly ‘‘web 2.0’’ conference held in October 2004 as
the beginning of widespread acceptance of that term. For an excellent summary
of first year web 2.0 thinking see What is web 2.0, Tim O’Reilly, September 30,
2005, http://oreilly.com/web2/archive/what-is-web-20.html
9. ‘‘Mash-up’’ emphasizes the experimental nature, as well as the fact that many
of the combinations were not anticipated by the creators of each individual
service.
10. Websphere from IBM, Weblogic from BEA (now part of Oracle Corp.), and
JBoss (now part of RedHat); the Net servers from Microsoft.
11. Appistry, whose mission is to create cloud application platforms (aka Platforms
as a Service, or PaaS), the successor to the classic application server.
12. These included Spring and Guice, among others.
13. Apache Tomcat, an open source, lightweight web server.
14. S. Pinchikula, ‘‘Tomcat Used By 64% of Java Developers,’’ InfoQ, December 3,
2007.
15. At least not in the near to mid term—operational inertia is a strong factor, as
are cultural norms within the enterprise.
16. See Chapter 9 for a more in-depth discussion of the considerations.
17. Examples include the search for a cureforcancerattheWorldCommunity
Grid (www.worldcommunitygrid.com) and the Search for Extraterrestrial
Intelligence project (known as SETI@home, http://setiathome.berkeley
.edu/)
18. Such as the Nimbus effort from the Globus Alliance, http://globus.org/
Notes 67
E1C03 02/21/2010 Page 68
19. Reliability is often confused with availability, particularly by vendors who are not
truly reliable. While swapping a virtual machine to a new physical machine
when the original physical machine breaks may provide great availability (and
may be sufficient for some applications), it does not help with the work that
was lost when the first physical machine failed—that would require reliability,
which would ensure that work in progress at the time of failure is automatically
completed elsewhere.
20. McClain, ‘‘The Green Plague Moves North,’’ OutdoorIllinois,VolVIIINo2,
February 2000.
21. Two prominent examples come to mind. In The Big Switch (Norton, 2008),
Nicholas Carr makes this point emphatically from a macro-forces perspective;
and in his ‘‘Red Shift’’ work Greg Papadapoulos (Chief Technology Officer of
Sun at the time) went so far as to say that this consolidation would continue
until only five computers remain in the world.
68 Cloud Computing and Everything Else
E1C04 03/02/2010 Page 69
4
CHAPTER
Strategic Implications
of Cloud Computing
With the hype of cloud computing dominating the current in-
formation technology (IT) landscape, much as service-oriented ar-
chitecture (SOA) did six years ago, we should stop and take a
breath and remember the reasons why SOA was positioned as a criti-
cal business and IT initiative then. The promise of SOA came from
the desire to enable business agility and flexibility, and at the same
time achieve reduced application maintenance costs and faster time-
to-market, drive savings and cost avoidance through service reuse,
and cut into the 20–30% integration burden most companies spend
today. These are typical SOA value drivers, and they still remain
valid. However, based on the overhyping of SOA, the challenge to
live up to those overinflated expectations has been enormous. SOA
has not failed as a business, IT, and architectural strategy, but it has
failed to live up to the claims and expectations that were hyped.
Could any technology live up to those expectations?
However, take a look at the ‘‘typical’’ benefits of cloud comput-
ing, and you begin to feel as if you have seen part of this movie be-
fore. Many of the target benefits of cloud computing are the same
ones we began our SOA initiatives to achieve: agility, flexibility,
faster time-to-market, and cost savings. Fortunately as we have seen
in Chapter 1, The Sound of Inevitability, the forces that drive this
transition run very deep indeed and demand to be understood.
In this chapter, we develop and explore the strategic implica-
tions of cloud computing and what this significant business and
69
E1C04 03/02/2010 Page 70
technology trend means to a business executive. There are many
strategic, financial, and operational implications of cloud comput-
ing that must be understood as this trend becomes a mainstream
componentofthechiefinformationofficer’s(CIO’s)toolkit.We
will address them here.
A Survey of Cloud Implications
The economic meltdown of 2008–2009 caused significant uncer-
tainty in the business world, and had an especially poignant impact
in IT investments that were more discretionary. This intense eco-
nomic downturn dampened many firms’ appetites for complex
transformational initiatives, such as SOA, in favor of more concrete,
bottom-line-oriented initiatives, which means cloud computing to
many IT executives.
Much of the limited discretionary spending has been sprin-
kledoverafewopportunities,butitwasnotenoughtohaveasig-
nificant impact on business or IT operations. Discretionary
spending tends to be focused on strategic investments, research
and development, and IT innovation initiatives. However, as we
all have seen, an economic blip usually crushes all discretionary
budgets across the board, including IT discretionary budgets.
Therefore, all non–business sponsored IT initiatives tend to be
pruned back or cancelled, and IT innovation ceases until the next
economic upturn. IT innovation and transformation efforts in-
clude initiatives such as SOA (if not sponsored by the business),
and other technology explorations and research and develop-
ment efforts, such as understanding effective utilization of cloud
computing, mobile applications, web 2.0, social networks and re-
lated technology trends. Without business sponsorship, these ini-
tiatives will have no support in a difficult economy.
However, technologies with high potential for rapid return on
investment will start or continue to be pursued. Cloud computing
falls into this category. The combination of business value potential,
industry buzz, and a sour economy have made cloud computing a
very relevant focus for business and IT executives. Cloud computing
offers a very potent combination of business agility, rapid time to
market, and IT cost savings that can be realized quickly for aspects
of your business. That is why cloud computing is compelling to busi-
ness and IT executives. The troubled economy has reprioritized IT
70 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 71
initiatives, and cloud rose to the top of the stack. Cloud offers an
opportunity to deliver tangible, hard dollar savings to an organiza-
tion by reducing IT operations costs and personnel costs associated
with internally owned datacenters.
Strategic Business and Financial Implications
The challenging economy made the cloud computing conversation
especially relevant. The business and financial potential of cloud
makes it a special trend for us to embrace. We will delve deeper into
the full range of business and financial benefits later. The strategic
business and financial implications of cloud are the focus of this
section.
First and foremost, with cloud computing, we have another ave-
nue for realizing business agility, the Holy Grail of all business strat-
egies. As with all technology trends, business agility is probably the
most frequently mentioned goal of business and technology execu-
tives when they describe their strategies, and yet it remains the least
realized in terms of execution. We could even go so far as to say that
a clearly articulated business or technology strategy that can deliver
on that promise, that is clearly articulated, and has been incorpo-
rated into daily operations can seem as elusive as any mythological
beast. Fortunately, this opportunity truly is different.
Cloud computing offers business agility in a simple, clearly un-
derstandable model: For a new startup or for emergent business
requirements of established enterprises, cloud computing allows an
organization to implement a rapid time-to-market model by securely
accessing a ready-to-use IT infrastructure environment, hosted and
managed by a trusted third party, with right-sized, scalable comput-
ing, network and storage capability, that we pay for only as we use it
and based on how much of it we use. Hmmm, let me think about
this a while . . . NOT!!!
We do not have to build or expand our data center (no con-
struction of buildings, raised floor, energy and cooling equipment,
building automation and monitoring equipment, and no staff); we
do not have to buy any hardware, software, or network infra-
structure (no dealing with the procurement hassles we are so accus-
tomed to, especially with the inevitable delays in IT acquisition); we
can rapidly implement a new business model or start a new com-
pany to address a new market need far faster than we normally
A Survey of Cloud Implications 71
E1C04 03/02/2010 Page 72
could have; and we do not have to continue to pay for the cloud
infrastructure and resources if we discontinue the project or if the
company fails. From a business and IT executive’s perspective, what
is not to like about this business vignette?
There are countless new startup firms that have leveraged cloud
computing models to obtain their IT infrastructure as a service,
therefore enabling them to focus their limited funds and resource
bandwidth on their unique technology and business model innova-
tion. Resource constraints are liberating in this sense, since they
force new startups to leverage ready-to-use cloud resources as op-
posed to building a data center.
These types of scenarios, of course, raise a number of business
and financial implications that must be explored further.
Convert Fixed Costs to Variable Costs
First, cloud computing offers a business executive the opportunity
to convert what have traditionally been significant fixed costs
of owning and operating a data center into a variable cost, paid only
bythevolumeofITresourcesthatareactuallyused.Datacenter
costs are paid up front, but are capital from an accounting perspec-
tive, where the physical assets are depreciated over their useful lives.
Thus, data centers are fixed costs in that the expenses paid monthly
will be relatively fixed compared to business volume.
Fixed costs are expenses that stay relatively constant regardless
of the level of sales. For example, the cost of renting a corporate
headquarters is likely to be a constant amount (say, $100,000 per
month) regardless of how much revenue the company generates.
Data centers, and the computing resources, cooling and energy
management equipment, and supporting building automation and
physical security equipment contained therein, are considered fixed
costs, are treated as capital expenses in accounting terms, and are
depreciated over their useful lives per generally accepted account-
ing principles (GAAP) rules. For the purposes of quarterly or an-
nual accounting, the monthly expense for data centers will be a
fixed cost, or the same quantity of expense, regardless of how effec-
tively it contributes to or supports revenue volume. So, if sales are
down, you still have to pay the same fixed costs. If your sales are up,
you have the same fixed expense obligations.
72 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 73
Variable costs, however, vary with the amount of output or sales
that is generated. Examples of common variable costs include raw
materials, packaging, and labor directly involved in a company’s
manufacturing process. These costs vary with the amount of output
and/or sales volume a company generates. More sales, more varia-
ble costs, but they are aligned with sales and output volume. Less
sales or output, the less your variable costs will be. Cloud computing
models, based on the pay-as-you-go model offered via utility comput-
ing benefits, means that the expenses associated with cloud-pro-
vided resources, e.g. IT infrastructure, platforms as a service (Paas),
software as a service (SaaS), vary more directly with your output or
sales volume, and you can add or reduce capacity based on sales vol-
ume or output volume. Thus, cloud computing expenses to a cloud
consumer are a variable cost instead of a fixed cost. From a cash flow
and financial perspective, converting fixed costs into variable costs is
far better for the enterprise. Cloud computing is especially attractive
in enabling this fixed cost to variable cost conversion benefit.
Cloud Delivers Superior Return on Assets
Cloud computing potential to deliver a superior return on assets
(ROA) to the enterprise than the ROA of an organization that owns
and operates its own data centers. ROA is an indicator of how profit-
able a company is relative to its total assets. ROA tells you what the
company can do with what it has (i.e., how many dollars of earnings
they derive from each dollar of assets they control). Companies that
require large initial investments in physical assets will generally have
lower return on assets.
ROA ¼ðNet Income Interest Expense
Interest Tax SavingsÞ=Average Total Assets
Consider two internet startups, each with a $20 million tranche
of venture capital. StartCo1 invests in a small data center, comput-
ing infrastructure, staffing, power and cooling equipment, which
costs $5 million. Instead leverages a third-party cloud for its IT infra-
structure, costing it $750,000 annually. Each has $3 million in reve-
nue in year one, with a net income of (–$2 million. The calculations
for ROA for each of these startups are below. For the purposes of
A Survey of Cloud Implications 73
E1C04 03/02/2010 Page 74
this ROA example, we assume interest expenses and interest tax sav-
ings are zero.
StartCo1 ROA calculation ¼ð$2;000;000=$5;000;000Þ¼4
StartCo2 ROA calculation ð$2;000;000=$750;000Þ¼0
A higher ROA value indicates superior return on assets. Thus,
the calculation above illustrates that StartCo1, with a ROA of -–4.0
or minus four, has a poor ROA relative to StartCo2, with a ROA of
0.0, or zero.
The ROA calculation provides insights into how efficient busi-
ness management is at using its assets to generate earnings. ROA is
calculated by dividing a company’s annual earnings by its total
assets, and is displayed as a percentage. Data centers and IT infra-
structure are treated as a firm’s assets, and thus will impact the ROA
calculation. Under a cloud strategy, the data centers are owned and
operated by an external third party, while the revenue generated
from a cloud-based business model is yours. Thus, the ROA calcula-
tion clearly confers a benefit to the enterprise leveraging a cloud
model.
Cloud computing helps reduce IT costs by offloading data cen-
ters, IT operations staff, and related costs to third-party cloud pro-
viders. While a small percentage of overall corporate expenses, this
still contributes to a better allocation of capital toward strategic
business and IT requirements. However, as we will see, there are a
range of compelling business, information technology, and strate-
gic benefits of cloud computing. Adoption of cloud computing is
not a one size fits all proposition. Rather, cloud will offer different
value propositions based on your particular business requirements
and technology foundation, and the specific types of cloud re-
sources your firm requires. Cloud is much more than outsourcing
allorportionsofyourITinfrastructuretoathirdpartycloudser-
vice provider.
Business Agility and Faster Time to Market
Cloud computing offers a new pathway to business agility and faster
time to market by offering ready-to-consume cloud-enabled re-
sources, such as IT infrastructure, software platforms and business
applications, that can be accessed and operated in support of a new
74 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 75
business requirement far faster than acquiring, installing, configur-
ing and operating these IT resources on your own. For the business
executive, cloud means the ability to quickly get a new business
model to market without the typical IT procurement delays, infra-
structure engineering and configuration management needs, and
software configuration and maintenance requirements. Instead, the
business defines its computing, storage, network, platform and ap-
plication resource requirements; goes to a third-party cloud pro-
vider; and obtains the necessary resources with a credit card
transaction. The resources will be available within hours, as opposed
to weeks and months.
There are many scenarios where cloud makes perfect sense for a
business executive. Often, new business model concepts are tested
and piloted on a limited basis in order to wring out the kinks and
nuances of a new business model or limited aspects of a new busi-
ness strategy. Many times, speed to market is a major driver of a new
business model innovation, and along with that comes security and
intellectual property protection. The longer you wait to launch, the
sooner critical trade secrets can fall into the hands of your competi-
tion. For a business executive, cloud provides a means to conduct
limited scope business-model experiments to pilot a new service or
product, quickly and securely, without having to conduct normal IT
acquisition of hardware, software, and network infrastructure. As
the business model innovation proceeds, and if it is successful,
cloud offers a scalable on-demand model to add new capacity pre-
cisely as it is needed, no more and no less. If the business model
pilot is cancelled, the cloud capacity is relinquished, and you stop
paying for the cloud resources immediately. If you had acquired the
IT infrastructure to support the new business model construct, you
would still be paying for it, and you would still have the capacity—
probably unused capacity—going forward. Excess capacity is waste,
both in hard dollar terms, physical computing and storage terms,
and in manpower and IT human resources terms.
The business agility and rapid time-to-market value of cloud is
particularly attractive as a means to respond to new markets quickly,
to innovate and test new business model concepts quickly, and to
offer new startups a rapid model to go to market without up-front
costs and time delays in acquiring and operating IT infrastructure.
These are all reasons why a business executive should care about
cloud. The strategic implications are clear.
A Survey of Cloud Implications 75
E1C04 03/02/2010 Page 76
Information Technology Benefits of Cloud Computing
The IT benefits of cloud computing are significant as well—at first
blush, however, IT executives will blanch at the idea of more out-
sourcing of IT capabilities, in this case IT infrastructure to cloud
providers. However, that perspective is a very narrow one, and does
not consider the strategic value of clouds in the strategic context of
the overall business enterprise. Cloud offers a way to increase IT re-
source and capacity utilization, which are historically very low in pri-
vately-operated datacenters of large enterprises, usually in the low to
mid teens (15%). Often, the dramatic underutilization of datacenter
resources—especially computing, storage and network resources—
are caused by stovepiped system-based acquisition of dedicated IT
infrastructure, scoped for peak loads anticipated under best case
estimates for a new business application. There are two fundamental
problems with this model: (1) a business application project team
usually acquires its own dedicated IT resources, which are explicitly
not meant to be shared with other business applications or by other
business units; and (2) the estimated peak utilization of the comput-
ing, storage and network resources is almost always too optimistic,
meaning that too much capacity is acquired and installed, and most
of the available capacity is never utilized.
These two factors are why virtualization technologies have be-
come mainstream today. At least by leveraging virtualization con-
cepts, an enterprise can acquire less computing hardware initially
(usually inexpensive commodity blades), virtualize these computing
resources for the initial application requirement, and still leverage
the remaining excess capacity for other computing needs by others
in the enterprise. Cloud applied in this model offers clear IT savings
in optimizing infrastructure spending across multiple application
project requirements, rather than acquiring dedicated servers and
storage for application stovepipes that are inherently not intended
nor designed to be shared and leveraged by others.
While the IT cost savings are clear in the scenario above, there
are broader IT implications with cloud computing, as described in
the list below:
Optimize IT Costs. Cloud can reduce a portion of IT opera-
tions costs. Through judicious leveraging of cloud service pro-
viders to offload portions of IT infrastructure costs, a
76 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 77
combination of IT savings and business enablement can be
achieved. Cloud should not be pursued strictly as a cost-sav-
ings initiative, although cost is most certainly a core driver of
the cloud push today. Cloud savings must be balanced by
some degree of business enablement or business assurance in
order to justify pursuing a cloud strategy.
Time Compression of Go to Market Models. Cloud offers time
compression of time-to-market for key business initiatives. We
feel this is a key driver for adoption of cloud computing en
masse. Time compression of time-to-market is critical for new
business initiatives where a novel innovation must be
launched quickly, without long lead times, in order to capital-
ize on its market potential. Cloud offers an ideal business ca-
pability platform to market in a dramatically time-compressed
fashion. Time-compression helps avoid intellectual property
leakage, competitive advantage erosion, and loss of market po-
tential through product launch delays due to IT acquisition
delays, internal organizational friction, and related factors.
Inexpensive Access to New Business Applications. Cloud
offers the ability of the IT organization to evaluate, access and
provide business applications to its business customers quickly
and inexpensively via the Software as a Service (SaaS) Cloud
pattern. Cloud-enabled SaaS-based applications have low start-
up costs, low monthly access fees, and eliminate the need to
acquire and install hardware, software, network and storage
capacity typically required for the very same application on an
enterprise license basis.
Reduced Maintenance of IT Infrastructure and Applications.
Another IT benefit of cloud involves the reduced mainte-
nance for applications and platforms (SaaS and PaaS, Plat-
form as a Service) that are accessed via the cloud on behalf of
the IT organization’s business customers.
Business Alignment of IT resources. Cloud supports better
alignment of IT resources to business needs by focusing these
valuable enterprise assets on competitive advantage and stra-
tegic initiatives rather than commodity IT requirements.
IT Resources Deployed in Support of Competitive Advantage.
Furthermore, an appropriate cloud strategy will leverage
cloud as a competitive advantage enabler, which means that
resources focused on pursuing cloud for competitive
A Survey of Cloud Implications 77
E1C04 03/02/2010 Page 78
advantage purposes will have clear alignment to the needs
of the business.
Also, the strategic implications of cloud for the CIO rest in the
ability of the IT organization to offer cloud capabilities to its busi-
ness customers and truly be a force for faster time-to-market for new
business applications. The IT organization should develop either an
internal private cloud that can be applied to multiple business sce-
narios, or develop the relationships with multiple external cloud
service providers to be able to quickly provision cloud resources to
enable specific business application requirements. Developing in-
ternal, private cloud capabilities is a significant research and devel-
opment effort, and must be pursued with care and with the full
support of business leadership to invest in such an internal project.
However, the private cloud offers immediate cost savings through
server consolidation, staff realignment, and better asset utilization.
In the public third-party cloud scenario, the IT organization
must still perform research and development in order to under-
stand the types of cloud providers and their capabilities, and to de-
velop key relationships with a few trusted cloud providers to which
they will offload portions of their IT infrastructure over time.
In all of these scenarios, the IT organization can leverage cloud
computing to drive cost and resource optimization internally to the
IT function, increase business support by introducing cloud-
enabled business capabilities to the business, and support competi-
tive advantage by leveraging various cloud patterns to best support
the strategic direction of the business.
Business Benefits of Cloud Computing
Cloud computing offers significant benefits for the enterprise in ad-
dition to agility. The additional benefits from cloud computing
include:
Reduced/Optimized IT Cost. Cloud computing offers a way
to reduce IT infrastructure costs through a combination of
capital expense avoidance, pay-as-you-go capacity, better uti-
lization of virtualized commodity computing capacity, and
reduced operational costs by requiring fewer internal IT
resources to focus on commodity infrastructure needs.
78 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 79
Furthermore, cloud patterns that focus on PaaS, SaaS, and
using Cloud operating systems platforms as replacements for
conventional application server and middleware needs will
realize great potential for IT cost savings. Overall, the accu-
mulated cost savings from cloud can become significant,
especially for firms that avoided investing in data centers
and related IT fixed costs to begin with. As larger enterprises
begin to transition larger portions of their enterprises to
cloud, there will be a dramatic decrease in IT costs, with a
corresponding increase in business agility and rapid time-to-
market.
Better Asset Utilization (Infrastructure). Cloud computing lev-
erages infrastructure virtualization approaches that dramati-
cally improve server utilization, from the 10% current average
to 50–65% server utilization, and in some cases even higher.
The same asset utilization improvement opportunity applies
to storage virtualization as well. Better asset utilization reduces
IT costs by reducing fixed cost overhead, maintenance costs,
and IT operations staff required to run and manage a datacen-
ter. Recall that return on assets, or ROA, is an indicator of su-
perior use of assets to drive business value.
Better Asset Utilization (People and Skills). Cloud computing
allows you essentially to outsource your IT infrastructure, plat-
form middleware, and application infrastructure, depending
on your cloud needs, to a third-party firm. This means you can
focus your precious IT staff on more strategic and innovative
enterprise requirements. This is a far better use of corporate
people skills and knowledge, and offers a greater return on
your people assets.
Pay-as-You-Go Model. A key feature of cloud computing is its
on-demand utility nature, whereby computing, storage capac-
ity, or application resources are consumed only when needed,
and you pay only for what you use when you use it. If you no
longer need the cloud-enabled resources, the capacity is re-
leased back to the cloud pool for others to draw from. This
helps align computing and storage demand with business
needs, and unused capacity will not sit idle as a capital
expense, paid for whether it is utilized or not.
Convert Fixed Costs into Variable Costs. A related and power-
ful benefit from cloud computing is the ability to convert what
Business Benefits of Cloud Computing 79
E1C04 03/02/2010 Page 80
were formerly fixed costs into variable costs, which are only
paid by actual usage based on internal business demand. This
is a powerful concept that has significant financial and opera-
tions benefits for IT and business executives.
Bypass Slow IT Acquisition Processes. Cloud computing mod-
els offer a means to quickly add operational IT infrastructure
in hours/days, versus weeks/months, by enabling innovation
projects to bypass often slow and arduous IT acquisition and
procurement processes and quickly put into production new
business capabilities. This rapid time-to-market model will be
one of the major reasons companies will quickly adopt cloud
computing. Corporate acquisition processes are so laborious
and slow that any approach that enables low cost IT infra-
structure services in an accelerated time frame will be warmly
embraced. Eventually, IT acquisition processes will be ‘‘cloud-
enabled,’’ meaning that they will provide acquisition pro-
cesses and governance to explicitly support cloud computing
resource acquisition models.
Easy Onramp to IT Infrastructure for Startups or Innovative
Business Ventures. For startup firms that do not have the capi-
tal to acquire IT infrastructure to enable their business mod-
els, the benefits are similar: less capital expense up front,
and easy onboarding into an already-operational IT infra-
structure, which lets the startup focus on its unique differenti-
ated business model. For larger enterprises launching new
innovation projects, cloud computing allows a very rapid time-
to-market to test new business models, and avoids the need
to acquire, install, configure, operate, and maintain dedicated
IT infrastructure.
Innovation Enabler. Cloud offers a way to create more innova-
tion both within the business and within IT organizations.
With pre-integrated IT infrastructure, cloud-enabled plat-
forms, and business applications available in modular, pay-as-
you-go pricing models, cloud invites organizations to leverage
various cloud deployments onbehalfofnewbusinesscon-
cepts, IT research and development, product and process in-
novation, and more.
Market Response Tactic. Cloud can become an integral ele-
ment of an organization’s market response process. As an
organization monitors the market, its customers, and its
80 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 81
competitors, cloud computing can become part of the overall
response framework to address emergent competitive threats,
emergent customer needs, and spot markets in different geog-
raphies. Cloud can become a standard tactic to respond to
these emergent competitive circumstances, in addition to be-
ing a preemptive platform for attacking the competition.
Procurement Accelerator. Cloud offers a way for business and
IT leaders to quickly gain access to various cloud-enabled re-
sources—IT infrastructure, platforms, business applications,
and others—already installed, configured and ready to con-
sume—simply with a credit card transaction. The procure-
ment avoidance and/or procurement acceleration benefits of
cloud are, in our opinion, one of the major reasons cloud will
become a force for good in large enterprises. One of the most
often cited challenges in large organizations is the IT procure-
ment process, which almost always imposes serious delays
upon projects due to the slow acquisition and procurement
processes necessary to acquire IT infrastructure. We urge IT
organizations to embrace cloud service providers to help ac-
celerate the procurement process, as opposed to going
around your internal procurement process. We all know of
instances where project teams have avoided internal procure-
ment processes precisely due to their slowness. Cloud offers a
way for procurement to become part of the solution. Cloud
solutions can provide standardized IT infrastructure rapidly
within your enterprise (within certain procurement thresh-
olds to avoid abuse).
Business Experimentation Enabler. Cloud offers a platform
for business experimentation, risk mitigation, and innovation
enablement. The cost equation of conducting business model
exploration changes dramatically when fixed IT costs and IT
support costs are a much lower proportion of the overall costs
for business model innovation. Again, many forms of cloud-
enabled resources fit this model, from infrastructure as a ser-
vice (IaaS), to pure-play cloud enablement platforms or oper-
ating systems, to platforms as a service (PaaS) to software as a
service (SaaS). Regardless of the specific combinations of
cloud-enabled resources you are exploiting, they become part
of an overall approach to business experimentation and inno-
vation that becomes possible via the cloud.
Business Benefits of Cloud Computing 81
E1C04 03/02/2010 Page 82
Cloud computing, as we have shown, offers a range of business
benefits. Regardless of the value you hope to realize from cloud
computing, you must nevertheless focus your efforts on business
opportunities where cloud computing makes sense for you, where
risk can be mitigated and/or controlled, and where you can really
deliver business value through the adoption of cloud-enabled
resources.
Cloud-Based Business Models
A cloud-based business model isanewbusinessmodelthatis
entirely envisioned, enabled, and realized based on a cloud-comput-
ing capability. A cloud-based business model is thoroughly realized
by leveraging cloud computing concepts, technology, and revenue
models to execute the envisioned business-model concept. Cloud-
based business models may apply equally to both cloud consumers
and cloud providers. A cloud provider business model is based on the
development of cloud enablement technologies and solutions. It in-
cludes the following solutions:
Acloud service provides the network and computing infra-
structure upon which cloud platforms and cloud solutions op-
erate. Service providers and cloud solution providers are similar in
that they both develop and provide cloud enablement services and
solutions to prospective cloud consumers to address their respective
business needs. CSPs include organizations that operate cloud-
enabled data centers, which provide preconfigured cloud de-
ployments to end-customers to address their cloud needs.
Acloud platform service provider (CPSP, e.g., Amazon.com, Goo-
gle.com, Salesforce.com, and others) provide cloud-based
platforms, hosted in a cloud-enabled infrastructure and cloud
operating system environment, such that developers can ac-
cess the platform, develop a new business application, and
then host that application on the cloud-based platform. Cloud
platform service providers are unique in that they have devel-
oped a complete application platform, hosted in a cloud,
which enables rapid application development on that plat-
form, while providing an ‘‘as a Service’’ deployment and host-
ing framework for the applications to be provided ‘‘as a
82 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 83
Service’’ through that platform, which is in turn hosted on a
cloud.
Acloud technology provider (CTP) develops the tools and tech-
nologies that enable cloud to be established and provided to
consumers of cloud-enabled resources. Cloud technology
providers provide the foundational enablement technology
for cloud computing. Cloud technology providers offer the
range of tools, technologies, middleware and Cloud operat-
ing system solutions that are needed to enable private clouds,
public clouds and hybrid clouds. CTPs provide the basic tools
that help end-users leverage cloud internally to an enterprise,
as well as enable, cloud service providers and cloud platform
service providers to deliver cloud-based solutions. VMware is
an example of a cloud technology provider, as is Appistry,
3tera, Eucalyptus and a host of others.
Acloud solution provider develops entire suites of cloud capabili-
ties to provide to a broad market of cloud consumers. Amazon
is a cloud solution provider in this taxonomy. System integra-
tors are cloud solution providers, or will become cloud solu-
tion providers, in this parlance.
Acloud consumer business model is an enterprise that strategically
applies cloud computing concepts to a significant portion of
its business, or to a completely stand-alone business unit, in
order to build in the inherent competitive advantages of cloud
computing.
Cloud-Enabled Business Models
A cloud-enabled business model is a business that leverages cloud
computing to enable specific aspects of its business model to gain
competitive advantage. This is particularly applicable to end-user
enterprises that apply cloud to their IT operations, or to new busi-
ness units that with new business models or new business processes.
A cloud-enabled business model differs in that the adopting or-
ganization is leveraging cloud on a narrowly defined and bounded
portion of its enterprise, and only insofar as cloud helps it drive out
costs or achieve time-to-market for a small segment of its operations.
In a cloud-enabled business model, cloud merely augments the pri-
mary business model concept already committed to by the adopting
Cloud-Enabled Business Models 83
E1C04 03/02/2010 Page 84
enterprise. A cloud-enabled business model is superior to one that is
not cloud-enabled, but is less sophisticated than a cloud-based busi-
ness model, which is a cloud pure play in terms of strategy defini-
tion, envisioning, and execution.
A cloud-enabled business model ‘‘layers’’ cloud computing
approaches onto its legacy business model to drive enhanced com-
petitive advantage, but again, the incremental competitive advan-
tage is a value overlay to the current business model concept. For
example, a manufacturing enterprise under competitive pressure
from China may leverage cloud to drive incremental costs out of it
current domestic headquarters and administrative operations
thereby lowering its IT costs. In addition, the same enterprise might
also leverage a cloud infrastructure to establish a new overseas man-
ufacturing site, leveraging contract manufacturing from several out-
sourced manufacturers but implementing its international hub
quickly through cloud enablement provided by third-party cloud
providers.
In both scenarios, the core business model is manufacturing of
goods, leveraging domestic and offshore manufacturing capabili-
ties. However, cloud-enabling this manufacturing business model
may provide the incremental margin necessary for profit, or to sup-
port research and development of new products to be manufac-
tured in the future.
Thefollowingaresomeexamplesofcloud-enabledbusiness
models where aspects of a business might be transitioned into a
cloud deployment to drive value for an existing enterprise:
Cloud-Enabled Supply Chain. A cloud-enabled supply chain is
a scenario where a large manufacturing enterprise elects to
push demand management, inventory management, and sup-
plier management into a cloud such that the information and
data can be globally managed virtually worldwide, while ensur-
ing authoritative, real-time reporting of stock levels, raw mate-
rials, work in process, and finished goods inventory. The value
of supply chain management in the cloud is being able to
manage massive amounts of data, in real time, from global
suppliers, manufacturing partners, and distribution and ware-
house management partners on the end-to-end supply chain.
Cloud-Enabled Sales and Marketing. Cloud-enabled sales and
marketing can benefit by aggregating lead generation, web
84 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 85
site contacts and customer inquiries into a globally-deployed
cloud to develop a worldwide view of business development
efforts, marketing program effectiveness, and customer feed-
back and interactions from global web site activities, help desk
and customer support contacts, all from call centers inte-
grated into the same cloud. A cloud-enabled sales and market-
ing operation can enable similar real-time operational pictures
of customer data to help react and respond to market signals.
Cloud-Enabled New Business Unit. A cloud-enabled business
can be entirely bootstrapped on a cloud-based platform to test
a new business model or expand an existing business into a
new geography without acquiring dedicated IT infrastructure
to support a highly prospective business venture. The risk pro-
file of starting new business ventures changes if it is not neces-
sary to acquire, implement, and maintain an IT datacenter to
support the new business. An organization can quickly
onboard its new business operations onto a cloud deployment,
managed by a cloud service provider, which can be quickly
ramped up based on actual business demand from the new
business, or ramped down if the business experiment does not
succeed. This application of cloud computing will encourage
more risk-taking with new business models, and should spur a
burst of new business innovation as a result of a much lower
risk profile for new business experimentation enabled by
cloud computing.
Cloud-Enabled Call Centers. In many ways this is a natural fit
with the recent evolution of associated call-center technolo-
gies, such as Voice over Internet Protocol (VoIP), which is in-
trinsically cloud resonant. A truly cloud-enabled call center
could be fully distributed and incremental, able to expand or
contract as demand warrants, in increments as small as one
agent at a time. In this manner this could enable call centers
to become even more responsive and efficient, in that infra-
structure costs can more precisely scale proportionate with la-
bor costs.
We have offered a few examples of cloud-enabled business mod-
els here. This is a small list, but your imagination is the only barrier
to imagining the ways in which an existing enterprise can leverage
cloud computing models to enable portions of a current business
Cloud-Enabled Business Models 85
E1C04 03/02/2010 Page 86
model to drive competitive advantage. As cloud matures, we expect
to see many variations of these concepts based on hybrid clouds that
blend the best aspects of private clouds applied internally to an
enterprise, while leveraging the raw potential of public clouds for
access to new markets, new distribution channels, and new products
and services.
Strategic Implications of Cloud Computing
Asymmetric Competition
A critical strategic implication of cloud computing is that it will ena-
ble a host of new asymmetric competitors to enter various existing
markets without an installed base of rigid IT infrastructure and leg-
acy applications that anchor them to their accumulated past invest-
ments. These new competitors will not have an installed base of
legacy applications, nor will they have fixed costs invested in physi-
cal data centers and related IT infrastructure. In fact, these new
asymmetric cloud-based competitors will not even approach busi-
ness problems the same way as their more established competitors.
This is the real threat: the mindset of a cloud-based asymmetric
competitor. Asymmetric competitors do not view IT infrastructure
and data centers as necessary because they have never had them,
nor have they ever needed them. IT infrastructure does not convey
competitive advantage to them, so they simply do not acquire it.
Moreover, they do not want it, as it limits agility and flexibility of the
business model more than anything else. The next generation of
cloud-based asymmetric competitors view IT infrastructure with dis-
dain and suspicion. They want nothing to do with any physical assets
that will hold their business models back.
Rather, these asymmetric competitors will compete on business
model differentiation and speed, and instead of building infra-
structure when they are larger more mature enterprises, they will
continue to leverage the variable cost model of cloud to extend the
inherent advantage of agility, capacity alignment, and fixed cost
avoidance to outpace their competition. Cloud offers new rules of
competitive differentiation, and these nimble new asymmetric com-
petitors will press the advantage.
Furthermore, asymmetric competitors know of no other operat-
ing model than a cloud computing paradigm. Therefore, they will
86 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 87
accumulate expertise and skills at leveraging cloud-based business
models, and thus will outpace their entrenched traditional rivals on
a knowledge and experience basis with cloud. Their cloud-based
competitive advantage will rapidly accrue based on accumulated
knowledge through more cycles of learning of their cloud-enabled
business model. A cloud-based business model can learn and adapt
faster than a typical IT-infrastructure based business model, which is
one reason why cloud-based businesses will run roughshod over
their traditional competitors.
Legacy business models suffer from installed base and aging IT
infrastructures. Such legacy business anchors are impairing many
firms and preventing them from innovating their IT capabilities to
better support today’s emerging business requirements. Ask any
CIO, and they will concur that they spend 70–80% of their IT bud-
get maintaining their current installed base and legacy applications,
as opposed to being able to shed legacy applications and invest capi-
tal in new innovations on behalf of the business. Asymmetric com-
petition is already occurring through the widespread adoption of
cloud computing to create new, nimble cloud-based competitors.
For mature enterprises, the need for agility becomes a critical re-
quirement to counter the tactics of these new asymmetric competi-
tors. However, the real battle is not protection of the current
business model, but the development and innovation of new busi-
ness models through the aggressive adoption of cloud computing.
This is the new frontier where asymmetric competitors will be hard
to match.
Speed of Competition
Another strategic implication of cloud computing is the speed of
competition. In addition to enabling a new pack of asymmetric com-
petitors, cloud enables a new pace of competition from current
competitors as well. Cloud offers a new model to get to market with
new solutions, services, and capabilities that can literally pop onto
your radar and take market share before you can blink an eye. This
is a unique feature of cloud-based business models and even cloud-
enabled business models. As Stalk and Hout (in their book Compet-
ing Against Time
1
) advocate, cloud-based competitors have a clear
advantage simply on the basis of speed, cycles of learning, and accel-
erating up the learning curve for new business model innovations.
Strategic Implications of Cloud Computing 87
E1C04 03/02/2010 Page 88
Cloud-based competitors have many of the time-based advantages
that are identified in Stalk and Hout’s groundbreaking book, and
will therefore be formidable to entrenched competitors in similar
markets. Cloud-based competition will center on agility and speed,
and both are related to having no internally-owned and operated IT
infrastructure. Speed of competition is supported by a number of
variations, which are explored in the sections below.
Speed to Market. A cloud-based business model can bring a
new product or service to market faster than its traditional
competitors. The speed to market benefit of cloud computing
is a key feature of this computing evolution, and will be a com-
pelling reason why all organizations will explore cloud for
aspects of their business models. Compressing relative time to
market enables an organization to get to market with its prod-
ucts and services faster, which has direct implications for reve-
nue generation, market share capture, and for their
competitive position against other firms. As history clearly
shows, first to market very often wins, and cloud enables that
competitive advantage.
Speed of Innovation. Cloud-based business models will enable
rapid cycles of innovation for new business models, new prod-
uctsandservices,andnewbusiness tactics that can leverage
the speed and agility of cloud to gain competitive advantage
over competitors. An organization’s speed of innovation will
increase dramatically based on its ability to leverage cloud-
enabled research and development to innovate, experiment,
and bring to market new concepts and ideas.
Speed of Learning. Another critical dimension of cloud com-
puting is the speed of learning enabled through cloud-based
business models. Related to many of the other dimensions of
speed and time-based competition, cloud-based business mod-
els will benefit from speed of knowledge and speed of learn-
ing, a dynamic that supports rapid change, evolution of
business models, and a higher cadence or pace of innovation.
For a new business, the speed of learning has everything to do
with that organization’s ability not only to survive but to thrive
in any business environment.
Speed of Business Model Evolution. Thepinnacleofcloud-
based competition is the speed and pace of business model
88 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 89
evolution and innovation that cloud enables. By simply focus-
ing more personnel resources on its business model, an orga-
nization can rapidly evolve and adapt its business model
concepts to better compete against its competitors. Cloud-
based business models offer a superior business model evolu-
tion framework because of the absence of internal integration
to an installed base of legacy systems, without the need to wait
for the IT infrastructure to adapt in lockstep with your busi-
ness model.
Infrastructure Avoidance: Today’s Entrepreneurial Mindset
A critical cloud benefit that we must emphasize is the ability to
bypass IT infrastructure investment and operations completely.
Today’s startups are averse to the entire concept of buying and
maintaining IT infrastructure, data centers, server farms, and the
like. Why waste money and effort on infrastructure when we can be
focusing on a cool new innovation, a new technology or a com-
pletely new business model? This IT infrastructure avoidance mind-
set is the current reality of today’s generation of entrepreneurs. In
fact, if you acquire IT infrastructure you are considered an old
school startup right away. It is neither ‘‘cool’’ nor ‘‘hip’’ to buy IT
infrastructure.
Infrastructure avoidance allows the ultimate in flexible and agile
business models. We must understand, however, the mindset of
today’s entrepreneurs in order to fully appreciate this dynamic.
Today’s entrepreneurs exhibit the following characteristics:
Web-Centric Culture. Today’s new entrepreneurs grew up on
the web, the whole web, and nothing but the web. They live
their lives on the web. They represent a culture that embraces
all things web. They are digital natives. This generation of
entrepreneurs will be extremely comfortable with cloud-based
competition because they are comfortable with the web-based
dimensions of cloud computing.
Remote Distributed Anonymous Collaborators (RDAC).
Today’s generation of new competitors is extremely comfort-
able with remote collaboration, often anonymously, with peers
and partners that they have never met. This generation of
entrepreneurs can achieve their goals via a highly virtualized
Strategic Implications of Cloud Computing 89
E1C04 03/02/2010 Page 90
web-enabled collaboration process with peers and partners
with shared vision and goals. Because the network or commu-
nity is defined and aligned with shared ideals, vision, and
objectives, they can succeed by leveraging a remote anony-
mous collaboration model. This organizational construct is
ideal as a precursor to cloud-based business models—a web-
based collaboration business model can be migrated to a
cloud-based execution model.
Web Application Ecosystems. Today’s entrepreneurs are inti-
mate with ’’all things web’’, Google, Amazon, Facebook,
Apple/iPhone, Android, pervasive mobile devices, and wire-
less communications—they grew up with these applications,
models and computing paradigms, and care little about tradi-
tional computing models based on installed software on fat
clients connected to a conventional datacenter. If the capabil-
ity is not provided via the web and a browser, they do not
want it.
Open Source and Everything Is Free. This generation of new
entrepreneurs wants software for free—in fact they want every-
thing for free if they can get. Open source and free is always
the first choice. If they cannot get their software for free, they
will alternatively look to rent it as cheaply as possible over the
web. They will almost always avoid buying physical assets or li-
cense software, as much to avoid having to manage installed
base as to avoid paying for software tools they believe should
be free for a common good. Open source web-based business
models are what they know and want.
Mobile Devices and Untethered Telecommunications. Today’s
entrepreneurs are most likely to skip a physical land line for
their home telephone requirements, and instead rely on
wireless communications. This generation eschews physical
connections, physical infrastructure, and being physically
tethered to anything. This further feeds the mindset that
avoids infrastructure at all costs.
Distributed Collaboration. Today’s entrepreneurs are commit-
ted to highly distributed collaboration models, where their
partners, peers, and colleagues are connected via the web into
loosely coupled business processes in support of the shared vi-
sion of the business model. The physical distribution of the
90 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 91
team, the processes, and organization model make cloud-
based competition models ideal for these new competitors.
PutItAllontheWeb.They do not have the fear of the web
that more traditional competitors display. In other words, while
there are most certainly security and performance challenges
of web-based business models and operations, today’s young
entrepreneurs do not view them with suspicion and dismay;
they view them as the current reality and work around these
obstacles to launch their business models in spite of them.
The entrepreneurial mindset of today will create a new genera-
tion of cloud-based business models that will soon be attacking leg-
acy marketplaces and industries, as well as creating entirely new
ones. The discussion above develops a profile of the likely cloud-
based competitors that will become asymmetric competitors. These
asymmetric competitors will be a force to reckon with, and cloud
computing will be the fundamental technology foundation that
they will be competing with. Combine the mindset of these new
entrepreneurs with the technology approach of cloud computing,
and there is real danger for naysayers along with tremendous oppor-
tunity for adopters of cloud.
Evolving from SOA into the Cloud
Up to now, this chapter has focused on some of the strategic, busi-
ness, IT, and financial implications of cloud computing, and the
characteristics of cloud-based competitors. In this section, we
explore some cloud migration and adoption scenarios that have
bearing on relative cloud success for organizations in their transi-
tion from the last major architecture paradigm, Service-Oriented
Architecture, or SOA, to cloud computing. While SOA still is an
emerging architectural and technology trend, it has become the de
facto architectural paradigm for business applications and informa-
tion technology capabilities today. Though some analysts self-serv-
ingly declare that SOA is ‘‘dead,’’ the paradigm of services and
service-enablement of capabilities associated with SOA—despite the
baggage—will be the dominant architectural pattern for years to
come. Cloud will benefit from the goodness of SOA both in the
short term and in the long term.
Evolving from SOA into the Cloud 91
E1C04 03/02/2010 Page 92
Cloud computing, of course, benefits from SOA in significant
ways. Cloud computing is directly related to the provisioning and
consumption of IT capabilities as a service over the web. SOA
enables cloud-based business models and cloud-enabled business
models. Cloud builds on the shoulders of SOA. SOA, of course,
built on previous technology and architecture advancements and
innovations around web computing and massively distributed
computing.
Many organizations have had success with their SOA initiatives,
and thus are well postured to adopt cloud computing as a viable
technology strategy. Cloud logically builds on SOA concepts of ser-
vices, in particular shared SOA infrastructure services, core enter-
prise services, and the clean layered architectures that SOA
represents. Those organizations that have embraced SOA will have
an easier transition computing. However, many organizations that
struggled with SOA have rapidly abandoned their failed SOA strate-
gies and have instead focused their efforts on cloud computing with
hopes of realizing many similar benefits. The question is, can those
organizations realize their cloud goals building on a failed SOA
strategy?
This section explores the relationships between SOA and cloud
computing, and how one discipline builds on the other. SOA and
cloud computing are interdependent initiatives, and if executed as
related initiatives, offer an Agility Double Play. You can achieve agil-
ity and flexibility from SOA adoption, and additional enterprise
agility from cloud computing. If an organization skips SOA and
moves toward cloud computing, it will eventually have to revisit
SOA and services concepts, as well as the architectural and organiza-
tional disciplines required to succeed with both. Our position is that
you need SOA behavior with cloud computing. However, success
with SOA, we suggest, means your organization is better positioned
to succeed with cloud computing.
SOA Cloud Transitions: Jumping into Cloud Computing
The transition to cloud computing for many organizations is occur-
ring now, beginning with education and awareness, evaluation of
vendor platforms in relation to targeted benefits, and proof of con-
cepts and pilot implementations. The hype cycle of cloud computing
92 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 93
has begun, fueled by analyst hype, vendor claims, and end-user de-
sires. The focus of this section is the adoption path to cloud comput-
ing from SOA. We have observed that many organizations are
embracing cloud computing, and their launch pad into cloud com-
puting is represented by five broad cloud computing transition
pathways:
1. Transition to Cloud Computing from a Successful SOA Initia-
tive. Your cloud computing initiative builds on SOA successes
by leveraging SOA governance disciplines, shared infra-
structure services, shared data services layers, well-defined
and layered enterprise architectures, and, of course, applica-
tions composed of services, which should be more easily tran-
sitioned onto a cloud platform. This is a relatively easy cloud
computing transition pattern, and offers a virtuous cycle of
cumulative SOA benefits coupled with the incremental bene-
fits of cloud computing. This is an Agility Double Play!
2. Transition to Cloud Computing from an Immature SOA Ini-
tiative, with Preliminary Success. Your cloud computing ini-
tiative begins from an immature and potentially successful
SOA initiative, where cloud computing can leverage architec-
tural discipline, build on already-implemented SOA shared
infrastructure services and core enterprise services, and lever-
age SOA governance disciplines. This cloud transition pat-
tern offers promise for both SOA and cloud computing
success.
3. Transition to Cloud Computing from an Immature SOA Ini-
tiative, Struggling to Achieve Success. This cloud transition
pattern essentially means the organization is frustrated
with its SOA initiative, and believes that cloud computing
can deliver IT value to the enterprise in a lower-risk, less
business-engaged fashion. This transition pattern does not
meanSOAwillnotsucceed,justthattheorganizationis
struggling with typical SOA adoption challenges. Thus
cloud computing offers another avenue to pursue that may
not endure the organizational, behavioral, and cultural
changes that SOA demands. The danger here is diverting
critical IT resources and funding to cloud when SOA still
requires sustained focus and effort. This is what we call
Evolving from SOA into the Cloud 93
E1C04 03/02/2010 Page 94
a ‘‘SOA red zone,’’ where SOA adoption can be critically
impaired during its normal SOA adoption lifecycle.
2
Our
experience suggests that cloud will suffer from the very
same behavioral, cultural, and incentive challenges that
SOA did.
4. Transition to Cloud Computing from a Failed SOA Initiative.
Your cloud computing initiative begins from a failed SOA
strategy, and essentially your organization ‘‘cuts its losses’’
and walks away from the SOA concepts—infrastructure ser-
vices, composition of applications from services, reuse and
sharing of services, and so forth. SOA failure comes in many
forms, but generally it indicates the organization did not have
the appetite for SOA, SOA governance, sustained SOA invest-
ment, and the discipline required to realize the incremental
and cumulative SOA benefits over time.
5. Transition to Cloud Computing, Skipping SOA Altogether.
This cloud transition pattern essentially means an organiza-
tion is a late adopter of SOA, or it never really gained traction
with its SOA efforts, and instead has chosen to skip directly to
a cloud computing paradigm. This cloud adoption pattern is
centered on small and mid-sized businesses, where the accu-
mulated combination of business and IT complexity, integra-
tion challenges, and duplicate application capabilities have
not forced them to consider a SOA initiative. SOA initiatives
are more popular with larger, more complex organizations
that have accumulated complexity through mergers and
acquisitions, as well as from natural organic growth where IT
complexity and duplicate applications and capabilities
evolved from organizational and structural choices, com-
bined with decentralized IT oversight and weak governance.
This cloud adoption pattern is very typical for new startups,
or small businesses that never really needed to pursue an in-
ternal SOA strategy to attack the typical integration chal-
lenges of larger organizations.
The jumping off point into cloud computing from SOA is a nat-
ural extension in some ways, but, in other ways, it means bypassing
the sometimes arduous effort represented by an enterprise SOA ini-
tiative. We will explore some of the implications of transitioning to
cloud computing from various stages of SOA adoption.
94 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 95
Agility Double Play: SOA + Cloud Computing = More Agile Enterprise
The most compelling aspect of the cloud transition patterns above
is the ability to drive enterprise agility truly from two perspectives in
parallel. SOA combined with cloud computing offers an Agility
Double Play, which combines the agility offered by a flexible, virtual-
ized cloud environment with the business process and application
composition agility offered by SOA through reusable, composable
services.
SOA offers enterprise agility though composition of applica-
tions and orchestration of business processes based on consuming
web services (or services) available in your enterprise or accessible
through third-party service providers. SOA also supports IT flexibil-
itybyabstractinglegacysystemsand infrastructure from applica-
tions through a layered services architecture, which helps eliminate
point-to-point interfaces and instead encourages access to service
implementations via standards-based interfaces leveraging industry
standards.
Cloud computing offers another level of enterprise agility
through the rapid provisioning of new business applications into
service by hosting them on a cloud-enabled platform, which elimi-
nates the need to specify, order, acquire, install, configure, test, and
manage the infrastructure (servers, storage, networks, security) to
enable that business application. By leveraging a cloud computing
paradigm, a business application can be quickly introduced without
the cost, time, and effort required to buy, install, and configure ded-
icated infrastructure. This Agility Double Play of SOA combined
with cloud computing combines many best-of-both-worlds scenarios
into a very real and tangible value proposition that is too significant
to ignore.
Exhibit 4.1 illustrates the power of the Agility Double Play.
Critical to the Agility Double Play is the parallel implementation
of both SOA and cloud to enable your enterprise business objec-
tives. You must understand that these are complementary efforts,
and that in fact cloud explicitly relies on SOA and service enable-
ment in order to provide its capabilities to a given enterprise.
Cloud Pulls SOA Initiatives Through A clear industry pattern al-
ready underway is that cloud interest is pulling new SOA initiatives
through. The economic pressures on many organizations triggered
Evolving from SOA into the Cloud 95
E1C04 03/02/2010 Page 96
a spike of interest in cloud technology. The interest in cloud, unex-
pectedly, spurred renewed interest in SOA, or brought to the sur-
facenewdemandforSOAthatneededacloudpushtoenergize.
Regardless, interest in cloud computing has triggered latent de-
mand for SOA. The cloud pull of new SOA efforts, from one per-
spective, should not be a surprise. After all, cloud demands a
certain technical and behavioral maturity such that an organization
will be comfortable with service-enablement of capabilities and
applications, and is also equally accustomed to consuming IT capa-
bilities as services. The mindset of a service-oriented organization
and culture is highly aligned with the nascent cloud computing
paradigm.
Technically, cloud pulling SOA is due to the requirement for
service-enabled capabilities in order to provide or consume them
via a cloud-based paradigm.
Behaviorally, cloud pulling SOA through is the comfort level
with acquiring critical IT capabilities as a service provided by others.
The trust-based model of cloud is very much akin to the trust-based
model of SOA and shared, reusable services provided by others.
Culturally, when a company is accustomed to providing and con-
suming resources from third parties, externally or internally, the
Exhibit 4.1 Agility Double Play
Source: AgilePath Corporation. Used with permission.
96 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 97
organization will have a superior ability to absorb and adopt cloud-
based business capabilities into its enterprise.
Putting these forces together, it is no surprise that interest in
cloud computing is pulling SOA as a business model, an IT strategy,
and an architectural paradigm into greater relevance for all
organizations.
SOA Enables Cloud From business, IT, and architectural perspec-
tives, SOA also enables cloud. SOA enables cloud because of the cul-
tural and behavioral forces we identified previously—the mindset
and culture of providing and consuming critical resources in a
trust-based model from third parties.
SOA enables cloud from a business model perspective, where
service orientation is all about making appropriate decisions about
core and context capabilities, driven most often by transaction cost
analysis and evaluation of economic trade-offs and relative cost-ben-
efit analysis justifications for doing certain business functions inter-
nally versus having external service providers perform them on an
organization’s behalf. These are common decisions in the organiza-
tion and structure of any business operation.
SOA enables cloud from an IT strategy perspective in that the
information technology functions of an enterprise must provide a
level of support to the business that is on par, minimally, with
external service providers of the same IT capabilities. In this fash-
ion, the IT organization must examine how it best supports the
strategic business model and the tactical day-to-day operations of
the business, and then make the same core and context decisions
that are made by the business. Thus, SOA enables cloud from this
perspective in driving a behavioral model of optimizing the IT
enterprise based on service and cost decisions in support of the
business.
SOA enables cloud, most assuredly, from an architectural and
technical perspective. Service enablement of resources enables
them to be logically understood and utilized in a granularity that is
more intrinsically cloud-native. In addition, service enablement of
resources establishes the logical boundaries and modes of interac-
tion that best suit the cloud. Finally, service enablement may be
used to ensure that interdependencies are maintained to ensure
natural scalability and elasticity (see Exhibit 4.2). See Chapter 8, All
Things Data, for more on this.
Evolving from SOA into the Cloud 97
E1C04 03/02/2010 Page 98
When to Do SOA versus Cloud?
A key topic that emerges from the Agility Double Play discussion
and the transition from SOA to cloud is understanding when your
business needs call for a SOA-based architectural model as opposed
to, or in conjunction with, a cloud-based architectural model. The
answer, ultimately, is that you will eventually be doing them both,
simultaneously, with cloud being the master enterprise infra-
structure and application hosting and deployment architecture,
and SOA being the master application architecture.
In the short term, however, while cloud computing matures,
there must be a reconciliation of SOA and cloud to one another
based on industry reference models and reference architectures.
Both of these approaches, however, must be mapped and aligned
to a well-formulated and documented Enterprise Architecture for
your organization. Furthermore, determining whether SOA or
cloudisthemasterarchitectureforyourbusinessneedsmustbe
determined initially based on business goals and objectives.
While there is overlap of the respective value propositions of
Exhibit 4.2 SOA–Cloud Iteration
Source: AgilePath Corporation. Used with permission.
98 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 99
SOA and cloud, there are differences as well, as illustrated in
Figure 4.3.
As shown, the business drivers for SOA and cloud are similar in
some ways, yet different many others. Remember, SOA is fundamen-
tally an application architecture construct predicated on reusable
services, while cloud is in many ways much broader than SOA in its
ability to support a wide range of business, technology and eco-
nomic challenges.
Many organizations are headed down the SOA path, and are try-
ing to determine how cloud either supports or augments their cur-
rent SOA strategies, or how cloud should be pursued as a separate
yet related IT initiative for their enterprise. For these organizations,
they may consider leveraging cloud virtualization technologies and
cloud platform middleware to provide the core enterprise services
or SOA infrastructure services required of their SOA initiative. This
approach offers a framework to cloud-enable the infrastructure ser-
vices layer(s) of your SOA reference architecture, while maintaining
the SOA–centric business and data services layers, as well as the abil-
ity to support process orchestration and application composition.
Contrasting SOA and Cloud Cont’d.
• Increase business agility
• Improve time to market
• Achieve better business-IT
alignment
• Reduce IT costs
• Improve IT flexibility
• Reduce integration costs
• Reduce application maintenance
costs
• Achieve reuse
• Rapid time to market for new
capabilities
• Acquisition end around
• Competitive time compression
• Asymmetric competition
• New start-ups LOATHE
infrastructure
• Better asset utilization –
hardware/infrastructure
• Better asset utilization – people
resources
• Convert fixed costs to variable costs
SOA Cloud
Exhibit 4.3 SOA–Cloud Value Propositions
Source: AgilePath Corporation. Used with permission.
When to Do SOA versus Cloud? 99
E1C04 03/02/2010 Page 100
Thus, this approach effectively ‘‘inserts’’ cloud into your SOA refer-
ence architecture.
For organizations who are late adopters of SOA, but are early
adopters of cloud, we suggest making cloud the master reference
architecture, thereby leveraging cloud to enable your SOA strategy.
Thus, rather than acquiring SOA infrastructure and middleware
tools, you would deploy your services to a cloud-enabled platform
that will host your services, provide the runtime container and/or
application server functions, and support orchestration and compo-
sition of business applications built from your portfolio of services.
The cloud platform you select could be a private cloud that you im-
plement internally, or it could be a third party cloud platform
offered as a service by a multitude of cloud service providers. This
approach ‘‘inserts’’ SOA and services hosting/provisioning into a
cloud reference architecture. The upside associated with this ap-
proach is that you can leverage a cloud-based SOA framework to
ramp up or down capacity demand for services for which you are
unsure of their true consumption demand within your enterprise or
by your customers.
So, answering the question, ‘‘What is the master reference archi-
tecture?’’ is not quite as straightforward as it might seem. Building
on the previous discussions, there are four main approaches to
determining how SOA and Cloud can be reconciled, as described
below.
Cloud as the SOA-enablement and services hosting/provision-
ing framework: In this approach, cloud is leveraged as the
master reference architecture, and thus provides the SOA plat-
form and supporting middleware for services hosting, provi-
sioning, management, and application composition. This
approach will work especially well when there is organizational
alignment and cooperation of the application architecture or-
ganization with the enterprise infrastructure/data center or-
ganization, and they are both aligned under a cloud strategy
that will make this model a priority.
SOA with Cloud-enabled SOA Infrastructure: In this ap-
proach, SOA remains the master reference architecture for
applications and services, yet it recognizes the value that a
cloud framework can bring for the SOA infrastructure and
middleware tools. Thus, this approach seeks to enable SOA
100 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 101
through cloud-enablement of the SOA infrastructure, either
with an internal cloud platform or leveraging a third party
cloud service provider. This approach is already being pur-
sued by many organizations today.
SOA and Cloud as Parallel Strategies: This scenario involves
pursing SOA and cloud as separate but parallel strategies, with
SOA being executed by the Enterprise Applications organiza-
tion, and cloud being executed by the IT Operations/Data Cen-
ter organization. Often, in large enterprises, these functions
reside in separate management domains, and are usually differ-
ent skill sets. Application architecture is a separate discipline
from the data center, infrastructure engineering and operations
activities of an enterprise. Thus, enterprise applications, applica-
tion architecture, and application development are often orga-
nized in a separate organizational structure from the activities
focused on data center operations, infrastructure engineering,
IT operations, and capacity management. This model will work
as long as the touch points between SOA and cloud are defined
and well understood, such that they are working together to op-
timize their alignment and support to business goals. Most
likely, the strategies for each must be converged, and there
must be appropriate enterprise architecture governance con-
trols, supported by other IT governance constructs to ensure
alignment and joint delivery of both SOA and cloud for
the business.
Agility Double Play: SOA and Cloud Together: Of course, we
have been advocating for the Agility Double Play in this chap-
ter, where SOA and cloud are pursued as part of a single enter-
prise strategy that leverages the benefits of both architectural
approaches on behalf of the IT organization and the business.
In the Agility Double Play, regardless of relative maturity of
SOA and cloud strategies, they are converged under an um-
brella strategy that incorporates both as key elements of a sin-
gle business and IT strategy. In this model, there may be two
focused working groups or teams pursuing the details of both
SOA and cloud, but there will be an integrated team that
brings them both together, architecturally, organizationally,
and from an execution perspective, so that they can deliver
the mutual benefits that SOA and cloud offer as a single, inte-
grated strategy.
When to Do SOA versus Cloud? 101
E1C04 03/02/2010 Page 102
What Cloud Computing Does Not Do, but SOA Does (or Can)
SOA offers a range of business benefits that are unique to SOA, and
that cloud computing cannot deliver. Thus these should not be
treated as mutually exclusive initiatives but as complementary initia-
tives. Below are a few key SOA benefits that cloud computing cannot
offer:
Support Faster Application Development via Compostion/Or-
chestration. SOA offers the compelling ability to rapidly com-
pose new business applications and orchestrate new or
changed business processes based on consuming available
web services. This is a unique value proposition of SOA initia-
tives. Cloud computing does not offer value in faster applica-
tion development, but it does support faster time-to-market by
eliminating the infrastructure procurement and provisioning
aspects of new business applications, as well as access to plat-
forms as a service (PaaS), which can help shorten time to mar-
ket for new business applications.
Support Development and Reuse of Business Services. While
SOA initiatives are all about developing and consuming reus-
able, sharable reusable services, cloud computing is more
about leveraging internal or externally hosted infrastructure
services, platform services (PaaS), application services (SaaS).
There is a common thread here, as SOA initiatives recognize
the value in establishing a shared core enterprise services
layer, and cloud computing is based on an internal or third-
party shared infrastructure services, platform services, and ap-
plication services. The fundamental difference between SOA
and cloud is that SOA emphasized the development and reuse
of data, business, and presentation services from an applica-
tion architecture perspective.
Reduce Application Maintenance for Custom Applications.
SOA initiatives reduce application maintenance costs by lever-
aging pre-built pre-tested services to compose business applica-
tions, which directly reduces maintenance and development
costs. In addition, revising or enhancing applications com-
posed from services is much less costly than recoding software
applications. Cloud can eliminate application maintenance by
consuming SaaS-based business applications for appropriate
102 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 103
business needs. Cloud can also reduce aspects of application
maintenance by building custom applications from Platforms
as a service (Paas) approaches, which eliminate the need to
maintain the application platform and associated platform
middleware required to support applications.
Reduce Integration Costs. SOA dramatically reduces integra-
tion costs for an enterprise, which can range from 20 to 30%
of a typical IT budget. Integration cost reductions come in the
form of elimination of point-to-point interfaces, leveraging
SOA tools such as enterprise service buses and related integra-
tion tools, and of course web services and XML approaches to
building and integrating applications.
Support Application Portfolio Rationalization and Consolida-
tion. SOA initiatives facilitate sharing and reusing common
services, which provide a means to consolidate and rationalize
your legacy application portfolios. Cloud computing is
focused more on simplifying and optimizing (and potentially
outsourcing) the IT infrastructure layers of an enterprise ar-
chitecture, while SOA tends to focus more on the application
portfolios and application architecture layers of an enterprise
architecture. SOA thus has more direct impact on rationaliza-
tion of application portfolios, streamlining of business pro-
cesses, and harmonization of data across your enterprise.
The main message here is that while cloud computing and SOA
offer some related benefits, they are really complementary initia-
tives as opposed to mutually exclusive initiatives. We would argue
that cloud computing will benefit significantly from SOA, and the
behaviors of successful SOA initiatives are very transferrable to your
incipient cloud computing initiative. If your enterprise pursues
both initiatives, you can achieve the Agility Double Play.
SOA Failure and the Effects on Cloud Computing Success
SOA failure does not breed cloud computing success. However,
SOA failure does not directly portend cloud computing failure
either. They each require differing levels of engagement with busi-
ness stakeholders and business process owners for success, while
there is overlap in areas where both can be successful in a given
enterprise. SOA success may well facilitate the transition into a
When to Do SOA versus Cloud? 103
E1C04 03/02/2010 Page 104
successful cloud computing initiative by leveraging disciplines, capa-
bilities, and knowledge acquired through your SOA initiatives.
SOA failure can be caused by a variety of reasons, some of which
may impact an organization’s ability to transition to cloud comput-
ing, and some of which do not. Below are some typical SOA chal-
lenges that may contribute to limited SOA success or outright
failure:
SOA Governance Shortcomings. SOA challenges or outright
failures can in many instances be attributed to the failure to
properly address the SOA governance requirements, not so
much from a technical governance perspective but from an
organizational, cultural, acquisition, funding, and service own-
ership perspective. As we have experienced, the governance
requirements will evolve as SOA adoption progresses and
matures, so the governance demands of SOA are persistent
and long lasting. This is perhaps why SOA governance is so
critical to SOA success.
Failure to Deliver End-User Value. (e.g., faster time-to-market
for business applications, reduced development cost). Often
we see organizations spending too much time on service pro-
vider activities and SOA enablement technology implementa-
tions as opposed to working with business and end-user
communities to apply SOA to their business problems quickly.
The SOA benefits tend to get lost when the effort is focused
on ‘‘doing SOA’’ versus ‘‘doing business via SOA-enablement
of applications, data, business processes and IT infra-
structure.’’ There is a profound difference between the two.
SOA success is most often realized by delivering rapid value to
the business stakeholders of a given enterprise.
Too Much Focus on SOA Service Provider Capabilities, and
Not Enough Time Delivering End-User Applications and Ca-
pabilities. Related to the comments above, if you cannot suc-
cessfully engage with the business leaders and business end-
user community, you will struggle to maintain ongoing com-
mitment to SOA unless you rapidly deliver business value to
your customers.
Too Much Effort Trying to Explain What SOA Is versus Deliv-
ering Business Results through Services. As we all know, the
most successful SOA initiatives are embedded in the business
104 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 105
such that we are not talking about SOA at all. The sooner we
get the SOA conversation out of the way and focus on the busi-
ness or mission objectives, the better off we all will be, and the
more successful SOA will be.
Many SOA failures and SOA red zone struggles can be attrib-
uted to an internal, service provider focus as opposed to under-
standing how to engage with business stakeholders and apply SOA
to their business challenges. Cloud, by virtue of its more targeted
and narrower value proposition, may be able to avoid the over-
promise and trough of disillusionment that SOA has suffered
through.
SOA Patterns and Cloud Adoption Implications
There are a few cloud transition patterns from SOA that clearly au-
gur well for a successful cloud computing initiative. We explore a
few of these here, with the stipulation that this list is not exhaustive,
nor is it intended to be.
SOA initiatives tend to cluster into five primary patterns: data-
centric, process-centric, legacy-centric, consumer-centric and core
enterprise services patterns. The core enterprise services pattern
focuses on integrating a SOA enablement platform to provide core
enterprise services such as security, messaging, mediation, routing,
transformation and the like.
Success with any of these SOA patterns will bode well for cloud
computing. However, some SOA patterns lend themselves particu-
larly well to the transition to cloud computing. We will explore a
few here:
SOA Infrastructure Services/Core Enterprise Services Pat-
tern. SOA initiatives often center on developing a robust, inte-
grated SOA platform and infrastructure that delivers core
enterprise services that are shared by business and mission
applications. Cloud computing offers a similar infrastructure
virtualization model. Thus a successful SOA infrastructure ser-
vices effort will pave the way for a successful cloud computing
infrastructure virtualization pattern, which is normally an in-
dustry starting point for many cloud computing initiatives. Of
course, as discussed above, cloud service providers can offer
When to Do SOA versus Cloud? 105
E1C04 03/02/2010 Page 106
the SOA platform for the hosting, management and provision-
ing of SOA infrastructure services, which represents the cloud-
enablement of SOA.
SOA Data-Centric Pattern. Many SOA initiatives focus on se-
mantic integration, data accuracy, and data normalization
around an enterprise data model. These efforts fall under the
data-centric SOA pattern, which is typically implemented via a
robust SOA data services layer. Successful data-centric SOA
initiatives can lend themselves to cloud computing success
through the data and storage cloud computing pattern, as
well as through cloud-enablement of data services platforms
and hosting of data services. Storage as a service and rapid
sourcing, analysis, and dissemination of information from
data are fairly common cloud computing patterns, although
the storage cloud pattern is more common than the data
cloud pattern to date.
Consumer-Centric SOA Pattern. Presentation services and
application composition frameworks are positioned in the
consumer-centric SOA pattern, which enables end-user capa-
bilities at the glass under a SOA paradigm. The corresponding
cloud computing patterns include the Cloud platform pattern
and is the application/platform cloud computing pattern,
where applications and platforms are virtualized and provi-
sioned via cloud middleware to enable application scalability,
reliability, and remote user access via the web, and also where
application platforms are similarly provisioned to users over
the web. The application/platform cloud computing pattern
is supported in many respects by the consumer-centric SOA
pattern, although applications and platforms in cloud com-
puting are provider-side features of cloud computing rather
than service consumption activities represented by the con-
sumer-centric SOA pattern.
SOA/Service-Virtualization Sub Pattern. Enabling services vir-
tualization is a SOA subpattern or best practice that helps ease
the development of provisioning of services by providing SOA
platform middleware functionality such that service develop-
ers do not have to focus on it. Service virtualization is based
on loose coupling and abstraction concepts, but functionally
allows services deployment to be simplified, and services devel-
opment, testing, and provisioning to be standardized for
106 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 107
distributed developer teams. SOA/service virtualization is a
clear onramp to cloud computing, and is supported by the
SOA/services cloud pattern.
SOA Governance (Plus Two) Pattern. There are two addi-
tional dimensions to the four core SOA patterns: governance
and security. These are sometimes called ‘‘Plus Two’’ SOA pat-
terns. SOA success can almost always be associated with a solid
SOA governance model, comprised in part of governance pol-
icies, processes, enablement technology, organizational mod-
els, and boards. Cloud computing governance is emergent,
and its requirements and disciplines are not well defined yet.
However, we expect that an organization that has imple-
mented successful SOA governance can transition those expe-
riences and best practices into the requirements of cloud
computing governance to address issues of cloud security,
cloud onboarding/offboarding, cloud management, monitor-
ing, and operations, QoS, and SLA documentation and
enforcement.
Certain SOA patterns we addressed in the list above provide a
natural onramp to cloud computing, although there are differences
in the deployment and support requirements for them. In this light,
successful SOA initiatives can be directly supportive of an organiza-
tion’s transition to cloud computing. Again, we emphasize that
these initiatives bring some overlapping and unique value proposi-
tions to the enterprise that pursues them both. For those that have
not succeeded with SOA, we urge that you do not give up. Cloud
computing and SOA are mutually interdependent, and success with
one will enable success with the other. Success with both allows the
Agility Double Play described previously.
Cloud Computing Adoption Obstacles
There are some obstacles with cloud computing, obstacles that can
hinder an organization’s adoption of cloud and slow the industry
migration toward cloud-based business initiatives. Some of these are:
Security and Privacy Challenges. The security of cloud, and as-
sociated privacy concerns, give many organizations pause as
they think through their particular cloud computing concerns.
Cloud Computing Adoption Obstacles 107
E1C04 03/02/2010 Page 108
Security and privacy concerns include physical security and
simple access to facilities and equipment, as well as logical se-
curity, industry compliance requirements, auditability, and
more. There are also two perspectives: (1) where the security
glass is half-full and (2) where it is half-empty. The glass half-
full perspective believes that the cloud security concerns are
manageable and in fact are better when handled by a third-
party cloud service provider. The glass half-empty point of view
views all security challenges as hurdles that are immovable and
cannot be mitigated or overcome, regardless of the business
profile that merits onboarding into a cloud. As with the security
challenges that attended SOA and web services, the security ar-
chitecture and models associated with cloud will similarly be
stridently debated, and quietly overcome with security solutions
as the industry evolves.
Governance,SLA,andQoS.A critical set of potential cloud
obstacles include governance, service level agreements (SLA),
and overall quality of service (QoS) assurance. Much as gov-
ernance dominates the SOA discussion in ensuring appropri-
ate end-to-end governance across the IT and services lifecycle
in support of SOA initiatives, governance for cloud must also
include this.
Reliability and Trust. Cloud outages are well documented and
highly publicized, especially when the primary proponents of
cloud computing, such as Amazon, Google, Rackspace, and
others experience such challenges. If the cloud dial tone can-
not be assured, such that cloud consumers know that their
cloud-enabled resources will always be there for them, then
cloud will be relegated to niche needs where network availabil-
ity can be ensured. Cloud, like SOA, is a trust-based model
where lack of trust will severely cripple cloud adoption by the
masses.
Cloud integration and interoperability. The integration and in-
teroperability of private to private clouds, public to private
clouds, public to public, and hybrids poses a great challenge in
the absence of industry standards for APIs and cloud interfa-
ces, interoperability standards, and related technical standards.
Cross-cloud composition, collaboration, and orchestration of
applications. The concept of composing distributed business
applications across clouds, orchestrating business processes
108 Strategic Implications of Cloud Computing
E1C04 03/02/2010 Page 109
from services hosted in different clouds, both private and pub-
lic, and of integrating multiple hybrid clouds together into a
seamless business application fabric is new. There will be prog-
ress on these fronts as industry standards emerge to address
these potential needs.
Parting Thoughts: Things to Do Tomorrow
This chapter discussed ways in which SOA and cloud computing are
interdependent and mutually reinforcing business initiatives for an
enterprise. We suggested that SOA success can lead to cloud com-
puting success based on the SOA patterns that have been pursued
in the industry to date. While SOA and cloud offer some overlap-
ping benefits to your enterprise, they each bring unique value as
well. The following are some suggestions for you, and some things
you should begin doing tomorrow:
Develop a cloud computing strategy and roadmap, stating
clearly what you hope to achieve through cloud computing,
what business challenges cloud potentially applies to, and
what business challenges are not in cloud’s scope.
Understand various cloud computing patterns and the impli-
cations of implementing cloud computing for target business
requirements in your enterprise. Understand the relationship
of SOA patterns to cloud computing patterns, and how they
might reinforce one another.
Be clear on the desired business and financial benefits you are
seeking; operationalize the cloud and SOA tactics you will im-
plement to achieve those value propositions.
Understand that SOA and cloud computing, together, offer
the Agility Double Play to your enterprise. SOA and cloud
computing are not mutually exclusive efforts.
SOA brings enterprise value that cloud computing efforts do
not deliver. Be sure that the value you seek is being delivered
by an appropriate paradigm—SOA and/or cloud computing.
The Agility Double Play is achieved through a unique imple-
mentation of both SOA and cloud computing. Enterprise agil-
ity can come from iterative implementations of SOA and
cloud computing, based on the various SOA patterns and
cloud computing patterns we have documented.
Parting Thoughts: Things to Do Tomorrow 109
E1C04 03/02/2010 Page 110
The cloud hype cycle
3
has already overshadowed SOA’s hype
cycle. Avoid the trough of disillusionment by being clear on
the value you seek, and how you will attain it. The use of SOA
and cloud computing patterns will help align your efforts to
deliver the business results you hope to achieve.
The rapid rise of cloud computing is following the typical hype
cycle of another technology trend. Many organizations are making
the leap to cloud and bypassing their failed or stalled SOA efforts.
Our observation is that many enterprises who struggled with their
SOA adoption efforts may also struggle with their cloud computing
adoption. While cloud computing offers benefits that SOA does
not, SOA offers benefits that cloud computing cannot deliver. They
are related, interdependent, and mutually reinforcing. SOA com-
bined with cloud computing enables the Agility Double Play. Suc-
cessful SOA adopters are better prepared for cloud computing
success, while failed SOA adopters may struggle. However, both
business initiatives will benefit from clarity around business goals,
and the strategies applied to realize those business goals.
Notes
1. Stalk and Hout, Competing Against Time: How Time-Based Competition is Reshaping
Global Markets, Free Press, 1990.
2. Excelling in the SOA Red Zone, AgilePath Corporation Whitepaper, 2009.
3. Trough of disillusionment and hype cycle are both terms popularized by Gartner
(www.gartner.com).
110 Strategic Implications of Cloud Computing
E1C05 02/25/2010 Page 111
5
CHAPTER
Cloud Adoption Lifecycle
This chapter develops a Cloud Adoption Lifecycle Model that de-
scribes the major cloud adoption phases and necessary activities that
an organization should proceed through on its way to realizing busi-
ness value from a cloud initiative. These cloud adoption phases are
realistic and represent tangible planning, architecture, deployment,
and operational requirements we believe reflect the reality of this
nascent information technology (IT) trend.
However, as with any emerging business and technology trend,
some of the later maturity stages of the proposed Cloud Adoption
Lifecycle are a bit more speculative. We simply do not know exactly
how cloud will develop as a segment of the IT industry and as a busi-
ness and technology trend. For example, the following questions
emerge from what we offer as the latter Cloud Adoption Lifecycle
stages:
Will there be a cloud integration and interoperability stage
where organizations are forced to contend with integration of
disparate clouds across organizational boundaries? If so, will it
be addressed early in the Cloud Adoption Lifecycle?
Will there be the ‘‘usual’’ interoperability challenges with
cloud that have accompanied all other technology and archi-
tectural shifts? Cloud, given its emergent nature, has few in-
dustry standards to help guide the vendors and end-user
organizations.
Will there be requirements for cross-cloud collaboration,
where organizations will establish collaboration processes
111
E1C05 02/25/2010 Page 112
leveraging data, applications, and infrastructure provisioned
into private, public, and hybrid cloud deployments?
Will organizations require the capability to perform cross-
cloud composition and orchestration of distributed, cloud-
enabled business applications and business processes that
leverage and access cloud-enabled data and related capabili-
ties within and across organizational boundaries?
What path will cloud evolution eventually take as a technology
trend? Will it materialize as the analysts and other pundits pre-
dict, or will it be derailed by an economic disruption akin to
what we are experiencing currently?
The Cloud Adoption Lifecycle Model helps lay out a sequence
of necessary steps to proceed through on the pathway to successful
cloud computing adoption for your organization. The Cloud Adop-
tion Lifecycle Model will help guide and shape how organizations
begin thinking about cloud as it applies to their organizations. It
creates a business-centric dialog and inquiry that maps and aligns
cloud computing patterns and capabilities with explicitly defined
business challenges and business needs, and transitions that initial
business-technology alignment through the rest of the Cloud Adop-
tion Lifecycle stages.
However, the Cloud Adoption Lifecycle must also be supported
by a tool to facilitate cloud technology alignment to business drivers
and business objectives. That tool is the Cloud Modeling Frame-
work, which will help map and align various cloud technology pat-
terns to the desired business goals. The relationship of these to
cloud planning and execution tools is explained below, and both
are developed further later in this chapter.
Cloud Adoption Lifecycle and Cloud Modeling
Framework: Two Necessary Tools for Cloud Success
In order to plan and execute a cloud initiative, we suggest you will
need two core tools to expedite your efforts: a Cloud Adoption Life-
cycle Model and a Cloud Modeling Framework. The Cloud Adoption
Lifecycle Model drives explicit business alignment between the
emerging cloud technology and a set of desired business outcomes
that will be realized through the appropriate exploitation of cloud.
The Cloud Adoption Lifecycle Model is illustrated in Exhibit 5.1.
112 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 113
Each of these Cloud Adoption Lifecycle stages will be explored
in detail in this chapter. The Cloud Adoption Lifecycle Model is also
supportedbytheCloudComputing Reference Model (CC-RM).
The Cloud Computing Reference Model develops the core cloud
technology patterns that support major business drivers and chal-
lenges, thus enabling a tighter alignment of cloud solutions to busi-
ness goals. There is no cloud reference modeling framework in the
industry, so this section will break new ground. The Cloud Comput-
ing Reference Model is illustrated in Exhibit 5.2.
The details of the Cloud Computing Reference Model Frame-
work, as implemented during the course of the Cloud Adoption
Lifecycle Model, are detailed below. In addition, Chapter 6, Cloud
Architecture, Modeling, and Design, will explore cloud computing
architectures, which will further decompose the elements of the
cloud computing reference model framework from a technology
perspective.
Leveraging the Cloud Adoption Lifecycle Model and the Cloud
Reference Model together will not only accelerate your cloud initia-
tive, but they will also lead to higher fidelity of business drivers and
Cloud Computing Adoption Playbook™
Cloud Strategy
& Planning
Cloud
Deployment
Model
Cloud Program
(Cloud Program
& Mult. Projects)
Cloud Reference
Implementation
Cloud Integration
&
Interoperability
Cloud Collab,
Composition &
Choreography
Cloud
Governance/Ops &
Ecosystem Model
Cloud Modeling
Cloud Computing
Reference Model
Cloud Provider
Analysis &
Selection
Cloud Steady
State
Cloud
Governance &
Lifecycle Planning
Cloud Deployment
&
Provisioning Plan
Cloud POC/Pilot
Implementation
Cloud Early
Learning &
Strategy Input
Cloud Program
Go/No Go
Implement Cloud
Governance &
Security
Implement
Mgt, Monitoring
Operations,
& Support
Cloud Modeling
and Architecture
Cloud
Implementation
Planning
Cloud POC/Pilot
Project Cloud
Implementation
Cloud Strategy and
Roadmap
Cloud
Integration
Cloud
Collaboration
Cloud
Maturity
Cloud
Expansion
Cloud Bus.
Discovery &
Assessment
Cloud Mobilization
& Transition
Planning
Cloud Reference
Architecture Cloud Program
Go/No Go
Feedback,
Metrics, Strategy
Evaluation
Exhibit 5.1 Cloud Adoption Lifecycle Model
Cloud Adoption Lifecycle and Cloud Modeling Framework 113
E1C05 02/25/2010 Page 114
goals to the eventual cloud solutions that are deployed to meet
those business goals.
In the remainder of this chapter, we will walk through the stages
of the Cloud Adoption Lifecycle Model, and then delve into the
Cloud Computing Reference Model as it enables and supports the
Cloud Adoption Lifecycle.
Cloud Adoption Lifecycle
The Cloud Adoption Lifecycle Model presents an idealized set of
steps we feel cloud adopters will progress through as they begin
exploring cloud computing for their respective enterprises. The
Cloud Adoption Lifecycle Model is not a maturity model, nor is it a
strict recipe for cloud success. Rather, the Cloud Adoption Lifecycle
Model represents a generalized framework upon which an organiza-
tion can plan and execute its own cloud adoption process based on
its particular needs.
This idealized Cloud Adoption Lifecycle follows five mainline
stages of cloud adoption, as illustrated in Exhibit 5.1, as well as the
anticipated cloud adoption stages farther out as cloud adoption
matures.
ThecoremainlinestagesoftheCloudAdoptionLifecycle
Model are:
Exhibit 5.2 Cloud Modeling Framework
114 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 115
Cloud proof concept (POC)/pilot project stage
Cloud strategy and roadmap
Cloud modeling and architecture
Cloud implementation planning
Cloud implementation
The supporting Cloud Adoption Lifecycle Model stages, which
build on your initial cloud implementation and are thus further up
the maturity curve, are:
Cloud expansion
Cloud integration
Cloud collaboration
Cloud maturity
Each of these stages of the Cloud Adoption Lifecycle Model is
explained in detail in the following sections. The Cloud Adoption
Lifecycle Model offers a baseline from which you can determine
your entry point into cloud computing, and the steps you should
consider to support your adoption of cloud computing. At the end
of this chapter, we will offer suggestions for using the Cloud Adop-
tion Lifecycle Model.
Cloud Proof of Concept (POC)/Pilot Project
The goal of this cloud adoption lifecycle stage is knowledge and
early learning about cloud technologies. This stage closes knowl-
edge gaps, helps understand what you do and do not know about
cloud, and prepares your enterprise for a more formalized planning
and implementation process going forward. The following activities
are included in the cloud proof of concept (POC)/pilot project
adoption stage, and are explained in the paragraphs that follow:
Cloud POC/pilot implementation.
Cloud learning, evaluation, and cloud strategy input.
Cloud program go/no go decisions.
Cloud POC/Pilot Implementation The cloud pilot implementa-
tion is a very important substage of the Cloud Adoption Lifecycle,
and one that prepares the organization for dramatic cloud learning
Cloud Adoption Lifecycle 115
E1C05 02/25/2010 Page 116
and hands on understanding of cloud’s potential for your organiza-
tion. Your cloud pilot implementation sows the seeds of cloud suc-
cess. Before beginning your cloud pilot, you should have clear goals
and metrics that will inform you whether the pilot was successful.
A cloud pilot should not be a technical proof of concept. Your
cloud pilot should actually test a business scenario that you feel rep-
resents how cloud may be applied on a broader basis in your enter-
prise, albeit in a smaller, controlled scope. The following attributes
of a cloud pilot should be considered:
Has defined goals and objectives, with metrics to evaluate rela-
tive success or failure
Is scoped narrowly enough, yet accomplishes defined business
objectives
Is planned as a business pilot versus a technology POC
Can be performed within a well-defined budget and time
duration
Informs the organization with respect to business, technology,
and operational lessons learned
Supports the cloud evaluation criteria defined beforehand
Informs the cloud strategy so that it can be validated, refined,
and tuned based on pilot lessons learned
Provides enough data to make an informed go/no go decision
with respect to cloud
Your cloud pilot is a stepping stone into solving pressing busi-
ness challenges via a well reasoned, technically sound cloud strat-
egy. The cloud pilot should be executed with intent to gain early
learning, basic cloud knowledge and hands-on experience, to in-
form your strategy based on this early learning to test potential
cloud patterns, architecture, and deployment models, and to ensure
you can realize the target business outcomes via your cloud strategy.
Cloud Early Learning and Strategy Input A cloud POC or pilot
project should enable your cloud team to gain valuable knowledge
and early learning about cloud computing. POCs and pilots help
you develop an understanding of what you do and, more impor-
tantly, what you do not know, in order to successfully implement
cloud computing in your organization. In addition, you should be
in a position to evaluate whether cloud is right for your enterprise,
116 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 117
and to evaluate various industry solutions and approaches to cloud
computing. Finally, your cloud POCs and pilots should generate a
baseline of information that will become explicit inputs into your
formal cloud strategy development process.
Basedonthecloudpilot,andthecriteriaandmetricsyoude-
fined to evaluate cloud pilot success, you should be in a position to
answer the following questions:
What have we learned from the cloud pilot that makes us con-
fident we will be successful?
Should we postpone developing our formal cloud strategy un-
til the industry is more mature?
Is cloud appropriate for the stated business, technical, and op-
erational challenges we face?
Have we performed a sufficient evaluation of cloud relative to
our business and IT organization?
Do we understand the risks as well as the business benefits
cloud offers to us? Do the potential benefits outweigh the po-
tential risks?
Did the pilot sufficiently answer the business, technical, opera-
tional, and security issues we identified pre-pilot?
Are we organizationally ready for cloud, given its immaturity
and the associated risks? Can we overcome potential behav-
ioral and cultural obstacles?
Do we have the knowledge and experience to develop and suc-
cessfully execute a business-aligned cloud strategy?
The cloud learning stage should be just that—an explicit exer-
cise to review lessons learned from your cloud pilot project, to eval-
uate your cloud readiness as an organization—from both a business
readiness and a technical readiness perspective. Often, organiza-
tional learning is not a directed activity as part of a formal strategic
planning process. This is why you should build into your Cloud
Adoption Lifecycle Model this process of learning, strategy evalua-
tion, confirmation, and/or revision, and then a clear definition of
the exit criteria to formally proceed into execution of your cloud
strategy. The cloud go/no go decision process is discussed next.
Cloud Program Go/No Go Decision At this point in the Cloud
Adoption Lifecycle, your organization should be prepared to make
Cloud Adoption Lifecycle 117
E1C05 02/25/2010 Page 118
decisions about whether or not cloud offers real business potential
to your organization. Based on your cloud POC or pilot projects,
you should now have a body of knowledge and data that allow you
to make the appropriate choice as to whether cloud makes sense for
your goals, and if so, exactly how and to what magnitude.
The following are sample exit criteria that may be considered as
part of your cloud program go/no go decision calculus:
Cloud offers potential to satisfy business requirements based
on your cloud POC/pilot.
Cloud has the potential to address our technical requirements
based on our POC/pilot project.
Cloud will satisfy operational requirements based on your
cloud POC/pilot project.
Cloud security considerations and risks are clearly understood
and are not show stoppers.
Cloud governance requirements can be met with current
approaches and technical solutions.
Cloudisaffordablewithinsomepredictablerangesuchthat
you can estimate the investment or costs, and the resultant sav-
ings or organizational benefit, and make planning decisions
accordingly.
Cloud is realistic given the organizational priorities.
Cloud is realistic given your current technology staff levels and
training.
Our POC/pilot projects have provided sufficient knowl-
edge and experience that we can develop a realistic cloud
strategy and roadmap, and execute that cloud strategy with
confidence.
The go/no go decision here is quite simple. Should your organi-
zation pursue a formal cloud computing program, you must allocate
the requisite resources to support the level of cloud program your
strategy calls for, and you will assign appropriate accountability for
the cloud effort.
Cloud Strategy and Roadmap
The goal of this Cloud Adoption Lifecycle stage is to incorporate
the lessons learned from your POC and pilots into a formal cloud
118 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 119
strategy development process. The cloud strategy and roadmap
stage establishes a formalized and actionable cloud strategy that will
be executed to achieve stated business objectives.
The activities to be performed in the cloud strategy and road-
map adoption stage are:
Cloud business discovery and assessment
Cloud strategy and roadmap
Cloud mobilization and transition planning
Cloud Business Discovery and Assessment The cloud business
discovery and assessment activities are necessary to understand
where your organization currently is with respect to cloud
computing capabilities, how mature your cloud efforts are,
and your overall organizational and IT readiness for cloud
computing. Your cloud readiness can be determined by your
general maturity and organizational readiness along three
broad dimensions:
1. IT Outsourcing Experience
^Have you had experience outsourcing all or portions
of your IT capabilities to third-party service delivery
organizations?
^Have you managed these relationships successfully?
^Did you establish SLAs and performance measures to mon-
itor those relationships?
^Have you migrated from one service provider/outsourcing
partner to another successfully?
2. IT Infrastructure Virtualization Experience
^Have you successfully explored various virtualization
technologies?
^Have you gained experience with various tools supporting
the foundational competencies of today’s cloud computing
industry?
^Are you prepared to build on your virtualization founda-
tion to add higher order cloud capabilities?
3. Service-Oriented Architecture (SOA) Maturity and Experience
^Have you achieved some level of success with SOA (e.g.,
SOA-enabling technology, infrastructure services, and re-
lated technologies)?
Cloud Adoption Lifecycle 119
E1C05 02/25/2010 Page 120
^Does your organization understand the basic concepts of
service interfaces, implementations, and service level agree-
ments (SLAs)?
^Have you developed the internal competencies to manage
the relationships between service providers and service
consumers?
^Have you developed the funding, incentives, and cul-
tural and behavioral models necessary for SOA, which
are also critical for becoming an internal cloud service
provider?
^Have you implemented enterprise governance processes,
policies, organizational models and enforcement technolo-
gies and tools to support IT and SOA governance? Can
these be adapted to and extended to support your adop-
tion of cloud computing?
Once you have determined your cloud readiness, you should
consider the following cloud business discovery steps preparatory to
developing your formal cloud strategy and roadmap:
Assess external business environment
Review business and IT strategy
Assess cloud strategy, if one exists
Perform cloud readiness assessment (see previous section)
Determine cloud maturity
Identify cloud business and technology drivers
Identify cloud business imperatives, or the issues that must be
resolved to be successful
Identify potential cloud obstacles or barriers
Define clear cloud goals and outcomes if you pursue a cloud
strategy
You will most likely develop other criteria for your cloud busi-
ness discovery and assessment needs. You can use these as a founda-
tion to get started, and add others as you see fit.
Successful forays into cloud will depend on and leverage your IT
organization’s collective experience and comfort levels with these
types of IT initiatives. The relative success you have had with each of
thesewillhavebearingonyourability to realize success through
cloud.
120 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 121
Cloud Strategy and Planning Cloud strategy and planning is essen-
tial to prepare your enterprise for cloud with a realistic and attaina-
ble cloud strategy that supports and is aligned with business and
mission objectives. A viable cloud strategy should state in clear un-
ambiguous terms what business problems a cloud approach will
solve, how cloud will address those business and technology chal-
lenges, what actionable and measurable steps will be taken to imple-
ment cloud to realize those goals and objectives, and by when.
As with a SOA strategy, the emphasis should not be on the
length of the strategy document but on how actionable, implement-
able, and operationalized the cloud strategy actually is. The follow-
ing attributes should characterize your cloud strategy:
Actionable. Cloud strategy clearly states what problems it
addresses, how cloud will be leveraged to meet those chal-
lenges, and what actions will be taken to do so. A cloud strat-
egy should not only be a call to action, but it should also
specifically state what actions will be taken, by when, and to
what effect as measured by some objective metric.
Implementable. The cloud strategy can realistically be imple-
mented, its impact can be tested and measured with appropri-
ate instrumentation and proof, and it can be scaled in
production operations to meet the business challenges it was
targeted to address. Along with the actionable attribute, the
cloud strategy must be sufficiently detailed and grounded in
real world effects. You must be able to actually implement
cloud and measure its impact on your operations, time-to-mar-
ket, cost reductions, and so on.
Operationalized. The cloud strategy is specific in its purpose,
goals, and objectives, and the activities and initiatives contem-
plated in the cloud strategy are specified with the following
level of detail:
^What will happen. Cloud will improve time-to-market for new
business requirements.
^By when. We will have our first public cloud in place by day,
month, year.
^As measured by the following metric. We will launch business
applications 50% faster by leveraging public clouds, and
save 65% of the capital expenses associated with acquiring
our own servers, storage, and IT infrastructure.
Cloud Adoption Lifecycle 121
E1C05 02/25/2010 Page 122
The biggest problem we see with strategic documents is a
lack of operationalized clarity, with dates, metrics, and account-
ability for implementation. Make sure your cloud strategy is suf-
ficiently detailed so that it is actionable, implementable, and
operationalizable.
Use these guidelines to develop your cloud strategy and execut-
able roadmap.
Cloud Mobilization and Transition Planning Upon completion of
your cloud strategy and roadmap, preparing for the transition to
cloud is next. An organization cannot simply perform a cloud busi-
ness discovery and readiness assessment, develop a cloud strategy
and roadmap, and suddenly, as if by magic, begin operating a pri-
vate, public, or hybrid cloud. First, your organization must go
through a period of planning, followed by the ramping of your orga-
nization’s knowledge, skills and capabilities, such that you will ena-
ble a smooth transition from your pre-cloud operating model to an
implemented cloud operating model.
Cloud mobilization and planning is the phase in which you
ramp your organizational capabilities and ensure your functional
readiness to implement cloud in accordance with your stated cloud
strategy and roadmap. The following activities should be part of
your cloud mobilization and transition planning phase:
Conduct a Cloud Training and Awareness Program. Conduct a
broad-based cloud training, education, and awareness pro-
gram to obtain general cloud skills and training, education
for key executives and middle management, and provide com-
prehensive organizational awareness to explain what cloud
is, what it means to your organization, and how your team
can engage in its realization. This cloud ramp and transition
activity will smooth the pathway to cloud success by ensuring
consistent terminology, awareness of the cloud strategy,
and accelerated buy-in to the cloud strategy by middle
management.
Obtain Cloud Architecture, Technical, and Operations Skills.
Obtain technical, architectural, and operations skills through
external consulting, technical training, prototypes, proof of
concept implementations, and pilots. This cloud ramp and
122 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 123
transition phase is critical to ensure you have the necessary ar-
chitectural, technical, and operational skills and capabilities to
meet your strategic cloud objectives. As with SOA, cloud
adopters will struggle if they do not have access to the appro-
priate skilled technicians, architects, and operations managers
to facilitate the realization of cloud.
Cloud Transition Planning. Develop a plan to transition from
the cloud strategy phase into action. The cloud transition plan
ensures you are ready to allocate resources and effort, and as-
sign accountability for the next stages of the Cloud Adoption
Lifecycle Model.
Cloud Modeling and Architecture Adoption Stage
The goal of this cloud adoption lifecycle stage is to perform the nec-
essary cloud modeling and architecture steps in order to execute
the cloud strategy. This adoption lifecycle stage leverages the Cloud
Computing Reference Model (CC-RM) and its supporting modeling
and architecture framework to develop a strategically-aligned cloud
reference model, reference architecture, and cloud implementa-
tion that will support and enable the defined cloud strategy.
The cloud modeling and architecture adoption stage enables
your organization to perform the appropriate cloud modeling and
analysis, to develop a cloud architecture that will help you imple-
ment cloud either (1) internally as a private cloud, (2) externally
leveraging a public cloud, or (3) in a hybrid model where you retain
cloud capabilities internally while leveraging public cloud capabili-
ties for aspects of your cloud strategy. The following activities are
part of the cloud modeling and architecture adoption stage:
Cloud modeling
Cloud Computing Reference Model
Cloud Deployment Model
Cloud Governance and Operations Model (quality of service
[QoS], security, and SLA planning)
Cloud Reference Architecture
Each of these elements of cloud modeling and architecture
phase is discussed in the sections following.
Cloud Adoption Lifecycle 123
E1C05 02/25/2010 Page 124
Cloud Modeling The cloud modeling and architecture substage is
a critical and emerging requirement for the transition to cloud
computing. As organizations will learn early into their cloud plan-
ning, there are multiple patterns of clouds, as opposed to a one-
size-fits-all cloud. In order to successfully leverage cloud for your
enterprise, you must have a framework for analysis that enables
you to map your business and technology requirements to the ap-
propriate cloud patterns and the supporting cloud-enabling tech-
nology and cloud deployment model, and to viable cloud service
and solution providers.
Cloud modeling and architecture is an important planning pro-
cess because it will provide guidance on what cloud solutions fit
your business and technical needs. Cloud modeling and architec-
ture also provides guidance on your cloud deployment choices—
internal private clouds versus leveraging external public clouds pro-
vided and operated by third-party cloud service providers. Cloud
modeling and architecture will help you determine what business,
technology, economic, and operational use cases are appropriate
for deployment to the cloud. Whether you plan to implement cloud
solutions internal to your organization, or to leverage public clouds
provided by Amazon, Google, Salesforce, or others, you must still
understand cloud patterns, architecture and technology patterns,
and various deployment scenarios in order to best determine what
cloud approaches are best for your business.
Cloud modeling and architecture begins with an understanding
of cloud patterns. There are multiple cloud patterns available that
address different business and operational requirements your orga-
nization may have. Next, we summarize the most common cloud
patterns and the business, IT, and operational challenges that they
satisfy.
Cloud Computing Reference Model (CC-RM) Cloud modeling is
the process of analyzing business, technical, and operational re-
quirements against a set of established patterns or approaches, and
then determining the optimal cloud pattern, architecture, deploy-
ment model, and appropriate cloud solutions to meet your target
business needs. The output of a cloud modeling approach should
be a complete cloud business solution, which has the following
attributes:
124 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 125
Is a cloud strategy, which articulates the business context and
rationale for pursuing cloud for a defined class of business,
technical, and operational requirements
Is described and modeled using the appropriate cloud patterns,
discovered through a cloud modeling exercise that meets tar-
geted business, technical, economic, and operational needs
Has a well-defined cloud deployment model that supports the re-
quirements (internal/private, external/public, hybrid (inte-
grated, federated)
Includes a cloud governance and operations model,whichde-
scribes the end-to-end governance of cloud as well as the nec-
essary operations and management model
Includes a cloud provider plan, which evaluates the universe of
cloud-enablement technologies as well as cloud service provid-
ers in accordance with your cloud strategy
Leads to a successful cloud implementation, or the cloud solu-
tion implemented based on the appropriate deployment
model that meets the business and operational requirement
Has a cloud onboarding/offboarding plan, which describes how
you will move applications, data, business process, and busi-
ness operations into a cloud deployment, whether internal/
private, external/public, or hybrid
Finally, includes a cloud operations and support model, which in-
cludes all cloud operations management, monitoring, and
runtime support necessary for operational and support re-
quirements of your enterprise
In order to define these Cloud requirements, we advocate the
use of the Cloud Computing Reference Model (CC-RM), which we
explain in great detail in Chapter 6, Cloud Architecture, Modeling,
and Design. Recall Exhibit 5.2 for the illustration of the CC-RM.
The proposed Cloud Computing Reference Model (CC-RM)
will establish a cloud modeling and architecture foundation from
which an organization can realistically plan, model, architect, and
deploy cloud computing in a pragmatic fashion to address real and
pressing business and technical challenges. Cloud should not be
treated as a solution looking for a problem, but as a collection of
cloud patterns that can be configured to meet a wide array of busi-
ness and technical requirements.
Cloud Adoption Lifecycle 125
E1C05 02/25/2010 Page 126
The Cloud Computing Reference Model is comprised of four
supporting models or elements, as described below:
1. Cloud Enablement Model. The core of the Cloud Computing
Reference Model is the Cloud Enablement Model. The
Cloud Enablement Model describes the tiers of cloud com-
puting foundation, enablement, and business capabilities
provided by cloud platform and service providers to potential
consumers of cloud-enabled technology and business capa-
bilities. The Cloud Enablement Model is comprised of the
full range of cloud technologies and enablement solutions
such that all cloud patterns can be realized by providers and
consumers.
2. Cloud Deployment Model. Describes the range of cloud
deployment scenarios available to your enterprise—internal
private cloud, external public cloud, hybrid cloud, and com-
munity cloud. These deployment scenarios may be mixed
and matched to meet a variety of business use cases and
requirements.
3. Cloud Governance and Operations Model. Describes the gov-
ernance, security and privacy, operations and support, man-
agement and monitoring requirements for cloud computing
to ensure you have considered all the potential operational
risks of adopting cloud for your enterprise.
4. Cloud Ecosystem Model. The Cloud Ecosystem Model con-
siders the requirements of developing and sustaining a cloud
ecosystem comprised of cloud providers, cloud consumers,
and cloud intermediaries, as well as the cloud network and
‘‘cloud dial tone’’ necessary to ensure the cloud is always
there for you. The cloud ecosystem also includes the various
cloud enablement technologies and cloud providers and con-
sumers of those cloud enablement technologies to establish
the cloud ecosystem.
The cloud modeling process should result in a fully de-
scribed Cloud Computing Reference model, as well as the cloud
patterns that implement the targeted cloud use case(s) you are
contemplating.
Cloud patterns describe the specific combinations of cloud ena-
blement technology, cloud-enabled resources and capabilities, and
126 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 127
the various deployment models that make those cloud-enabled re-
sources available to consumers. We use the following nomenclature
to characterize what constitutes a cloud pattern:
Cloud Pattern. A cloud pattern is a described combination of
a cloud enablement pattern and a cloud deployment pattern
that, taken together, satisfy the broad business, technical, eco-
nomic, and operational requirements captured in a cloud use
case and refined through application of the Cloud Computing
Reference Model.
Cloud Enablement Pattern. The cloud enablement pattern is a
description, either written or symbolically, of the cloud-
enabled resources or technical capabilities, and their relation-
ships to one another, as they satisfy the technical and architec-
tural requirements of a cloud use case and a defined Cloud
Computing Reference Model.
Cloud Deployment Pattern. The cloud deployment pattern
describes the various cloud deployment models that satisfy the
requirements of a cloud use case and a defined Cloud Comput-
ing Reference Model. The cloud deployment pattern describes
the broad deployment options of private/internal, public/
external, and hybrid, as well as more fine-grained variations of
those and the architectural implications of those choices.
Based on these cloud patterns, the following steps represent a
cloud modeling approach we will follow in this book:
1. Determine business drivers and business imperatives.
2. Obtain stakeholder alignment and agreement (business, IT,
and operations).
3. Understand how business imperatives are addressed by cloud
patterns.
4. Select appropriate cloud pattern(s) that support business,
technology, and operational needs.
5. Evaluateanddetermineclouddeployment scenarios based
on selected cloud pattern(s).
6. Determine cloud governance lifecycle requirements and
establish cloud governance model.
7. Evaluate cloud solution providers and cloud service providers
that meet requirements.
Cloud Adoption Lifecycle 127
E1C05 02/25/2010 Page 128
8. Select cloud business solution (cloud pattern, deployment
model, and cloud provider).
9. Implement cloud governance model.
10. Implement cloud solution.
11. Begin cloud provisioning, resource management, billing, and
accounting process.
12. Onboard business operation, process, application or data
onto cloud solution.
13. Monitor, manage, and govern your cloud deployed solution.
14. Evaluate costs, performance, and business impact; adjust
cloud strategy accordingly.
Based on the completion of the cloud modeling activities, you
must then define the cloud deployment model that is defined dur-
ing the cloud modeling process.
Cloud Deployment Model The Cloud Deployment Model is a
planning stage necessary to understand the various cloud deploy-
ment options you may pursue based on the specific cloud pattern
that meets your business, technology, and operational require-
ments, as well as the cloud provisioning model that will enable your
onboarding of business capabilities, applications, data, and business
operations onto a cloud platform either hosted internally, provided
by a third-party cloud service provider, or some hybrid deployment
pattern.
The cloud deployment plan describes the range of cloud de-
ployment options you may consider as you evaluate how best cloud
applies to a given business, technical, or operational need. The
broad cloud deployment choices are:
Private
Public
Hybrid
Community
Depending on your business, technical, and operational re-
quirements, you may have a clear and obvious cloud deployment
preference. In other cases, the cloud deployment scenarios may be
ambiguous, such that you lean toward a private or hybrid scenario.
128 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 129
Cloud Governance and Operations Model Cloud governance is a
critical dimension of cloud computing. It will span the following
range of business, technical, and operational requirements:
Onboarding and offboarding business operations, processes,
applications or data to a cloud. The Cloud onboarding/off-
boarding process should consider the following dimensions:
^Organizational readiness
^Business readiness
^Application and data readiness
^Infrastructure readiness
^Technical capability readiness
Cloud architecture, pattern modeling, deployment planning,
and implementation
Cloud operations, monitoring, and management
Cloud audit requirements, reporting, and compliance
oversight
Cloud provisioning processes
Cloud lifecycle management
Cloud governance lifecycle (from planning to operations,
from cloud consumer to cloud provider, from cradle to grave)
As you develop your plans for cloud modeling and architecture,
be very explicit with your cloud governance model. Do not overlook
the multidimensional requirements of cloud governance from a
complete, end-to-end perspective.
Cloud governance is a multifaceted discipline, and you should
not limit it to the operational runtime dimensions of cloud. You
should treat cloud governance as the end-to-end planning, architec-
ture, deployment, and operation of cloud computing. In this vein,
cloud governance takes on a much more significant footprint in the
planning and execution of your cloud strategy. Also, understand
that the cloud governance lifecycle is not well understood. That will
be remedied by the industry soon.
Cloud Computing Reference Architecture (CC-RA) A Cloud Com-
puting Reference Architecture (CC-RA) is necessary for all cloud de-
ployment patterns–internal private clouds, external public clouds,
and hybrid clouds that blend aspects of private and public clouds.
Cloud Adoption Lifecycle 129
E1C05 02/25/2010 Page 130
In all cases, you need to understand your cloud reference architec-
ture in order to provision applications, data, or business operations
to a cloud, and you need to understand cloud architecture to suc-
cessfully deploy one internally and provision the cloud resources to
your internal business customers.
The Cloud Computing Reference Architecture is an artifact that
is derived from the Cloud Computing Reference Model. The CC-
RM and CC-RA work together to help your enterprise follow a re-
peatable process that will lead to a successful cloud reference imple-
mentation. The CC-RM provides the cloud framework for modeling
the critical dimensions of cloud computing. The CC-RA helps map
categories of technology to the CC-RM, such that you can begin to
select vendor products mapped to the cloud reference architecture,
and such that you can evaluate and test cloud use cases and require-
ments against the cloud reference architecture in support of a fu-
ture cloud implementation.
Based on the cloud pattern or patterns that fit business needs,
the cloud architecture must be aligned to those business, technical,
and operational needs. Cloud architecture is a critical dimension of
cloud computing, especially given its newness, and in particular
given the huge trust being placed on cloud as the future of the com-
puting industry.
Cloud Implementation Planning
The goal of this cloud adoption lifecycle stage is to prepare for your
cloud implementation. This stage focuses on selection of appropriate
cloud technologies, cloud service providers, and cloud solutions to
support your chosen cloud strategy. In addition, deployment models,
and the necessary governance, operations and support, management
and monitoring, and security challenges are addressed in this stage
as well.
The cloud implementation planning stage of cloud adoption
focuses on the following activities:
Cloud provider analysis
Cloud deployment and provisioning planning
Cloud governance and lifecycle planning
Cloud program go/no go
130 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 131
Cloud Provider Analysis and Selection This stage of cloud adop-
tion requires a thorough analysis of cloud providers based on the
cloud strategy and planning process you are undertaking. Broadly
speaking, you have three cloud deployment choices to consider:
1. Internal Cloud Provider. Does your organization have an in-
ternal cloud capability online and operational? Are machine
images and virtual machines, and storage and network re-
sources provisionable to you with a supporting chargeback
model, at rates competitive with third-party cloud service pro-
viders? Does your internal cloud service provider (assuming
you have a shared services construct or your IT organization
has become a cloud service provider) offer the same level of
cloudpatternandarchitecture support as external cloud
providers?
2. External Cloud Provider. For external cloud service provid-
ers, you must evaluate their business viability, fundamentals,
and security practices. Do they offer the range of cloud-
enabled capabilities and resources to meet your organiza-
tion’s needs? How open or proprietary are their APIs? How
will they integrate and interoperate with other 3
rd
party cloud
service providers? With your future or current hybrid cloud
deployment patterns?
3. Hybrid Blend of Internal and External Clouds. For hybrid
cloud deployment scenarios, how will you intermix your in-
ternal cloud capabilities with public cloud resources provided
by third party cloud service providers? What cloud service
providers have experience supporting hybrid clouds? Will
third party public clouds integrate and interoperate with
your private cloud-enabled resources and capabilities?
In addition, you must consider the following dimensions in your
analysis:
Cloud Technology Providers. What cloud enabling technol-
ogy solutions are available to meet your organization’s cloud
requirements? What cloud-enablement technology and tools
match the cloud patterns and deployment models you feel
best suit your needs?
Cloud Adoption Lifecycle 131
E1C05 02/25/2010 Page 132
Cloud Service Provider. What cloud services are available
from various third-party cloud service providers? Do they offer
infrastructure virtualization, computing, storage, and net-
works?Aretheystrongonapplication(SaaS)orplatform
cloud services (PaaS)? What is their operational capability
with respect to backups, redundancy, failover, and their over-
all ability to meet your SLAs and meet the terms of your cloud
service contract?
These activities will help you determine who the providers are of
the cloud enabling technologies, tools, as well as third party cloud-
enabled resources provided by cloud service providers, that support
your business and technology needs.
Cloud Deployment and Provisioning Planning The cloud deploy-
ment and provisioning model is a critical planning tool to help
your organization understand the various cloud deployment op-
tions you may pursue based on the specific cloud pattern that
meets your business, technology, and operational requirements.
The Cloud Deployment Model documents the range of cloud
deployment options you may pursue to address your defined busi-
ness requirements. A cloud-provisioning model is necessary as
well, which will enable you to plan how to onboard business capa-
bilities, applications, data, and business operations onto a cloud
platform either hosted internally, provided by a third-party cloud
service provider, or some hybrid deployment pattern. The follow-
ing are key dimensions of the cloud deployment and provisioning
planning stage:
Cloud deployment plan describes the range of cloud deploy-
ment options you may consider as you evaluate how best cloud
applies to a given business, technical, or operational need.
The four broad cloud deployment choices are:
1. Private
2. Public
3. Hybrid
4. Community
Cloud provisioning plan describes how you will provision
cloud resources internally to your enterprise, or how you will
onboard your data, applications, or business processes into a
132 Cloud Adoption Lifecycle
E1C05 02/25/2010 Page 133
third-party cloud provisioned to you. Cloud provisioning is
essential in order to identify a consumer, profile their cloud
requirements, obtain billing information, and then provision
cloud resources to that consumer. For public clouds managed
and provisioned by third-party cloud service providers, or for
private clouds managed and provisioned by internal cloud ser-
vice providers via chargeback models, the provisioning process
will be similar.
Cloud Governance and Lifecycle Planning Cloud governance is
an emerging requirement of cloud computing, and encompasses
a broad set of business and technical requirements, from the
planning and architecture process through the design-time con-
siderations of cloud computing, functional and nonfunctional
requirements analysis, and the actual process of onboarding your
enterprise onto a cloud (internal, public, or hybrid), and the crit-
ical monitoring and operational requirements of cloud once you
have successfully deployed.
The end-to-end cloud lifecycle is not well understood, nor are the
cloud governance requirements of that end-to-end cloud lifecycle.
Cloud onboarding and offboarding planning is a critical step to
ensure a smooth transition into cloud computing, as well as a
smooth transition back from cloud if your organizational no longer
benefits from cloud, or if you are unsatisfied with your cloud service
provider and need to switch to another.
Your organization will benefit from an appropriate planning
process that documents your plan for onboarding a business opera-
tion,businessprocess,anapplication,oryourdataontoathird-
party cloud or into a private cloud you deploy internally.
Cloud onboarding planning should consider the following issues:
Process for accessing the cloud resources applicable to your
business needs
How to migrate a business operation to a public cloud
How to migrate applications to the cloud provider you have
selected
How to migrate data to the cloud provider you have selected
(internal or external)
How to migrate an application to a cloud while hosting your
data in your data center
Cloud Adoption Lifecycle 133
E1C05 02/25/2010 Page 134
How to back out of a cloud or switch cloud providers as
needed
How to monitor cloud operations and QoS
How to track and obtain audit data for data integrity
Expect great progress in the definition, policy, and manage-
ment of cloud computing from an end-to-end lifecycle perspective,
as well as the enterprise governance requirements of the cloud
lifecycle.
Cloud Program Go/No Go The last step of the cloud implementa-
tion planning stage is a final go/no go decision. Based on all the
effort you have poured into your cloud POC/pilots, developing a
formal cloud strategy and roadmap, your cloud modeling and archi-
tecture, and your cloud implementation plan, you should have a fi-
nal stakeholder review and decision as to whether to continue with
your stated cloud strategy. This final go/no go decision is the final
gate before you commit resources—both funding and personnel—
to implementing cloud. If your implementation plans call for a pub-
lic cloud deployment, you still have commitments to onboarding,
moving your data and/or content to a public cloud provider, and
monitoring the SLAs of that particular cloud implementation.