Cloud Capability: Dr Werner Vogels Amazon CTO (Google Atmosphere session 3)

DR. WERNER VOGELS: Thanks for having me here.
So in contrast to Nick, who just gave you the vision and
maybe some of the history and the future of cloud computing,
I'm going to talk to you about reality, what is
going on right now.
So Amazon and Amazon Web Services are, I like to
believe, the dominant provider of infrastructure services.
That means really at the lower level of the stack where you
get the pure utility--
not the application level, not the fancy applications which
may look more to you like outsourcing--
no, really where we talk about cloud computing as a utility.
And so Amazon's one of the dominant providers there.
And I hope that by now you know enough about press and
stuff like that that you know that we're playing there and
what kind of services there are, so I'm not going to do
the sales talk on this.
What I'm really going to talk to you about is why are
customers or why are enterprises picking the cloud
and for what reason?
So we'll go through a range of our customers looking at what
is the motivations.
Before that, I want to do a bit of an intro around Amazon
and why actually we got into this business in the first
place, why it was a natural evolution why
Amazon ended up here.

I'll skip that one.
But first of all, I want to dispel a myth, namely, that
Amazon is just selling off excess capacity, that we're
just shifting off our garbage to you guys to use while we're
not using it.
And that when Christmas comes around and actually Amazon has
a bigger than expected Christmas, which is almost
every year, you will be out of luck.
This is not the case.
We entered into this utility business as a business by
itself, because we believe there's a huge opportunity
there not only from a business perspective but also because
Amazon has unique technologies in terms of scale and
reliability that we can exploit as a very low-cost,
high-volume business.
This is what Amazon is good in.
We have our roots in retail.
We know how to do a very low-cost, high-volume
business, and that is what the utility
business in reality is.
And especially at the infrastructure level, things
need to be cheap and as cheap as possible, and Amazon is
really good at that.
So, no, we're not shifting our garbage to you.
This is a business by itself that may be one time be easily
as big as our retail business is right now.
So I'm often asked to give some sort of definition--
what is cloud computing?-- given that all
the hype is out there.
I think there's many different definitions out there.
I like the one that Gartner put out about a year ago.
It's a style of computing where massively scalable
IT-related data capabilities are provided as a service
across the internet-- and the internet can
be private or public--
to multiple external customers.
And the key points there are massively scalable IT-related
capabilities as a service.
And of course, you have multiple customers.
But I do think that actually this definition misses two
absolutely essential points about cloud computing.
These services and resources need to be available in a
pure, on-demand fashion.
You need to be able to acquire them whenever you need them.
And when you no longer need them, you need to be able to
release them instantly.
You do not hold, nor the resources, nor the capital or
the operational expense associated with it, when you
are not using the resources.
So on-demand is an essential part of cloud computing.
And the second point which this definition is missing is
that it needs to be a pay-as-you-go model.
It needs to follow the true utility model that you only
pay for those resources that you really use.
So those two things actually, if you look at many of the
benefits that cloud computing will bring
you, are core there.
I mentioned not only the elimination of capital but
also the reduction in operational expense mainly
come from the fact that you only use resources where you
need them, and you do not pay for them when you do not use
those resources.
Now, Amazon has been in this business of providing these
infrastructure services for more than three years now.
We launched our first storage service in I think it was
spring of 2006.
In August, we launched our compute environmental called
Amazon EC2, the Elastic Compute Cloud.
Two months later, Business Week puts Jeff on the front
page, basically calling him crazy.
By now, we know that if magazines that are no longer
in business start calling our CEO crazy, we're
on a very good path.
We're still called Amazon Web Services, and
they are called what?
Good.
No, but it's an indication that maybe three years ago
this may have looked like a risky bet, where Amazon was
clearly the innovator for the
technologies that we had developed.
But there were things going on I think in a larger economic
setting that pre-date this, actually both economically as
well as also technology-wise.
Economic, I think the increasing competition, the
shortening time lines that products
have to be built across.
And we heard earlier already about the power of the
consumer basically deciding whether or not your products
are going to be successful brings enormous uncertainty to
the market.
You do not know on forehand whether your products are
going to be successful or not.
Maybe 10 years ago, you could predict that.
Now, that model is gone.
And for that, you need new resource models.
And it's essential that you're able to acquire and release
resources on demand and actually use all those core
competencies to actually work on those pieces of your
business that do not differentiate yourself from
your competitors.
Therefore, Amazon internally, we had many of
these examples actually.
So there is an elephant in the room here.

If you look at Amazon's history, we have a history of
building platforms. Maybe you all know us as--
I hope you all are retail customers of ours.
Is there somebody that is not an Amazon customer?
Can I talk to you later?

So Amazon has been in the platform
business for a long time.
So we allow others to sell on the Amazon platform.
We also built a very large enterprise
e-commerce services platform.
That happened about 10 years ago when we realized that to
actually get additional economies of scale that would
allow us to reduce cost and then, with that, lower our
retail pricing, we needed to get way beyond the scale of
Amazon itself.
And for that, we built an e-commerce platform, complete
service-oriented architecture, on which some of the world's
largest e-commerce operations run.
Not just Amazon, but for example, target.com, or here
in the UK, Marks & Spencer, Mothercare.
And all of those even may have functionality that Amazon
itself doesn't have, like multi-channel, in-store
terminals, and things like that.
All of that runs over Amazon technology.
But it allows us to get to a scale that is way beyond what
amazon.com, which is already a significant operation,
actually needs.
So with all of our innovation and all of our hard work, we
went through a traditional enterprise architecture
evolution pattern.
Lots of redundant operations going on, lots of redundant
innovation going on, because many of our engineers were
given very complex tasks, namely, to be able to reach a
level of reliability that was not seen before.
We should be able to lose a complete data center, and the
performance towards the customer
should not be affected.
We should be to be able to lose two data centers, and
maybe the performance to the customer could be affected,
but the functionality should still be there.
And that means that all the engineers who were actually
working on similar problems, instead of that, they were all
working on building better products for our customers.
About 70% of the time, they were actually working on
infrastructure matters.
And they were all working on somewhat similar problems.
It's a traditional pattern in that you actually then take
stock and drop this redundant development that's going on
into a shared services platform.
See, this is a complement to Nick's earlier pictures.
This is from a brewery in Belgium where they actually
kept a generator around that they were using at the
beginning of this century.
But it must be very obvious to everyone that having a
generator does not make you brew better beer.
It was just the cost of doing business.
And we were following a fairly similar pattern in that most
of our engineers were concerned with things that
were just the course of doing business.
And with this new shared services platform, we could
highly optimize that and allow engineers to start brewing
better beer.
So there are four principles around it that were essential.
One of them, that this stuff needs to be able to scale up
and down in order of minutes.
We had a history, actually, where engineers--
and we were really good at this--
if they would ask for server capacity, they would get it
within a matter of hours.
Four to five hours would get you a completely provisioned
server if you had asked for it.
However, that time frame is not sufficient to incent
engineers to also release that capacity again when they no
longer need it.
And it turns out that they were actually hoarding
capacity with the idea, well, just in case
you would need it.
And by shifting this allocation of capacity into a
matter of minutes, this virtual capacity, we see the
right behavior starting to happen.
You're able to access capacity or request as much capacity as
you need in a matter of minutes and then release it
when you no longer need it.
And we see then that also-- and this is one of the things
that we're also seeing happening with many of our
customers--
is that the moment they move to this model, they increase
the level of automation that goes with it.
Many processes that may have been hand-managed before, if
you can do it at this level through compute for complete
automated API, you can automate the hell out of it
and with that achieve levels of efficiency that were not
able to reach before.
Other point was that we really thought that this should be a
low-cost, utility-grade business approach.
So only pay for that what you use.
Of course, given that many people are going to build
their business on top of this Amazon infrastructure and
Amazon itself runs on top of it as well, reliability is one
of the top priorities.
As is security.
Given that we are providing these services at the
infrastructure level, more than thinking about privacy
and end-to-end security, for us it was important that we
would build into this layer many different security
technologies that our customers could be able to use
to build their own security tools or to map between their
policy controls and the activities that you need to
take at the lower layers.
Now, this is the set of services.
You can go to aws.amazon.com, and you can
find more about them.
They're really rooted in compute and storage with a
range of other services surrounding that.
But I'll skip that mainly.
One thing that I do want to emphasize, and especially
because this technology was launched specifically for our
enterprise customers, was that one of the feedback that we'd
gotten from customers was that, oh, the
public cloud is great.
We really love that.
However, I've already invested an enormous amount of effort
into having my own policy mechanisms, my own management
tools, and all of those work well in my data center.
They don't work that well if I have to include the public
cloud into it.
So we developed a technology called Amazon's Virtual
Private Cloud, which allows you to wall off a piece of the
cloud, give it your own network addressing mechanisms,
and then connect that back to your data center, making it
look as if this piece of the cloud is part
of your data center.
And you can then start putting any of our
compute units in there.
You can make it scalable as much as you want to.
But this is specifically targeted towards customers
that already have existing data center infrastructure and
then are able to build that out seamlessly into the cloud
without losing the ability to still use your standard
management tools.

So there's actually four points which I want to
emphasize on the advantages of moving to the cloud.
And most of these are feedback from our customers, some
different reasons why customers picked
moving to the cloud.
One of them is, of course, the cost advantage.
It eliminates capital as well as reduces operational cost,
because you're only paying for those resources that you
really use.
But remember, if cost is your only concern, everything looks
like an expense.
It doesn't drive innovation.
And what I hear actually from many of our enterprise
customers is that although they like the cost picture,
the agility side of things is much more important, the fact
that this allows you to think about resources.
Without that you have to allocate them up front,
without to think about that these are
actually constrained resources.
No, there are no longer constraints on the amount of
compute or storage that you can use for any new product or
existing product that you want to move into.
Time to market, the reduction of that time to market, is an
essential driver for customers moving to the cloud.
Actually, can I go back to that slide still?
Thanks.
The other heavy lifting I think that comes--
it's obvious because most of the utility part addresses
that-- but also many customers are picking this as a
foundation for new architectures.
The IDC study was mentioned earlier about what percentage
of existing IT would move to the cloud.
The more progressive part of it, the more indicating part
of that study was that the expectation was that about 50%
of new IT would start off in the cloud instead of just
doing the lift and shift of moving all IT to the cloud.
So adoption is like this where now early this year, it was 52
billion objects in Amazon's S3.
That's our storage service.
We're now 82, where I expect we easily are more than
doubling year-over-year demand of storage that our customers
are using there.
So while Amazon--
when we started off, we really had the idea that these may be
more targeted towards younger businesses.
We have to be honest about that.
We really thought that the businesses that would be
looking at innovation would be the ones that will be jumping
on board quickly.
And that was the case.
Startups were clearly our earliest customers.
It took however, only a few months after the launch of
Amazon EC2, our compute units, before enterprises started
realizing that this was gold.
And after that, more or less a few months after launch of
EC2, enterprises have been the major users of the Amazon
cloud ever since.
And the early adopters were clearly those that already
knew how to use these large compute resources.
[UNINTELLIGIBLE]
pharma, financials clearly knew what to do with large
compute units that they could extend their own world with.
Many of our partners came on board quickly as well.
You can get Enterprise Linux from these kind of customers
or fully supported databases.
All of this software is reality now with licensing
models that also address the cloud, although there's a
difference in licensing models.
I think many companies, although they are thinking
about cloud software and moving their software to the
cloud, I think there's still a lot of work to be done around
making sure that licensing models actually work for
customers, as well.
I think in this case, IBM has done a great job in that they
allow you to develop inside the cloud with their
technologies for free.
The moment you go into production,
you have two choices.
You either get a per-hour surcharge on top of the Amazon
costs that you get-- let's say normally the Amazon cost is
$0.10 per hour, and in that case it would maybe be $0.12
or $0.14 per hour, depending on the software that you run--
or you can take some of the internal IBM licenses, and
they provide a conversion table to go over to the cloud.
The services in traditional servers, middleware ecosystem
is also interesting.
Here you see many of the traditional enterprise
software vendors.
BMC recently launched the integration of the Amazon
services in all of them, management software.
And that's traditional.
TIBCO took the other approach.
Instead of converting their older middleware software to
the cloud, they decided to build a completely new
platform, really targeted towards new scalable IT
running in the cloud.
And I put the other ones up.
They're more or less also platform players.
The reason why I put them up there is that there's often
the notion that if you go up in the stack, if you go
towards a platform approach, you automatically get locked
into the cloud.
Well, for example, a company like Stax gives you standard
J2EE services in the cloud.
If you have applications that are built against strict J2EE,
you can immediately move them in the cloud by using
container technology like this and get then this automatic
scaling over these AWS instances.
Another player there, for example, is Spring and
SpringSource with their Java technologies.
Many of the SIs have jumped on board immediately.
They provide all sorts of services in helping enterprise
customers evaluate what applications within your
organizations are suitable for moving to the cloud.
All of these now have a cloud practice as well.
Here's a number of examples of customers.
The one on the left-hand corner is the NASDAQ.
They had the idea about building a new application
that would actually allow their customers to analyze
market data.
Although they thought there was a market there, they
didn't know for sure.
But to be able to allow it, they would have to retool
their back end and invest millions
and millions of dollars.
And that retooling of the back end would take maybe a year or
two before they could do this.
Instead, they took a very simple approach by just
dumping all market data into the Amazon storage service and
then built a Flash application that would access their data.
Now, if this application would not have been successful, they
would have been out of pocket a bit of money for the
developers of the Flash application, but it clearly
didn't run the risk of investing a lot of cut capital
into their back end to get these things done.
The other example there is Forbes running real-time stock
quotes out of New York over this platform as well.

Some companies picking us for time to market.
In this case, I put up the example of The Guardian.
When they put up all of the materials and piece here--
and they invited their customers actually to come and
mark up the expense reports--
they immediately realized that they could not do that on
their own platform, because there was an expectation that
many of their readers would show up.
And so they went and did it on our platform.
Bild is another story.
Bild wanted to go into the market of video citizen
journalism.
They went to their own IT department, asked how long it
would take to get the site up.
IT department said eight to 12 months.
That was clearly something after which an internet idea
was dead in the water.
They went with the Amazon services, with cloud services,
and four weeks later, they were up and running.
But also because it allows you to iterate quickly on ideas
that you have. So you may have this idea.
Four weeks later, you have a minimal site out there, and
then you start iterating on that.
Internet scaling, it's another reason why many of our
customers actually move to the cloud.
The top example is one that I like very much.
It's the Indianapolis Motor Speedway.
If you're into cars--
or even if you're not into cars-- if you're into internet
applications, you should visit this website when one of those
races is going on.
They have a massive Flash application, eight video
streams running parallel.
You can pick from which cockpit you
want to get the view.
And then all sorts of biometric data
and things like that.
Really an absolutely cool application.
As you can imagine, millions of people come to use that
application.
Unfortunately, it only runs three times a year.
So how do you allocate capacity for that?
How do you prepare for that?
Playfish is a UK-based based company, becoming quickly one
of the largest gaming companies in the world.
They build for the Facebook platform.
And they already demonstrated that if you build for social
networking, you have to build for success.
Maybe in the past, your nightmare was I throw a party,
nobody shows up.
Now the nightmare is I throw a party, and everybody shows up.
One of their latest games, Restaurant City, they
estimated that within two weeks, they would have 150,000
concurrent users.
It turned out to be 8 million.
And I think their largest game runs something like 16 million
concurrent users.
And so you have to be prepared.
And we see this, actually.
If you look at many of the new marketing companies that are
being built, there will be some marketing.
Often it will include video.
Marketing will include
integration into social networks.
It will include gaming.
All of these kind of things you need to run at the scale
that only the internet can provide you.
Traditional enterprise computing, here I picked two,
Eli Lilly and Pfizer.
Eli Lilly uses the cloud to do collaborative drug trials.
Pfizer does traditional protein docking.
They use--
what is it-- about 500 nodes at a time.
Eli Lilly stamps out multiple 64-node clusters in the cloud
to do this collaboration.
Pfizer uses VPC, so they hold it within their own data
center environment, even though it sits in the cloud.
Eli Lilly, because it's a collaborative effort,
specifically puts these things out in the cloud, in the
public cloud, and then allows data to flow back to their own
data centers.

On this one, I want to pick out actually Netflix.
As you may know, Netflix is a competitor of Amazon.
We both play in the video on demand business.
And though I heard earlier on that someone still uses DVD
players, Reed Hastings gave a presentation about two weeks
ago, an interview to Forbes, where he predicted that within
two years, video on demand--
meaning Netflix-- would overtake the DVD business.
And so DVD business is going out.
Video on demand is moving.
The reason for Netflix moving onto the Amazon cloud was for
reliability purposes.
They had a number of scaling issues, had some outages.
They looked around what was best in class for
infrastructure services.
Ended up with Amazon.
Probably had to swallow a little bit when that name came
to the top, but decided to go with Amazon
and with these services.
Because the scale of this and the reliability is clearly
without any doubt.
Some customers pick us for security reasons.
And during the panel, I'm sure we're going to take
questions from you.
I'm happy to dive deeper into that.
Customers can get any of the security
clearances that they require.
In this case, they're health care companies,
HIPAA-certified.

Folks pick us for other reasons, lower operational
cost. In this case, Intuit with TurboTax wanted to make
sure that on April 15--
in the US, there's this moment that everybody, all consumers
have to fill in their tax forms--
they needed to be able to be ready for that scale.
They used Amazon for that.
Fire up 2,000 instances, emulate 200,000 browsers
hitting your site at the same time.
S&P moves all of their code into the cloud, at night in
our cloud, to test it there.
Many different reasons.
Companies enter the cloud not only for the number benefits
that they're seeing but also because cloud is a marketplace
for reselling your services.
Many of the telcos are thinking about how to actually
resell and how to repurpose their IP to actually the
leverage in the cloud and to allow all of us to leverage in
the cloud as well.
That said, this is still day one.
This is disruptive technology.
The way that we will impact enterprises and the way that
we will see massive innovation happening on top of this,
there's still a long way to go.
That also means that probably you're going to later on ask
me for predictions, how the world is going to look like.
That will cost you $0.10.
And I'll give you any answer, and maybe if you ask this guy,
you will get a more reliable answer than asking me.
I think we will see at the infrastructure level certainly
a number of providers arising over time.
I think these will be the five different things in which
these providers will be compared.
I like to believe some of these are absolutely, 100%
must, you must match the 100% level.
There's only 100% security.
There's nothing else.
But maybe you're willing to sacrifice some scalability for
some cost-effectiveness, or maybe you're willing to pay
less if sometimes a provider's allowed to lose your data.

That was a joke only for insiders, actually.
So I think the matrix will exist over time.
And this is also how IT jobs will change over time.
I think managing your providers will actually be
essential there.
This is how so many changes will happen around these four
or five different properties.
That said, all you need, given that it's a complete
self-service, pay-as-you-go model, the only thing you need
is this URL and a credit card.
Thank you.