B1 中級 5277 分類 收藏
開始影片後,點擊或框選字幕可以立即查詢單字
字庫載入中…
回報字幕錯誤
TONY VOELLM: I head up the Google Cloud Security
Performance and Test Team.
I've been working on Cloud for over two
years now up in Seattle.
And don't let my title fool you.
It says "Engineering Manager," but managers
at Google are different.
I really do get my hands down in the code.
In fact, I checked something in last week, and about five
minutes later, somebody on my team fixed it and checked it
in again, so.
[LAUGHTER]
TONY VOELLM: I've done a bunch for Cloud.
Some of the things that are externally visible for Cloud
is I created the Google Compute Engine Units--
GCEUs.
And we'll talk more about what Google
Compute Engine is later.
Being the engineer I am, I thought, wow, GCEU, it's
really cool.
We should call that GQs, because who doesn't want GQs--
or, which engineer doesn't want to be GQ.
And now you know why I'm an engineer.
OK, great.
So here's what we're going to do.
We're going to talk about cloud computing.
So I'm going to take a quick step back, talk a little bit
about what cloud computing is.
I'll take you through some history about how we got to
where we are today in 2013.
This is a history of cloud computing.
Then I will definitely take you through the Google Cloud.
I'll give you pivots of what the Google Cloud looks like,
how we think about it, how the industry thinks about it.
I'll run through a series of demos.
And then, to prove I'm an engineer, I'm going to take
you through the pitfalls.
And this is how you know I'm not a marketing person,
because a, my slides are not pretty; and b, I'm going to
tell you why things may not work for you
from time to time.
And in the end, I'll just wrap it up with
the Team and questions.
So with that, let's dive in.
So what is cloud computing?
It's a good question.
I had this question two years ago.
And in fact, I probably still have this question today.
But one of things that I did to try to figure out what this
industry is, is I started looking different places.
I go do web research, Google search.
I looked up at How Stuff Works, and they had a really
interesting definition.
They talk about remote machines owned by another
company, and like maybe your email and word processing
would be out there.
And this seems like a really dated definition, but it's
actually still fairly accurate.
I did things like go out to conferences, because there are
several conferences that happen throughout the year
around cloud computing.
And in there, you'll see interesting terms, like Hadoop
elastic environments, grid software--
there's all these terms that start to pop up.
I even went out and started to survey my peers at Google,
like, what do you think cloud computing is?
And you can see down here, they start talking about, oh,
it's this computation that you can do in the cloud.
You don't have to worry about stuff.
So what I did is I said, OK, well, with any definition,
let's pull together the properties of cloud computing,
because there's certain things we're hearing often in these
definitions.
You know, one was nothing--
nobody cares where it is.
Everything's accessed over a network.
So cloud computing is something that
happens in the network.
That's sort of like the beginning of what cloud
computing is.
The second part is a really important
part, which is utility.
You can turn it on or off.
You pay for what you use.
And when it's not on, you turn it off.
It's like a light switch.
So if I want a database now, I have a database.
And if I don't want a database in five minutes from now, I
turn it off, and I'm not paying for it.
There's an elastic component where resources grow and
shrink on demand.
And you've seen this many times across like YouTube
scalability.
We broadcast the Olympics.
And whether one user is watching, or 8 million users
are watching, it all seems to work.
And so there's this elastic component on the cloud that.
grows and shrinks on demand.
For sure, it's programmable.
Programability is an important aspect of Cloud.
And then access control models.
So here's where there's some pieces we'll talk about later,
where like software as a service, versus you developing
your own code.
And platform and infrastructure as a service
layers, where access models are different.
There's some models where the end user owns the control, and
there's some where the person providing the
service owns the control.
But there's some method of controlling
access to data and resources.
And while not required, there's this thing that often
comes up, which is multi-tenant.
Your workloads run side-by-side
with somebody else's.
Some companies, this can be concerning--
why is Company A and Company B running on the same server?
We're competitors.
We don't want our data anywhere near each other.
And it's really the cloud providers that create this
partition or this barrier between those workloads.
So there's no flow of data from one to the other.
And this is called multi-tenancy.
So I tried to be really smart.
I'm like, OK, that sounds really good.
So let me give a definition of cloud computing that tries to
roll in all these sources of information.
And my definition is it's a set of programmable resources
that's pay-per-use.
It happens over a network.
It's elastic.
And it removes the developer from having to worry about the
hardware resources, the operating system, or all these
minutias that she doesn't want to worry about.
And she can just focus on delivering the application
that she wants.
And it's there, and it grows and shrinks on demand.
So that's my definition.
So that's cloud computing in a nutshell.
So here's a little mini-quiz.
So I'll just take a quick show hands.
I'm only going to go through a couple of questions to see if
things are already resonating with everybody here.
So is Gmail cloud computing?
Yes.
It could depend on perspective.
One perspective is Gmail is a hosted software service that
companies can buy.
You can buy Gmail.
And for some nominal fee per month, you can host your
mailbox there.
So on the upper end of software as a service--
this is where Google started--
yes, Gmail, I would say, is cloud computing.
Now what about hosting Python applications.
Is that--
show of hands-- is that cloud computing?
Yes.
Yeah, it has the programmable aspect we talked about.
It's elastic.
This is where Google App Engine enters the picture.
Here, let's try one more.
Are physical servers hosted by a hoster--
is that cloud computing?
Yeah, it depends.
Yeah, this is the one that gets sort of tricky is--
if you can on demand request these servers, and have them
go away on demand, then you sort of enter into the cloud
computing, versus just pure hosting.
We tried this whole thing in the '90s called application
hosting and server hosting.
And so, what's different today is this
whole elastic component.
And you might be thinking already, like,
why is all this important?
Why is this definition of cloud computing important?
And so I asked that question, too, actually.
Like, why is this important?
And so, I went out, and I found this "Forbes" article.
And I realized that not only can Google help you find
dating sites, we can also help you on your dates.
Where it says, "some fake it to make it," where there's 17%
of us, apparently, that on our first dates lie and tell
people we know what cloud computing is.
So I'm here to help you with your dating.
That's really what this is all about.
So cloud computing.
OK, so let's go back.
So let's go back and let's talk a
little bit about history.
So computers--
they've been there for a while.
Almost 60 plus years now.
Hard to believe we've lived with technology that long.
But in 1961, John McCarthy, also sort of dubbed as The
Father of AI, was living in a world where there were very
few computers relative to today.
There were 6,000 computers.
And he had this thought.
He said, computation one day will be a utility.
For him, this was really important, because there were
so few of them, and it was a constrained resource.
But it kind of made sense.
He was predicting the future, that one day we
will get to a utility.
Now the way we got there is very different
than perhaps he expected.
But nonetheless, some credit goes to him in terms of
thinking about, yes, computers could be a utility one day.
But before we could get there, something had to happen.
We had to have the internet happen.
We didn't have an internet in 1961.
We had some sort of point-to-point stuff.
People were trying things out.
But it wasn't until 1969 that ARPANET, the predecessor to
the internet, happened.
And at the time, transfer speed between computers was 50
kilobits a second.
And to give you an idea of what that actually means,
because it's hard to sometimes think about all these bits--
your cell phone's about 2000 times faster than computers
could talk to each other back in 1969.
Some other things had to happen.
We had to have the microprocessor revolution.
That started roughly in 1971.
And so after the microprocessor revolution, the
internet's kind of there.
We have these acoustic couplers and modems.
In the '80s, we have the BBS era.
This is where you have laptops.
They were called luggables.
You'd carry them around like this.
They were like 67 pounds, or something like that.
This is an example, it's the Kaypro.
But something interesting happened where services
started to show up, like CompuServe and GENie.
And you would dial up, and for $0.10 a minute, you could
access this super awesome service.
And all you wanted to do was find out where
the free BBS was.
So you could go connect to this free thing, and start to
share files or data.
And so you'd go connect up to something, like Koala Country,
which was free.
And so there was this whole sort of culture around the
internet starting to happen--
connectivity, sharing.
Data should be universally accessible.
So roll time forward a little bit.
So from the '80s, if that was our BBS era, we really needed
the '90s to happen, because these are pretty important to
where we are today.
So in '93, if you can believe it, this
is the Mosaic browser.
It was first to enter in the scene, and make the internet a
lot more accessible.
Prior to that, we all ran LAN line tools, like Archie and
all these things he hope to forget one day.
And users started showing up.
And there were a few users.
There were about 25 million users connected up to the
internet in '93 roughly.
By '95, something interesting happened--
we had 6 million hosts serving data on the internet.
And so we had 25 million users, and so you have to
figure the users have grown a lot.
And you'll see this on the next slide.
Now I'm sure I'm not going to pronounce his name correctly,
so Ramnath K. Chellappa, I apologize if you ever watch
this video.
But this really smart guy was out there, and gave what's
often deemed to be the first definition of cloud computing.
Where Ramnath, he says, cloud computing-- he basically says
that computing is going to be a paradigm where computing is
determined not by technology, but by economic decisions.
Yeah, look at that.
Isn't that surprising--
economic decisions.
And when we were all really flush with cash in the late
'90s, nobody was too worried about server rooms.
And the fact that 10% of the CPUs we all owned were
actually being utilized, 90% unused was just fine.
We had plenty of money to run all of the air
conditioners and power.
But computing resources grew.
2000, we had 72 million hosts.
And then by 2006, we had almost four million hosts on
the internet.
And that is astonishing growth, if you think of how
fast that happened.
And then the number of users that are using these also
grew, which obviously grew the servers.
And we had like 461 million users in 2001 using internet.
Pretty astonishing.
So 2006 was kind of a magic year.
This was the year where people like Eric Schmidt, our
executive chairman of the board for Google--
super smart guy--
started to piece things together, and started
connecting together these ideas of
software as a service.
In fact, by all my reading, he was deemed one of the first
people to ever use the term "cloud computing." Because as
I mentioned before, in the '90s, we tried app hosting.
Nobody wanted to hand over their data.
Nobody wanted us to run their applications.
But somehow, magically in 2006, when you called it
"cloud computing," everybody seemed a lot more comfortable.
At least, beginning to be comfortable with this idea.
And then also in 2006, Amazon launched Amazon Web Services.
And this was the first provider that was out there.
And I love this picture here, because it's kind of like
Amazon's the baby--
bright-eyed, I'm new to the party.
And the older sister is really looking there, like hm, didn't
we try this in the '90s called application hosting?
And as the way with technology, sometimes if you
know nothing, you're going to win, because you're just sort
of looking at it from a different perspective.
There's this whole notion of innovation cycles that you can
read about that happen over and over again in technology.
So when did Google enter the picture?
So Google entered into this picture in 2008.
We launched two things kind of simultaneously, hitting
different parts of helping to make the cloud happen.
One part is we launched Chrome beta, which is astonishing,
because just recently it looks like Chrome has become the
most popular browser in the world.
And that's in like four years, which is astonishing growth.
But Chrome came out in beta.
And Google App Engine-- this place where you can host
Python and Java applications--
came out.
So we're trying to tackle the cloud from two parts.
One was the usability end, where we're making the
internet easier to use with the browser.
And we were starting to create a platform where you could
actually create applications and host
applications on the internet.
In 2010, we launched actually Google Cloud Storage.
I can't tell you the number of tera x--
petabytes--
whatever happen to be in cloud storage.
I can tell you it's sufficiently big.
So Google Cloud Storage is an object store in the cloud.
It stores a ton of data.
There are many, many places you probably hit this, whether
you go to a website and images show up, or things like that.
But we had launched that service actually in 2010.
Then 2011, we took App Engine out of beta.
This is where you could tell Google was very serious in
this market.
We put down an SLA where we said, hey, we will guarantee
certain sets of APIs will be around.
We'll have a deprecation policy, and so forth.
Very important to all of us as developers and engineers that,
if you're going to build it, it will still be there a year
from now if you're betting your business on it.
And then in 2012, last year, we shipped a couple of things.
We shipped something called Google BigQuery, which is this
amazing query technology.
You can query terabytes of data in a second.
I know, that's astonishing.
We have hosted MySQL in the cloud, and I'll talk more
about this later.
And we launched Google Compute Engine, which is our virtual
machine offering in the cloud.
And I noted here that it's limited preview.
Google differentiates here.
Limited preview means there are workloads in production.
People are paying us.
And we are happy to have you come and try Compute Engine.
But we're just not going to open up the doors
fully open just yet.
But we are happy to help you use it.
Beta is different.
Beta means we're not totally sure.
Maybe it's going to change, and so forth.
And this is something that has kind of confused the market a
little bit, where people think, oh, you have Compute
Engine but it's in beta.
Actually, it's in limited preview.
People are paying us money to use the service.
So we go through this whole history, and then I learn
something new from Eric.
So we learned all this technology stuff, and I
thought I was really smart with my
definition of cloud computing.
But it takes somebody like Eric to really bring it home.
He goes, you know, I'm not sure anybody knows what cloud
computing is, but I do know one thing--
it's a marketing term.
So there you go.
It's a marketing term.
So if anybody asks you what cloud computing is, you can
confidently now answer--
it's important to my dating, and it's a marketing term.
So let's talk about the stack.
And oftentimes, cloud computing is
thought of as a stack.
A set of sort of tiered services, from the lower
level, which is called infrastructure as a service--
IAAS--
which is maximal flexibility and maximal complexity.
This means you're your own administrator.
You have to have your own backup plans, retention plans.
It's a lot of work.
In fact, a lot of times, it's sort of perceived as the IAAS
layer is like taking the server from underneath your
desk, and sticking it up in the cloud.
Whatever that means.
AUDIENCE: [INAUDIBLE]
TONY VOELLM: Hold that thought.
Ask me that later.
Somebody said without their privacy.
Actually, I disagree with that, but I'll tell you why I
disagree with that later.
And I'll show you some of the things that Google is doing to
be very, very, very careful about end user data.
And I'll talk about some of the messages around that.
But infrastructure as a service is really the thing
we're familiar with.
It's interesting, whenever I've given talks about this
next layer up, called platform as a service, a lot of people
ask me where the server is.
The platform as a service tier tries to remove the user from
this infrastructure layer, but you have a different
programming model.
And in fact, it's very hard for developers to think in
this model.
But if you can get into this model, it's very powerful.
And then at the top of this tier--
I'll go through each of these little bit more-- is software
as a service.
This is where you have things like Google Drive, Google
Docs, Google Spreadsheets, Gmail, YouTube, all these
things that you can use.
At the service layer, you can even build on top of them.
They are programmable.
You can put JavaScript into your Google Spreadsheets.
And you can pull data from the lower tiers in the
infrastructure layer up.
And there's all these examples out there that
allow you to do this.
It's super cool.
But that's the software as a service tier at the top.
What's interesting about SAAS is it's less flexible, but
it's lower complexity.
So it's easier to use, but you don't have perhaps all the
controls you want.
So there's trade-offs at each of these layers.
So let's talk about each one just a little bit more.
And then I will take you into how the Google pieces plug in
to these tiers.
So infrastructure as a service layer.
As I mentioned, these are the building blocks.
These are the pieces that we know today where we talk about
storage, like I have disks.
We talk about computing resources.
I have machines.
We talk about databases.
I have databases.
And this is the layer where a very thin layer will come on
top of it, and allows you to access it over the cloud.
But it looks familiar.
I'll show you an example later of Compute Engine where we can
log into Google Compute Engine.
It's a machine in the cloud.
I get a UNIX prompt, and I can do stuff like configure web
servers, or run computation workloads-- whatever I
want to do on it.
There are some terms here, too, that you watch out for at
the infrastructure layer.
Because there is all this decision-making to be made,
there's this notion of zones.
Like, where are these resources?
And so, are they in the US?
Are they in Europe?
Where do I want them to be?
How do I have disaster recovery?
And so, yes, all of this complexity suddenly enters in
at this layer.
Platform as a service is different.
So this is things like Google App Engine, Salesforce.com,
Amazon Elastic Beanstalk, and so forth.
There's lots of examples of these out there.
But this is a different model.
This is where you can't just take the code that you've
always written and just suddenly put it in the cloud.
Some amount of rewrite, some amount of rework is going to
happen in the platform layer.
But what you get for it is, you get authentication models.
Somebody else will handle verifying who the user is
who's using your application.
You get services like Data Store, AKA Google BigTable,
where you have infinite key value pair look-up, and it's
redundant and reliable.
You have things like versioning control, where you
can do experiments.
Like I want to deploy only 1% of my users onto my new
software, versus 99% on my old software.
And as I'm confident that my new bits work, I can actually
kind of move the dial over.
And these systems in the background are automatically
moving users to these
different servers and services.
So you've given up some flexibility around
configuration and control, but you've gained a whole lot more
around scalability.
And then there are obviously test services and payment
systems, and things that you could
integrate in at this level.
Is all of this resonating so far with everybody?
OK, good.
Then we have the last layer, which is the software as a
service tier.
This is actually where Google started.
It's very interesting.
Different companies have taken different approaches to cloud.
Google has sort of come from the top down.
We started with software as a service, things like Gmail,
and search, and all these other things.
Moved down into the platform layer with Google App Engine,
and further down with these infrastructure
components I'll show.
Others in the industry started differently, and fundamentally
their design points are different, where they started
at the infrastructure layer, and moved up.
And you can sort of see this permeate through their
architectures.
And then, even a third one, which I can't name, that sort
of started in the middle, and sort of moved out from the
platform layer, kind of up and down, which is probably
perhaps one of the hardest points to start at.
So, software as a service layer--
you have a model around computation and code, but you
get capabilities like I want to run a query on a terabyte
of data, but the data has to be structured
a particular way.
For example, you have things like Google Translation
Service, and other things at this layer.
So reduced complexity--
the least complex--
but the least flexible.
So how does this look for Google?
And how do we sort of shape across these tiers?
Just one quick segue.
The language of cloud.
There's basically two languages of cloud.
There is REST and JSON, and SOAP and XML.
Every provider out there speaks one
of these two languages.
Google made a set of choices.
I'll talk about those in a minute.
Really, we're on REST and JSON.
We wanted simplicity, and less statefulness.
But there are different languages of the cloud.
These are important.
These will impact how you actually
develop your software.
So Google--
where are we?
Here's how Google layers across these services.
Yes, I realize this is a little bit of an eye chart for
those in the back of the room.
So I hope you have 20/10 vision.
But I will walk you through these, and give you a little
bit of an explanation of these technologies.
And certainly, we can talk more about these later.
I actually have demos of a couple of them, so I will
definitely be doing the demos.
So where do we start?
So at the bottom tier, we have the
infrastructure as a service.
So we have Google Cloud SQL.
This is hosted MySQL in the cloud.
So if you use MySQL, SQL Server, any other sort of
Oracle, SQL-based language, MySQL will look
very familiar to you.
The data types are familiar.
The syntax is familiar.
SQL-99, or whatever type syntax.
And in the cloud, you get this service.
And so whether you're programming in App Engine,
Compute Engine, or even outside of the Google Cloud,
you have a database.
It looks like a database.
And you can run queries, put data in, and run transactions,
and so forth.
What's unique about the Google Cloud SQL that's different
than others is our monetization model-- the way
you pay for it.
We have two models.
One is you can sort of get the subscription model.
The other is you can pay per use.
And so, for like $0.10 an hour, you could have 100
gigabyte database, or something like that.
And when you're not using it, it automatically
shuts down for you.
When you go and you run a query, we'll automatically
spin up your database, attach you to it, and
let your query complete.
I don't know of anybody else in the industry that gives you
that level flexibility for their SQL service.
So that's actually pretty cool.
By the way, I spent my whole career in these infrastructure
layers all the way up, so what's totally cool to me is
not always cool to others.
Like, that's my nerd humor.
I spent my whole time doing operating systems.
I think operating systems are cool.
Can we save one bit?
Most people are like, one bit?
What I do I even care, one bit?
I got more bits on my phone than like all
that existed in 1961.
Anyway.
So to the storage layer.
So Google Cloud Storage has been around for a while.
It's growing.
We've added capabilities, like static web hosting into the
service, so you can serve web pages out of here.
We are one of the first companies to support CORs.
This is like cross origin request, or whatever, where
you can say, oh, this server can request data from Google
Cloud Storage, and make it look as though it's coming
from my own site.
And this fixes a lot of permissions problems when you
build applications on the internet.
We have some really cool new features that I'm probably not
supposed to talk about that will be coming down the road
here with this, which makes it a lot easier.
We added a file API into App Engine, so it's easier to
manipulate files.
In Google Cloud Storage, we continue to innovate, quarter
after quarter, week after week.
New bits are shipped.
It's astonishing that we'll ship basically new kernels
every week in Compute Engine.
I don't know anybody else that does that at that speed.
And so with that, Compute Engine is our virtual machine
offering in the cloud.
We offer a couple different versions of OSes.
They look very familiar, and we'll log in.
You have different images you can choose.
At some point, we'll let you upload your own kernels, and
very interesting stuff.
But we have data centers all around the world that allow
you to host VMs, and I'll show you that.
So that's our infrastructure as a service layer.
Very cool, growing.
There's more that will be coming in the coming weeks,
months, and years in that layer.
The platform as a service is like Google App Engine, which
has been around for while.
And we continue to innovate services.
And we're always trying to find ways to better blend
programmability inside of the App Engine with Compute
Engine, so you can start to move your code more flexibly
between the different services.
We're getting better at that.
App Engine has different models of computation.
You can host Python code, Java code, Go code up in the cloud.
It'll scale up or scale down.
It integrates directly with the services down below.
So whether you're pulling objects or queries, you can
also have workloads run over inside of Compute Engine.
I'll show you a demo that uses Google App Engine as a front
end for hosting a website, and the interaction of the data
model with Compute Engine where we're doing some
scalable computation.
We have some other things that are coming.
I discovered that there is this thing out there called
Google End Points.
It's in Trusted Tester mode.
I thought it was safe to put it on this slide, because I
typed this in and it showed up on Google, so it must be OK.
So that's the engineering perspective, by the way.
But this is where we're trying to make it easier for you to
develop services.
So we give you this API layer that handles things like
authorization and authentication and payments,
and allows mobile phones and end browsers to send requests
into your service.
You handle the request, and you send back a response.
And so, if you've used Google Maps API, or these other APIs,
they are actually this type of Google End Points layer that
we use internally.
And now, we're going to offer that externally.
And then moving up the stack into the software as a service
tier, we have Google BigQuery.
And this is our service where you can upload terabytes of
data, run a SQL query, and the answer will
come back in seconds.
The first time you do this, it's actually quite
astonishing.
I grew up building SQL Server technology, and things like
that in years past.
And databases could never do this.
I was astonished the first time I did it.
And then, most people are probably familiar with thing
like Translate.
If you build front end web pages, and you want to get a
Google assessment on the performance of your page and
how to optimize it, we have services like Google PageSpeed
you can actually go use.
We have a set of sort of artificial brain models.
Anybody see that?
We took like 10,000 CPUs, went out and trained it on every
video on YouTube, and what did it learn to do?
Anybody know?
AUDIENCE: Cats.
TONY VOELLM: Yeah, it learned all about cats.
I'm a dog guy.
I was kind of offended.
But we have the Google Prediction API, which does a
lot of that.
It's these AI models in the cloud where you can train them
with sets of data, ask for answers, and then it will give
you your prediction of what's there.
It also does linear regression models, and lots of other
interesting things.
And of course, at the top is Docs.
I mentioned Docs on the slide because Docs can integrate
with all these other tiers.
To this Google End Points set of APIs that we expose out.
So everything we expose, we have is a RESTful API.
And Docs can actually program around these, whether it's in
the spreadsheets, or forms, or other areas.
It's actually pretty cool.
So how does Google view the cloud?
So this is-- by the way, this last side, this is how the
industry views cloud.
They think of it as this tiered model of
infrastructure, platform, and software as a service.
Google, we kind of think of it differently, though.
We think of it as apps.
There are a set of things that we built, that you use.
And then we have these other buckets of how we think about
the cloud platform.
We certainly think about how do you build your front end
stuff, like websites and apps, whether it's in your mobile
phone or Android apps.
Whatever they are, we kind of have this part that we think
about as apps.
We think about your data.
Data is very important.
And this is where privacy of your data
is extremely important.
We are one of the first cloud providers out there to have
encryption at [? REST ?].
So all data in Google Compute Engine is encrypted.
And we're taking that same mean and value to the rest of
our Google Cloud.
So that basically means there's a key.
We don't really have your key.
You lose your key, you're hosed because you're not going
to get your data back.
But there's probably one engineer who's highly audited
somewhere that could get the key.
But it's very, very, very controlled.
So we think about storing your data.
We think about computation at scale.
We're very interested in scientific workloads.
And we've done all kinds of interesting things, like
genomics, video rendering, and so forth.
There's been some really great articles that are written
about our computational capabilities, and
those are out there.
And then, of course, analyzing your big
data, which is a problem.
If you have terabytes of data, actually how
do you analyze it?
There's another interesting problem, which is I have
terabytes of data-- how do I get it into the Google Cloud?
Turns out, we--
I know, I don't really want to admit it.
You can send us a disk.
Not everybody's internet is like Google's internet.
But once it's in the Google Cloud, it's extremely fast.
But yes, if you send us a disk, we will actually
uploaded into the Cloud for you.
So this is more of the Google model.
We think about apps, computation, data, and
analyzing the data.
So what did we do to build Cloud?
So there are a bunch of principles and properties that
we've really held to, which are security.
And by security, I mean security and privacy.
We are highly, highly audited.
There's nothing that I can think of that can be touched
in cloud that isn't audited.
So if somebody has touched a piece of data, it's known who
it was, when they did it, how long they touched it, for what
purpose they did it.
And we have a very tight set of audited controls.
And you'll see more about audit processes and other
things later in the year.
We have a strong auth model.
So we chose this auth model called OAUTH2.
It's a little complicated from the developer end, which is
why we have upload to GitHub a bunch of code samples, like
how to program the Google Cloud.
So if you want to use cloud SQL or Compute Engine, or
whatever else, we put a bunch of example apps out there.
But there's some cool properties of OAUTH2, which is
like revocable access.
If you give somebody an access token, you could actually go
in and revoke access to that access token.
Which is something that's important.
Because once you're given somebody access to an app, you
want to be able to revoke it at some point.
You don't want them to have-- they've got your key, and they
always have your key.
That that's a problem.
OAUTH2 has other things, like time limits.
Like, you may look at the data for the next five minutes, and
after that, you can't get it.
And so you see things like that show up in our storage
tier where we'll give you a lease-- five minutes to pull
the imagine, and after the five minutes, you
can't see it anymore.
And so, while there's some slight complexity for
developers there, there's a lot of power that comes for
security around that.
Consistency was a second meme we've held.
I'm actually very happy to see the blogs picking up on this,
where they go out and they say things like, Google Compute
Engine is the most consistently performing
virtual machine in the cloud.
If I'm getting 100 IOPS to second the disk now, I see it
now, tomorrow, no matter how much seems to be running, the
workload seems to run exactly the same time and time again.
That is extremely hard to do, but something we value a lot
is consistency.
Open and flexible.
We're giving all the examples out.
In fact, all of our UI that I'm going to show you later,
you can develop all these UI yourself.
This is something that we've held as a principle.
We want people to build on cloud from all layers, whether
it's the management orchestration
layer, all the way up.
And then, yes, we have code.
And I'm a security guy, so I tried to use some
leetspeak on you there.
We haz code.
Sorry.
Tried to trick you.
And then proven.
So we actually do use all these services today ourselves
in production.
Google's one of the few companies I've ever been at
where we actually use all the things that you use.
We don't use anything different.
We use the same things, which is very cool.
So we prove the technology, and we won't ship it until
it's ready.
So I sometimes get the question,
why the Google Cloud?
Well, that sounds all great, Tony.
You have security.
You have consistency.
You have all these tiers, offerings everywhere.
I can write my mobile apps, and host them in
the back of the cloud.
Why Google, though?
Well, we know something about data centers.
If you haven't gone and done the virtual tour of the Google
data centers, you should.
Go out to Google, type "Google data centers." It's
phenomenal.
We have powerful machines, network services, geo-located
all over the world.
We've been running these services
obviously for a long time.
And we're really taking the best of what we have, and
really allowing the world to actually use
Google as their computer.
And so why Google?
Because we care.
We listen.
We take the feedback.
Every time I've gotten feedback, within weeks or
months, we've actually acted on the feedback.
So as you use the Google Cloud,
please do send us feedback.
We really do listen.
So why Google?