The move to turnkey computing

The move to turnkey
computing
Why everything as a service is inevitable.

Wednesday, April 13, 2011

Good morning. Today weʼre going to look at the evolution of
clouds, and why I think the inevitable long-term consequences
of cloud computing are third-party platforms, rather than the
infrastructure-centric, public/private deployments we see today.

Some background
@acroll
alistair@bitcurrent.com


I write, organize, and analyze emerging IT trends at Bitcurrent;
work on running clouds at CloudOps; and try to share some of
these thoughts with enterprises and startups.

Within ﬁve years, we won’t
care about virtual machines.
(Start with a big statement. At least you’ll pay
attention.)


Hereʼs what I want to try and convince you of.

One caveat.
I don’t mean big tech ﬁrms. Twitter stopped
using clouds for a reason. I mean businesses
whose core job isn’t the delivery of technology
services. Less than 10K machines.


Thereʼ

Five years is a long time.



(Remember, Apple once named its computers
after fruit.)

There was no Twitter.
Overshare

h)p://su.pr/1keiym
ere was no
Twitter

wasn’t a verb.

h)p://www.ﬂickr.com/photos/st3f4n/3951143570/
Once, we couldn’t look stuﬀ
up

So at least hear me out.



http://www.ﬂickr.com/photos/harshlight/3235469361

First, I want to talk about what cloud computing really
represents: the end of a monopoly on IT.

Two reasons why
monopolies were OK.


Monopoly isn’t necessarily a bad word. They serve their
purposes. There were a couple of reasons IT was a
monopoly for so long.

http://www.ﬂickr.com/photos/brewbooks/3319730327/
(16MB)

First, the machines were expensive. That meant they
were a scarce resource, and someone had to control
what we could do with them.

http://www.ﬂickr.com/photos/argonne/4563394851/

Second, they were complicated. It took a very strange
sect of experts to understand them. AVIDAC, Argonne's
ﬁrst digital computer, began operation in January 1953.
It was built by the Physics Division for $250,000.
Pictured is pioneer Argonne computer scientist Jean F.
Hall.
AVIDAC stands for "Argonne Version of the Institute's
Digital Automatic Computer" and was based on the IAS
architecture developed by John von Neumann.

http://www.ﬂickr.com/photos/ebeam/3586287989/

This was also a result of scarcity. When computers and
humans interact, they need to meet each other halfway.
But it takes a lot of computing power to make something
that’s easy to use;

http://www.ﬂickr.com/photos/ecastro/3053916892/

in the early days of computing, humans were cheap and
machines weren’t

http://www.ﬂickr.com/photos/binaryape/458758810/

So we used punched cards,

http://50ans.imag.fr/images/galerie/Source/IBM-1130-1.jpg

and switches,

http://honeynet.onofri.org/scans/scan22/sol/submission/reverse.jpg

and esoteric programming languages like assembler.

http://www.ﬂickr.com/photos/ﬂem007_uk/4211743886/

Think about what a monopoly means.

http://www.ﬂickr.com/photos/caveman_92223/3531128799/

A monopoly was once awarded for a big project beyond
the scope of any one organization, but needed for the
public good.

http://en.wikipedia.org/wiki/File:Bell_System_hires_1900_logo.PNG

Sometimes, we form a company with a monopoly, or
allow one to operate, in order to build something or
allow an inventor to recoup investment. This is how we
got the telephone system, or railways.

For much of its history, AT&T and its Bell System functioned as
a legally sanctioned, regulated monopoly.
The US accepted this principle, initially in a 1913 agreement
known as the Kingsbury Commitment.
Anti-trust suit ﬁled in 1949 led in 1956 to a consent decree
whereby AT&T agreed to restrict its activities to the regulated
business of the national telephone system and government
work.
Changes in telecommunications led to a U.S. government
antitrust suit in 1974.
In 1982 when AT&T agreed to divest itself of the wholly owned
Bell operating companies that provided local exchange service.
In 1984 Bell was dead. In its place was a new AT&T and seven
regional Bell operating companies (collectively, the RBOCs.)
http://www.corp.att.com/history/history3.html


When monopolies are created with a speciﬁc purpose,
that’s good. But when they start to stagnate and restrict
competition, we break them apart.

http://www.ﬂickr.com/photos/ktylerconk/4096965228/

In fact, there’s a lot of antitrust regulation that prevents
companies from controlling too much of something
because they can stiﬂe innovation and charge whatever
they want. That’s one of the things the DOJ does.

http://www.ﬂickr.com/photos/leokoivulehto/2257818167/

(IT’s been handed many of these thankless tasks over
the years, and the business has never complained.)

First: Monopoly good.


In other words, early on monopolies are good because
they let us undertake hugely beneﬁcial, but largely
unbillable, tasks.

Then: Monopoly bad.


Later, however, they’re bad because they reduce the level
of creativity and experimentation.

http://img.dailymail.co.uk/i/pix/2008/04_01/tornadoDM3030a_800x533.jpg

Today, the same thing is happening to enterprise IT,
both on the server-side (what we think of as cloud
platforms) and on the client side (with the
consumerization of technology through tablets, domestic
Wiﬁ and broadband, the use of personal messaging, and
so on.)

Infrastructure as a Service
Amazon EC2, Rackspace Cloud, Joyent,
Terremark, Gogrid, VMWare, and nearly every
automated collection of virtual machines.


The most common kind of cloud is Infrastructure as a
Service (IaaS.)

http://aws.amazon.com/ec2/pricing/

This is what most IT people think of when you say
“clouds” – virtual machines I can use for just an hour.
Here’s Amazon’s “menu” of machines.

Machine Web
Image server
Machine instance


In an IaaS model, you’re getting computers as a utility.
The unit of the transaction is a virtual machine. It’s still
up to you to install an operating system, and software,
or at least to choose it from a list. You don’t really have a
machine -- you have an image of one, and when you
stop the machine, it vanishes.

DB Machine
Storage
server Image

Machine instance

App Machine
Server Image
Machine instance

Web Machine
server Image
Machine instance


Most applications consist of several machines -- web,
app, and database, for example. Each is created from an
image, and some, like databases, may use other services
from the cloud to store and retrieve data from a disk

DB
Storage server

Machine instance
Bigger
App
machine
instance
Server
Machine instance

Web
server
Machine instance


If you run out of capacity, you can upgrade to a bigger
machine (which is called “scaling vertically.”)

DB
Storage
server

Machine instance

App
Server
Machine instance

Web
server
Machine instance

Load
balancer
Machine instance


Or you can create several machines at each tier, and use
a load balancer to share traffic between them. These
kinds of scalable, redundant architectures are common
-- nay, recommended -- in a cloud computing world
where everything is uncertain.

Platform as a Service
Google App Engine, Salesforce Force.com,
Heroku, Springsource, (and nearly every
enterprise mainframe.)


The second kind of cloud is called Platform as a Service.
In this model, you don’t think about the individual
machines—instead, you just copy your code to a cloud,
and run it. You never see the machines. In a PaaS cloud,
things are very different.

Shared components

Data Processing platform
Storage
API
Others’ Others’
code code
User Auth
database API
Your Others’
code code
Image Image
functions API Others’ Others’
code code
...
Big Blob Governor Console Schedule
objects API

- You write your code; often it needs some customization.
- That code runs on a share processing platform
- Along with other people’s code
- The code calls certain functions to do things like authenticate a user, handle a payment,
store an object, or move something to a CDN
- To keep everything running smoothly (and bill you) the platform has a scheduler (ﬁguring
out what to do next) and a governor (ensuring one program doesn’t use up all the resources)
as well as a console.

IaaS and PaaS differences
IaaS PaaS

Any operating system you Use only selected
want languages and built-in APIs

Limited by capacity of Limited by governors to
virtual machine avoid overloading

Scale by adding more Scaling is automatic
machines
Use built-in storage
Many storage options (ﬁle (Bigtable, etc.)
system, object, key-value,
RDBMS)


To summarize: two kinds of cloud platforms I call
“clouds”

Software as a Service
(AKA web apps with logins)


The term “clouds” is a broader one, however. Many
people consider Software as a Service a “cloud”
approach, and while it’s not offering platform or
infrastructure, it does represent an on-demand utility
that’s priced in a fairly elastic way (though usually by
time period, not by consumption, so not a pure utility.)


You probably know some of these companies, and others
like them.


SaaS and PaaS are blurring, too, with the advent of
scripting languages. Nobody would argue that Google
Apps is a SaaS offering; but now that you can write code
for it -- as in this example of a script that sends custom
driving directions to everyone in a spreadsheet -- the
distinction is less and less clear.

My mom’s deﬁnition

Cloud = Web = Internet = Useless


(Personally, I think this makes the term “cloud”
synonymous with “web” or “Internet”, and therefore a bit
useless.)

fewer dirty hands
Less options,
Other services Startup

Gov/nonproﬁt
Public SaaS

Private nontech
more headaches

Private PaaS Public PaaS
More control,

Public co.

Private IaaS Public IaaS
Large web

Cloud Cloud Global 2K
technology business
stack model

We’ve done a bunch of research on this subject; most
recently, we surveyed over a hundred IT professionals
from a wide range of industries to understand their
cloud adoption preferences. Here’s where adoption of
these different technologies is today.

Adoption of cloud models by company type
5

4
Adoption (1=none, 5=heavy

3

2

1
Private IaaS Private PaaS Public IaaS Public PaaS Public SaaS Other public

Startup/self-funded Private regional nontech Large web biz
Gov/nonproﬁt Public co Global 2K

We’ve done a bunch of research on this subject; most
recently, we surveyed over a hundred IT professionals
from a wide range of industries to understand their
cloud adoption preferences. Here’s where adoption of
these different technologies is today.

Ten arguments for clouds as
a third-party, turnkey utility.


So now hopefully we’re all talking about the same thing.
And here’s my big prediction, which I hope to argue in
the remainder of the time I have: we’re all going to buy
our computing in a turnkey fashion, much more like SaaS
and PaaS, and nearly none of us will know anything
about the underlying machines.

The economic argument


The ﬁrst argument is an economic one.

Photo by Alan Cleaver from his Flicker Freestock set. Thanks, Alan!
http://www.flickr.com/photos/alancleaver/2638883650/

A true assessment of internal IT costs is a painful thing. Not only are power, cooling, and
other recurring costs spiralling out of control, but companies don’t properly understand how
much they spend on fixing things. They don’t know what poor performance or outdated
technology does to productivity. Most analysts say it costs about five times as much to run an
application as it does to buy it in the first place.

http://www.oncloudcomputing.com/en/2009/07/fronde-back-to-proﬁt-by-cloud-computing/

Cloud providers can leverage sharing and economies of scale keep costs down. Cloud
providers are poised to make the most of these economies of scale. Consider that in
July 2008, Microsoft revealed that it had 96,000 servers at the Quincy facility,
consuming "about 11 megawatts"
More than 80% dedicated to Microsoft's Live Search and the remaining for Hotmail
In August, a really good discovery was posted to a blog called
"istartedsomething.com": a screen shot of a software dashboard that illustrates
power consumption and server count at each of Microsoft's ﬁfteen data centers,
caught in a Microsoft video posted to their web site.

Idle
capacity,
lack of
automation,
etc.
IT server
costs
Ping, power,
pipe,
Private efﬁciencies
cloud
costs Public
cloud
costs


Sure, cloud computing will make you more efficient if it’s
in-house. But these are short-term gains; even an
efficiently run private cloud in downtown Manhattan is
still in downtown Manhattan—not near a dam
somewhere. And unless you’re in the business of
providing IT services, it’s unlikely you can hire the best
in the world.


It’s in the cloud providers’ best interests to make this as
apparent as possible as soon as possible. So they’re
introducing things like spot markets, which undermine
any chance you have of looking cheap. Computers are
pennies an hour, when you need them.


Cloud providers are thinking at a scale that nearly every
enterprise can’t compete with. That’s because operating
efficiency, and accounting for everything, are core to
their business; whereas making widgets is core to yours.

The parallelism-drives-
spikes argument


Okay, so that proves there’s an incentive to move to public clouds economically, right? But
maybe you have enough capacity for existing, predictable workloads. Well, that will change
too, because of how developers will build their apps.


Most of the time, people think spikes come from sudden ﬂuctuations in demand. That’s true;
but parallelism and new ways of coding are changing that.

• 60 seconds per page
Desktop EC2 • 200 machine
Pages 17,481 17,481 instances
Minutes/page 1 1 • 1,407 hours of virtual
# of machines 1 200 machine time
Total minutes 17,481 • Searchable database
Total hours 291.4 26.0 available 26 hours
Total days 12.1 1.1 later
• $144.62 total cost


A great example of these clouds in action is what the
Washington Post did with Hillarly Clinton’s diaries during
her campaign. They needed to get all 17,481 pages of
Hillary Clinton’s White House schedule scanned and
searchable quickly. Using 200 machines, the Post was
able to get the data to reporters in only 26 hours. In
fact, the experiment is even more compelling: Desktop
OCR took about 30 minutes per page to properly scan,
read, resize, and format each page – which means that it
would have taken nearly a year, and cost $123 in power,
to do the work on a single machine.

http://www.ﬂickr.com/photos/sharif/2423144088/


What that means is that applications will be written to solve for time. A Hadoop cloud will use
as many resources as possible, for as short a time as possible. This will dramatically amplify
spikiness, even for existing applications. And companies that can’t burst up parallel
machines will get results—building plans, traffic congestion, feedback on a marketing
campaign, terror threats—slower than their competitors.

The everyone-hates-making-
sausage argument


So economics are better—and get better the longer out we project—and the next generation
of applications will make things spikier than ever, requiring access to a pool of machines
larger than any one company.
But why not public IaaS?

http://www.ﬂickr.com/photos/gezellig-girl/4351078755/

To understand this, we need to talk for a minute about “composed designs.”

Query language
Let’s just call
this a database,
Software ‘mmkay?

Operating system

Computer hardware

Storage media


When IT architects want to build something, they have a set of proven designs for doing so. A
database is an example of this—it’s a combination of storage (disk) and a particular way of
arranging things (tables and indexes) and language (structured query language, or SQL).
We’ve learned that a database is a good prefab building block, so we use it. The alternative is
to build it all, from scratch, writing to the disk itself.

Pork, now in
a convenient
cube format.


Often, we don’t want to know what’s happening under the covers.

Blood sausage, anyone?

http://www.ﬂickr.com/photos/avlxyz/4560146695

Making sausage is no fun. It’s messy, and the underlying parts aren’t very nice to look at.

http://www.ﬂickr.com/photos/avlxyz/4560146695

There are some companies that should focus on the making of sausage. UPS, for example,
deﬁned the market and made new things possible by applying IT to shipping logistics. It
needed to invent new sausage recipes.

http://www.ﬂickr.com/photos/mynameisharsha/4092086880/

The
glass
is a lie.

We
like
the
idea
of
virtual
machines.
They’re
convenient
ways
to

think
about
compuGng
in
easy,
universally
understood
ways.

The British pint.


They’re like the British pint.


Know what this map is? It’s the countries in the world that don’t use the Metric system.
Liberia, Burma, and the US.
(I’ll set aside the irony that the imperial system is named after the empire you celebrate
leaving.)

http://www.ﬂickr.com/photos/prosto/367231552


Europe loves the Metric system. But the British love their
pints. It’s no fun to day, “I’ll have 0.63 liters of beer,
please.” This became a massive sticking point with
British merger into the Euro.


In the end, the European union had to capitulate, letting the British sell pints as an official
measure. We’re the same way: virtual machines are a convenient unit of measure, left over
from an old system that we should shed for efficiency.

Providers love separation.


Cloud providers do better the less their customers know
about the underlying infrastructure. The more clouds
resemble data centers, the more the provider has to
expose.

http://www.ﬂickr.com/photos/mac-ash/4534203626/

At its most simple, this is all about a “stack” of services. Stacks are a common idea in
computing and networking. Basically, they’re a separation of different tasks.

http://www.ﬂickr.com/photos/easternblot/126112823/

We’re familiar with the idea of a stack. There’s a stack in the postal service.

Your virtual platform

Layer of separation
Their physical infrastructure


You worry about the address, and the stamp. The postal service handles the rest—it doesn’t
care what’s inside your envelope; and you don’t care what route your letter takes to its
destination, as long as it gets there.

Cell towers.

http://www.ﬂickr.com/photos/serdal/5099121696

Do you choose which cell tower to use when you make a
call?

Kettles.

http://www.ﬂickr.com/photos/leehaywood/4141300920/

Do you insist on choosing a generator when you boil a
kettle? Nope. Imagine how much less efficient the phone
company or power company would be if they let you. In
the same way, the more the cloud provider lets you play
with the sausage—because you’re addicted to metaphors
like computers—the worse things are.

The data-has-surface-
tension argument


There’s more. There are good reasons that the world will
be more centralized, with a few big providers, than it
was in the past.

“Compared to the cost
of moving bytes around,
everything else is free.”
Microsoft technical fellow
Dr. Jim Gray, 2003

http://www-users.cselabs.umn.edu/classes/Spring-2009/csci8980-ass/Jim%20Gray.pdf

This is the late Jim Gray, one of the smartest people ever to think about data. He’s the guy
that famously said, “never underestimate the bandwidth of a stationwagon full of tapes
driving down the highway.”

Hairy, smoking golf balls.
http://www.ﬂickr.com/photos/onigiri_chang/4791909127/

He described the CPU of tomorrow as a “smoking, hairy golf
ball” – a tiny computer bristling with wires and generating a lot
of heat. He also said that, compared to the cost of moving
bytes around, everything else is basically free.


Want proof? Look at the latest series of servers that big
vendors are offering: they have a lot of storage, a backplane,
and an army of processors. They look like mainframes.

Data in the middle.


Thatʼs why Amazon launched S3—their storage system—six
months before they introduced the EC2 virtual machine
offering. Because having all the data centralized is key. Once
the data is somewhere, putting other computing around it is
cheap.

The focus-on-why-you-rock
argument


Okay, let’s review. Public clouds are cheaper, and spiky
development patterns mean demand for more machines
at once. Dealing with the underlying infrastructure isn’t
fun, and we mostly want to because it’s familiar. The
physics of networking mean it’ll all be centralized in a
few places.
But wait; there’s more. The business will insist on
results.


Utility computing means you can focus on what matters.
That means heightened expectations for IT. Already,
many of the CIOs I speak with tell me they’re viewed as
service bureaus by the line of business that has found
Big Data religion.


Once we ﬁnd new ways of doing things, we won’t want
to do the crap work anyway.

The doctor’s-not-safe
argument


But people don’t trust clouds, right? And the less visibility you give them into the sausage,
the more they’ll care about where it came from.


This is my daughter, Riley. She’s nearly 8 months old. And
since she arrived, I’ve learned about a lot of new things.


(she’s also a bit of a
geek.)


One of the things I’ve learned is that we’re afraid of nearly everything.

Security is a...

Reason to avoid clouds
23%
Reason to move to clouds
43%

No opinion
34%

http://www.thewhir.com/web-hosting-news/102309_IT_Firms_Skeptical_About_Cloud_PEER_1_Study

But security is both a reason to love—and a reason to hate—clouds.

Quick survey.


How many of you use a SaaS-based email for all your
personal communications?
How many of the services you rely on include password
recovery via that email?
Why do you trust the cloud?

http://www.flickr.com/photos/zeusandhera

I was at the doctor’s office last week. They had a wall full of
files. They had 11 doctors and 5 support staff. None of
them were particularly technical. As I waited in the lobby, I
watched two cases of mis-placed or mis-filed data.
How long before the government mandates that this
information be stored in a secure environment?

Explain why it doesn’t have
to be in the cloud?


At some point in the future, the cloud will be the default.
We’ll need to justify why we do things on-site. I’ll want
federated access to those medical records, and whatever
other services are out there.

The we-don’t-need-choice-
anyway argument


Okay, let’s talk about the diversity of platforms.

http://www.ﬂickr.com/photos/dok1/4547024596/
Henry Ford’s invention wasn’t the car—it was mass production. Giving people a much more limited set of choices, in return for
which, they got a much better, more affordable, offering.

http://www.ﬂickr.com/photos/blakespot

Once, there was a huge variety of computers from which to choose. Acorn, Altair, Atari,
Apple, Commodore, Sinclair, Apple, IBM. Not just vendors—entirely different architectures.
Then that changed; a few won. There wasn’t any value in the variety of hardware.

http://www.ﬂickr.com/photos/trekkyandy/345649669/

Then we moved up the stack. We could choose all kinds of devices: video cards, disks, audio
drivers, network cards.

http://www.ﬂickr.com/photos/presbyteer/243436122

Then we chose an OS for its application variety. Wordstar, Wordperfect, Microsoft Word, and
plenty of others lost to the recycle bin of history.

http://shravan15.wordpress.com/

The same thing is true of servers. A relatively small set of OS and machine options is good
enough, because variety below the programming language isn’t particularly useful any more.

http://www.ﬂickr.com/photos/avlxyz/1193082725/

That means the cloud provider can offer a relatively limited menu of offerings, but a rich set
of APIs, and people will be OK with it. Choice is overrated.

The vertical-specialization
argument


Today, clouds are fairly generic. But as the computing
needs of speciﬁc industries become more clear—HIPPA
for medical, PCI for ﬁnance—and with them the sets of
APIs a cloud offers will change.


Salesforce’s Force.com is already specialized for front-
office, CRM-centric apps.


Google is specialized for building startups, web-tier
environments, and APIs like emailing, authentication,
and payment.


Intuit is good for SMB and accounting applications, with
products like its QuickBase.


This is all about targeting and focus for speciﬁc sets of
customers. As providers get more focused—which they’ll
have to do, to survive the coming consolidation—many
of the objections raised by industries and compliance
officers will be overcome.

The cellphone-builds-
accounting-in argument


Because running environments is a full-time job for the providers, they have much better
monitoring and tracking than enterprises will build themselves. Let me give you a quick tour
of Google’s App Engine dashboards.

http://googleappengine.blogspot.com/2010/03/easy-performance-proﬁling-with.html

I can even ﬁnd out what parts of my code are consuming
the most CPU, across all machines.


And even their latency when served to people.

http://www.computerhok.nl/JSPWiki/attach/GoogleAppEngine/GAEQuota.png

It’s a true, pure utility because you pay for what you use.
Remember this picture; we’ll come back to it.

http://code.google.com/appengine/articles/load_test_screenshot.jpg

Here’s a shot of some code running in Google App
Engine. I only know that I’m paying by CPU-hour, or for
units like bandwidth, email, or storage. This could be
one machine whose CPU was used 8%, or a hundred, or a
thousand. I don’t know.

http://code.google.com/appengine/articles/logs_admin.png

I can see the logs for my application. But these aren’t for
a single machine -- they’re for the application itself,
everywhere.

That’s all free. Want some?


And those are free. FREE. Anyone here have that level of
visibility into their application or infrastructure, from
anyone, for any amount of money?

The genie’s-out-of-the-bottle
argument


Okay,

Expense
reports
can
no

longer
enforce
IT
policy.

Wiley GAAP 2010: Interpretation and Application of Generally Accepted Accounting Principles (By Barry J.
Epstein, Ralph Nach, Steven M. Bragg)

IT has enjoyed a high coefficient of friction that has
helped slow the adoption of rogue applications. In the
past, IT was a line item, and the cost of acquiring it at a
high upfront cost stopped all sorts of internal initiatives.

Airfare

DNS

Cloud

Public
transit

Important
research

Hotel


These days, supercomputing is easier (and cheaper) than
booking a ﬂight.


PaaS isn’t common today, but it will catch on fast.
Consider a recent hackathon we ran: 55 coders, 18 apps,
12 hours. Several are live now. I’m betting there are
already a ton of rogue PaaS apps running on Force.com,
being built for the front office without IT’s involvement.


This is the Microsoft rich text editor. Gates once ﬁred
someone for not including it in a build of Windows,
apparently. He understood what that ill-fated program
managed didn’t: give developers an easy way to edit a
block of text, pick a color, print a document, move
something to a clipboard, and they’ll use it. They’ll even
inherit your ﬁxes and improvements to it. The same is
true of cloud providers.

Service What it does
Elastic Compute Cloud Virtual machines, by the hour
Elastic Mapreduce Massively parallel data processing
Virtual Private Cloud On demand machines within internal IT
Elastic Load Balancing Traffic distribution
Cloudfront Content delivery acceleration
Flexible Payments Service Funds transfer & payments
SimpleDB Realtime structured data queries
Simple Storage Service Eleven nines redundant storage
Relational Database Service On-demand RDBMS
Elastic Block Store Block-level storage (file system)
Fulfillment Web Service Merchant delivery system
Simple Queue Service On-demand message bus
Simple Notification Service System for sending mass notifications
Cloudwatch Monitoring of cloud resources
Mechanical turk Humans as an API

This division between PaaS and IaaS is a bit of a fiction. In fact, virtual machines are just one
of around twenty “cloud services” Amazon offers – called EC2.

Service What it does
App Engine Executing Python or Java code
Bigtable datastore Store data for very fast retrieval
Calendar Data API Create and modify events
Inbox feed API Read a GMail inbox
Contact data API Interact with someone’s GMail contacts
Documents list API Manage a user’s Google Docs
OpenID single signon Use Google authentication to sign in
Secure data connector Link Google Apps to enterprise apps
Memcache Fast front-end for data
Image manipulation Resize, rotate, crop & ﬂip images
Task queue Queue and dispatch tasks to code
Blobstore Serve large objects to visitors

The same is true of App Engine - though these are functions called from code, rather than
services you pay for separately, they’re still more than just the code.

http://www.ﬂickr.com/photos/jackol/133765382/

These services let developers and the line of business
stand on the shoulders of giants. The ecosystem
surrounding the cloud environment provides a rich set of
APIs—just as the windows ecosystem, years ago, gave
developers a set of foundation classes.

The risks


There’s a downside to all this, of course. I ﬁrmly believe
that we’ll use computing, not computers, in the future.
But I remain concerned about one aspect of it,
particularly in free-market environments where there’s
no regulation.

The cloud
neutrality problem.

http://jimvoorhies.com/?p=1942

It’s the same risk that we face from net neutrality. A
small number of providers, whose users are dependent
on them for their environments and charge a recurring
fee, can signiﬁcantly limit the choices—and competition
—in the market.

The lesson of the answering machine
Making Steve Wozniak really angry


Iʼm going to ﬁnish with a story about monopolies and
innovation, but with a different point this time. Itʼs a story Steve
Wozniak used to illustrate the perils of an unregulated public
Internet, and I believe it applies to a computing-as-a-utility
world too.

Dial-a-joke.


Apple co-founder Steve Wozniak liked to dabble in a lot of things. In
1972, he wanted to set up a dial-a-joke service:

http://www.ﬂickr.com/photos/deeleea/369701296

People would call his number, and get a “joke of the day” from a
recorded message.

“This was 1972 and it was
illegal in the U.S. to use your
own telephone. It was illegal in
the U.S. to use your own
answering machine. Hence it
also virtually impossible to buy
or own such devices.”


But there was a problem. The phone company—AT&T, again—was
also the company you bought equipment from.

$700/month

And this cost a lot of money.


While AT&T offered a service that was useful, it didn’t allow Woz to
innovate by building something new atop its existing products. It
was an example of a service gone too far.

The balance you have to strike.
Leverage cloud models, but control your destiny.


And this is the downside of clouds. As IT professionals, you need to
embrace the changes that computing as a service offer—but at the
same time, keep control of your own destiny when it comes to
differentiating your business. This is the balance you have to strike
between public and private, dedicated and on-demand, proprietary
and standards-based. It’s why you need to control what makes you
special, and optimize everything else.

http://www.ﬂickr.com/photos/sparkys/3434382326/

In the end, clouds will look like airlines. Every country
has one (plus a second for government and the military.)
They’re regulated for safety, pricing, and other things—
though that varies by country. They have some
standards, particularly when they connect to one
another, for stuff like connecting passengers and
forwarding luggage. But below the level of the individual
ﬂight, they’re free to do what they want, and passengers
don’t have that much insight or say in how things are
run. In big markets, there are several competitors. There
are vertical offerings for things like medical evacuation,
or rental, or private pilots, or densely populated urban
areas.

Within ﬁve years, we won’t
care about virtual machines.
(Did I change any minds?)


Thatʼs my argument, in roughly 45 minutes. Howʼd I do?

Thanks!
@acroll
alistair@bitcurrent.com


The move to turnkey computing

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie The move to turnkey computing

Ähnlich wie The move to turnkey computing (20)

Mehr von Alistair Croll

Mehr von Alistair Croll (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

The move to turnkey computing