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?
Because we listen, and we have the experience to run this big
data center.
So, some demos.
This is one of my favorite parts here.
So I'm going to do a couple demos.
First, I'm going to take you to the Cloud Console.
I'm going to click on a web page.
That's going to be a very sophisticated demo.
But then I'll take you through very briefly
some App Engine demos.
But I'm going to spend a bit more time on Compute Engine,
and show you some of the power of what fully generalized
computation in the cloud looks like.
We will spin virtual machines up in Europe.
So while we're getting close to sleeping, they're wide
awake, and so we're going to go spin up some
machines over there.
And then, I'll just kind of round things out after this.
So with that, the Cloud Console.
And by the way, I closed out my email.
So if anything personal show up, start laughing so I know
to close the window very fast.
Which is very likely to happen.
So Cloud.
It's all together now.
So if you go to cloud.google.com, you can
actually try all these things that I've been
talking about here.
You can see different sets of customers that we have.
You can click into computing at scale.
You can go and learn more.
You can dig through this.
I'm not going to spend very much time on this.
In fact, I'm just going to go dive into some
of the other demos.
But we have an amazing amount of help out here.
If there are examples you don't see, example you want--
really, like I said, please send us feedback, and I'll
take you through it.
So cloud.google.com.
That's your starting point for all of Cloud.
So if you walk out of here with anything, three things--
know we're helping you with your dating, because you need
to know this stuff.
cloud.google.com is what you want.
And we care about security and privacy.
So that's demo number one.
There's cloud.google.com Which a year ago didn't even exist.
So let me go back here.
And you can tell I've done demos before, because just in
case it didn't come up-- there it is.
OK, so Cloud.
So let's talk about App Engine.
App Engine is our platform as a service tier at Google.
This is the thing that automatically scales up and
scales down dynamically for you.
It's where you can host your data.
It has lots of services you can use to build interesting
things like--
we have an XMPP service where you can go do live chat.
And at the back of your chat, you can have a robot trying to
predict what the answer is.
And so, you've probably experienced this somewhere on
the internet where you're typing into, oh, I need help
with my flowers.
And it comes back, and it says, oh, here, have you done
these things?
It's very likely it could be an App Engine app using this
XMPP protocol out there.
App Engine, as I said, started out in 2008.
And you can just see the phenomenal growth that has
happened with App Engine.
And year after year after year after year, we've added
services to make it easier to develop interesting
applications that are out there.
We have customers across many different
tiers for App Engine.
And this is to give you an idea of the scope of how App
Engine is used.
Clearly, line of business apps at the bottom.
Business apps--
lots of businesses use us.
In fact, you've probably hit an App Engine app
and didn't know it.
At the consumer tier, we have companies like Khan Academy.
And there's a bunch of other really cool ones I wish I
could have talked about, but I can't.
But mobile gaming is out there.
Lots of mobile gaming.
In fact, the biggest mobile gaming vendors out there you
can think are all using the Google Cloud in one way,
shape, or fashion.
And then, on the mobile tier, we have news
readers, like Simperium.
You have Pulse, and others.
And so, App Engine obviously has big usage, in terms of the
number of users.
There's something like 7.5 billion hits over a million
applications on App Engine being hosted 24 by 7.
And we have a 99.95% reliability.
And we're trying to drive that up all the time.
So that's App Engine.
So let me go pop in and do my two little sample apps.
If you go, and you look, if you google "appspot.com," "app
spot," or actually "all App Engine hosted apps." So if you
want to see who else is sort of out hosting apps on App
Engine, you can go do an app spot search.
I found this one, which is kind of geeky, because we're
all developers here.
Which is called shell.appspot.com, which gives
you a thin interface to Python, so you can program
Python in the cloud, and do like everybody would want to
do, which is--
oh, I have a typo.
That's me.
I'm not a very--
whew.
There.
[? Printonia ?].
I have taken over the internet.
Thank you.
But that's an example app.
You may have apps that are programming apps.
There's other obviously much more sophisticated vendors out
there doing cloud development, and they're using App Engine.
I found this other site, which was called Beat the Boot.
This was a Chrome site that Google had built where you
could actually go and try to play games to see how fast you
can do things.
How much faster you were than Chrome in booting.
And I was failing miserably.
But this is all hosted on App Engine.
The back end data tier, the front end presentation.
And I believe that this one was I'm supposed to race it in
brushing teeth or something like that.
And clearly, Chrome beat me.
So there you have it.
You can write games on App Engine.
Yes, it's very sophisticated.
OK.
And then the demos that I wanted to spend a little bit
more time on are actually Compute Engine.
And so, Compute Engine is one of our newest offerings.
We launched this last year at Google I/O.
It's in limited preview.
And so a few short facts about Compute Engine, and then I'll
do the demos.
Which is these are some things that people are saying about
Compute Engine here.
And what I like about this site here is this is like a
genomics site.
And if you go back and watch the Google I/O launch, it
shows you differences between--
you're trying to do this locally on your work station
where gene association takes about 30 days per association
on powerful workstations in your office.
And on Compute Engine, we're doing associations like every
five seconds.
So it fundamentally changes the way research is done.
In the last six months since we shipped this, we've beaten
the TeraSort record on Compute Engine.
So a partner of ours, MapR, they did this analysis where
they are looking at like, why would you want
to move to the cloud?
Like, what's the economics of the cloud?
How is it different?
And so, they went out and they did a TeraSort.
And they said, well, what would it
take to build a TeraSort?
Like if I was going to go build a set of machines, what
would it look like?
And so they did this one thing where it's like, OK, we'll
need roughly 1,500 servers, 12,000 cores.
It takes a lot of planning and investment.
It's going to take us about $6 million roughly to build this
data center that, in a minute, could sort your data.
Or, optionally, in 53 seconds, you could sort your data on
Compute Engine.
And at a cost of $500.
And by the way, the $500 will let you do it 60 times.
Because it's like 13 and 1/2 cents a minute per core.
Multiply it out.
You pay by the hour there.
So you could sort 60 times for or $554.
Cloud is completely changing the economics of how we think
about building software, bar none.
Here's a video of the TeraSort happening.
This was produced by MapR.
And what they're doing here is they're actually kicking off a
script that's programming to the REST APIs on the back end
for Compute Engine.
They're pushing software into the nodes, telling the
MapReduce to go do the sort.
The red are CPUs that are fully engaged.
The green are the idle.
And this is what a sort actually looks like,
computational-wise.
It's pretty cool.
It almost looks like the game [? alive ?], where all the
CPUs are engaged, and subsets and subsets and subsets.
And there you have it--
a TeraSort in seconds.
So let me go give some actual live demos here quickly.
So one is this.
So we actually have a UI for spinning up and shutting down
machines in Compute Engine.
So here, what I'm going to do is I'm
actually create an instance.
I'm going to call it "NYC," because it's New York.
Like I said, I have a couple choices of where I can spin up
machines in the world.
I can go to the middle of the US, the east coast, or
somewhere in Europe.
So I'm going to go to Europe.
I'm going to ask for a two-core CPU.
And I'm going to tell it to go kick that off.
And so one of the things that you'll see in Compute Engine
is the first stage of booting a virtual machine is called
provisioning.
This is where we go look at the data center, figure out
what physical host we can host the virtual machine on.
Once we figure out where it can be placed, we place it.
Then we go into this mode which is called staging.
And that's what you see happening right now.
This is like, oh, I have to boot an image.
It's an operating system that I need.
Let me pull this operating system down to my host.
Let me tell my machine about the operating system.
And then, let me actually started booting
the operating system.
Now what's interesting about Europe is the image takes a
little bit longer, because currently the images are
mostly hosted in other places than next
to those data centers.
And so, it's booting.
And then now, it's transitioned into this mode
called Running.
This machine [? b, ?] this machine is on.
It's powered up now.
So somewhere in Europe right now, I started up a machine.
So I just used my $0.14.
And so, I'm going to make use of my $0.14 here.
So I'm going to switch into the command line here.
So let me do one thing.
I will attempt not to type my password in for you.
OK, so what I'm doing here is, I actually have a workstation.
I have a developer workstation in Kirkland that I actually
logged into here.
Because I needed some gateway to get into my machine.
Like I said, this is infrastructure
as a service layer.
Somehow, you have to get into the machine.
And you can get an x terminal to it, or whatever else.
I'm a developer.
I'm going to go to the command line.
So what I'm going to do is, I'm actually going to go SSH
into this machine that's in Europe.
And I'm going to use the set of local command line tools
that we have for Compute Engine.
So we have command line tools for all
these different services.
This is called gcutil So Google Compute util.
I have a project.
And so one of the first things I'm going to do is I'm going
to say, list all the instances that are out
running for me as a user.
And I wish I could--
AUDIENCE: [INAUDIBLE]
TONY VOELLM: Yeah, sorry.
Actually, what it really doesn't
like is the fact that--
AUDIENCE: [INAUDIBLE]
TONY VOELLM: I have two mistakes here.
No pressure, no pressure--
live typing.
OK, now I'm definitely sure I'm running.
And I know it's a little hard to see in the back, but here--
what you can see is I actually have a machine that is booted.
It is this [INAUDIBLE]
machine, two cores.
Tells you what image it is.
Gives me an external IP address.
One of the things I can do with the tool, though, is I
can just say, ssh into NYC, which is my machine.
And the tool will automatically look up the IP
address, and get me in.
And so, here I am actually logged in to a server in
Europe, running in a Google data center--
which like I said, for an infrastructure
guy, is very cool.
So, yay, it actually worked.
So now let me give you a more visual kind of depiction of
what this looks like.
So for Compute Engine, I showed you the front end UI.
So there's this UI here.
I can click on the machine, NYC.
It tells me where it is.
I showed it to you running inside the command line.
So I could actually get command line access, and now I
can configure apps, get, run all my software, have full
programmability.
But here's a slightly different demo.
What I'm going to do here is I'm going to spin up 16
virtual machines.
And this is an App Engine app front end hosted application.
And what it will do is, as it starts to go through the
provisioning stage, you'll see green.
So we have gone off.
We told 16 servers to boot.
We're 13 seconds in.
Machines are already in this provisioning stage, then they
get the staging.
And then when they're green, that means they're fully up
and ready to go.
My co-workers will often show this with like 1,000 nodes.
And it takes about the same amount of time, actually, to
start 1,000 nodes.
Roughly under a minute, we could start up 1,000 machines.
So there's now 12, 16 machines out there that are running on
my behalf somewhere in the world.
And what I'm going to do is I'm going to show you what
this looks like visually to have this powerful computation
at your fingertips.
So here's a fractal generator.
On the left side is a single CPU doing computations.
On the left side are the 16 virtual machines I just spun
up in the world.
And if I click in one of these, watch carefully--
they'll both zoom, but start to look at the details.
So I'm going to zoom fairly quickly into
this one on the left.
Watch the resolution differences of these two
images, OK?
Here we go.
So if you look, this one is very blocky and fuzzy.
That one over there with 16 nodes is already computed
seconds before this one over here.
And so here we actually have an application running in App
Engine using Compute Engine as a background processor,
literally with these CPUs in the background doing the
computation.
And you can see, with even 16 processors, it's maybe shaved,
I don't know, half the time off, or 3/4 of the time.
A thousand CPUs?
This would just be just like this.
I could literally fly right into the fractal.
So there you have an integrated demo of App Engine
and Compute Engine working together.
And since it's getting late, I'm going to start
to wrap this up.
So there's some demos of Cloud.
But as I said, I would give you the pitfalls.
So it's kind of like when the dog grabs your sock,
and won't come back.
There are pitfalls in Cloud.
Needless to say, when the dog gives back that pink sock, I'm
sure it's going to be wet.
So what to watch out for in Cloud.
One is, Cloud is interesting.
The monetization models are typically by the hour, by the
day, by the month.
You have to be a little careful.
It does feel a little bit like death by 1,000 cuts, where
every day you go spend just a dollar.
And at the end of the month, you're like, whoa, where did I
spend $3,000 on this credit card bill?
You have to watch out for this Cloud.
We are trying to do things at Google to make this easier,
more predictable.
But we're not there yet.
So just be thoughtful of the services you're using.
As you move from the infrastructure as a service
layer to the software as a service, there's more lock-in.
Remember, I said it's easier to do these things.
But it also means you're sort of more locked in.
All of us as developers worry about lock-in.
Google is worried about this for you, too.
And we've done a lot to make sure you can
get your data out.
We had this whole effort called the
Data Liberation Front.
Any data that Google has, you can export it.
There are other things that we're also doing here to make
people feel more comfortable about using the value added
services, about feeling locked in.
Location matters.
There are different geopolitical rules, different
governments.
Depending on what you build, you have to pay
attention to location.
If you start a virtual machine in Europe, you may be subject
to European laws.
So while it's very easy for me to start it and use this
thing, depending on data retention policies and so
forth, you have to be familiar with those laws.
So while it's super easy to do, it doesn't mean you're
sort of divorced from having to understand the
legal end of things.
So that's kind of a gotcha.
And then, disasters happen.
Like, Christmas we couldn't play videos.
And you hear about things.
But what I want to say is it's really hard to keep cloud
services running.
But it's even harder to run them yourselves.
I've been there.
And so you don't have to take my word for it, build your own
data center, run it for a year.
And then when you're done, please come to Google, and we
will help you use our data center.
It will be better for you.
So there are pitfalls out there.
So with that, people ask me a lot of times, where does the
team come from?
So where else would you build the Cloud than in the
cloudiest city in the world, which is Seattle/Kirkland.
In fact, almost all the cloud providers are up there.
We actually tell everybody it's really cloudy all the
time in Seattle.
So I had to sort of synthesize this picture with some clouds,
but this is actually Mount Rainier in the background
going over the I-90 bridge here.
Trust me, it doesn't look like this ever, ever.
It rains all the time.
Please stay in New York.
The second-biggest location for Cloud is San Francisco,
followed by Mountain View.
And as [? Ari ?] had mentioned, we actually have a
team here in New York that's actually building Cloud, which
is super cool.
So we have sort of 24 hours of coverage.
We actually have a team in India in Hyderabad.
We also have one in Sydney, Australia that are helping
keeping these services up 24 by 7 for you.
And with that, I hope you learned what Cloud is.
I hope your dating is successful.
And thank you for coming to Google.
[APPLAUSE]
TONY VOELLM: And I'm happy to take questions.
You don't have to stay, because this is probably the
last call for beer.
But if people have questions, I'll be up here.
Feel free.
We can answer questions, or not.
MALE SPEAKER 1: Yeah, I think we can do--
TONY VOELLM: So the question is, are there Google services
running on Google?
Yes.
In fact, a lot of the properties that are out there
are running on Google.
I actually checked with marketing, and unfortunately,
they threw these golden handcuffs on me.
So I'm not allowed to talk about it.
But there are open source build servers, and all kinds
of interesting things are built on Cloud now.
Inside of Google, there's not a single line of business app
that's isn't built on App Engine these days.
In fact, a lot of our external apps are built that way, too.
So yeah, we are definitely using the services we're
building, day in and day out.
Our business depends on it.
AUDIENCE: I have a question about the
redundancy and just pitfalls.
Because like you said, things do happen.
If I were to get a dedicated virtual host, if I would go to
the hosting company, and try to figure out what kind of
redundancy they have, all these back-up failover things.
How do you guys handle things like that?
I've used Amazon in the past.
So like you said, everything is pay as you go.
You start up your machines, but if something does happen,
are you guys pretty transparent in trying to
figure out what happened, and just work with customers?
TONY VOELLM: Yeah, so the question was, how
transparent is Google?
We're very transparent.
I'll actually show you a quick example.
So one of the things you can do with the API
that is super useful.
So let me get out of this VM.
We actually have something that's--
if you look at the tool, this tool here, we actually publish
things like our down time that we're going to have on our
servers through the API.
So if we think that there's a service outage that's coming,
we'll actually go list that.
And I was going to see if I could find it here.
Yeah, get PCR.
Let's see here-- delete.
AUDIENCE: I guess my question was more in particular, like
Amazon had-- some of their regions have been down in the
past unexpectedly.
So if my service is in the middle of doing a bunch of
computations and one of the region happens to the affect
that, do you guys work closely with customers specifically
try to figure out what happened?
TONY VOELLM: Yeah, so for failover and disaster
recovery, yes.
I mean, there are things that we're going to do that I can't
talk about today--
because they're not released yet-- that will help with
these disaster recovery scenarios.
We're very cognizant of this.
If you noticed, I was talking about oh, there are multiple
zones out there, in terms of where you can
actually start services.
And so, the fact that we have two zones in Europe tells you
something about redundancy.
So we're building this level of redundancy in.
There are certain things that customers will want at some
point, like load balancers and failover
and automatic restart.
Today, it's a little bit more self-service.
We will get there.
Specific individual customers, we're happy to share a Google
experience on how we've actually done it successfully.
And how we've like scaled up, and kept search, docs, and all
these services running 24 by 7.
That's one of the benefits of actually working with Google
is we give a lot of insight into actually how we do that,
and how to sort of create your environments.
Which is why I also talk about the pitfalls.
Disasters are going to happen.
If you put everything in a single zone, and there is a
planned outage, or an unplanned outage, yes, you're
going to have a problem with your application.
Don't do that, right?
Like today, don't do that.
The alternative is to use something like App Engine
which will automatically migrate and move around
failures for you.
Which is why you sort of move up to this next tier.
And the you might start asking, well, could you do
that for virtual machines?
And I can't say anything.
AUDIENCE: Thank you.
AUDIENCE: Can you hear me?
TONY VOELLM: Yeah.
AUDIENCE: So I serve large, evil enterprises, so my
question is two-fold.
First of all, are there plans for a private or hybrid
enterprise cloud?
TONY VOELLM: So the first question is, is there plans
for a hybrid cloud?
And what this means is typically part of the cloud is
in the Google data center, the other part is hosted locally.
This means that there's generally a VPN service, an
encrypted channel into Google.
We actually have some documentation today on how to
do this with things like App Engine apps.
Talk to us more.
I'll talk to you--
I can't say anything here, but we can talk more.
It makes a lot of sense to allow these
hybrid models exist.
AUDIENCE: So the second question is, what operating
systems are going to be supported in the future for
the Compute Engine?
TONY VOELLM: The question is, what operating systems will be
supported in the future?
So today, there's CentOS, and there's another derivative
that's very familiar to most people, which I'm
not allowed to say.
But you can go find it, we call it the Gcell but it looks
very familiar to something else.
We will be providing more operating systems in the
future outside of Linux derivatives at some point when
it makes sense.
Part of that's going to come from demand from customers.
But yes, it does make sense to support more in the future at
some point.
AUDIENCE: OK.
Thank you.
AUDIENCE: Hi.
I heard that Hadapoo?
Hadoop.
Can you comment a little bit that you use that?
Maybe you don't want to say that.
And the other question is I heard the Google App Engine
supports Python, so do you plan to support Perl?
TONY VOELLM: Support which?
AUDIENCE: Perl
TONY VOELLM: Perl.
Oh, well, that's a great question.
I can't say anything about future features.
But we have heard many times that PHP is
popular, Perl is popular.
Hey, could you just work your Google magic and do all this
automatic scaling with any language we bring.
We've heard it.
I can't say anything more than that right now.
But yes, we recognize that it's really important.
That was one question.
The other one is around Hadoop.
I believe we have some white papers around how to run
Hadoop really well on top of Compute Engine.
And it makes sense that a lot of cloud providers have
provided software that makes it even faster.
And we definitely recognize that, too.
But I can't say if something is coming or not.
But I can tell you, yes, we recognize a
need for both of those.
AUDIENCE: Thank you.
AUDIENCE: I'm just wondering--
a long time ago, there used to be grid computing,
and stuff like that.
And peer-to-peer, and things like this.
Is it possible that if one's doing peer-to-peer for gaming,
some of the assets could be in the cloud.
And if for some reason--
mainly it would be running peer-to-peer.
But say like, there's a [? fallout ?] then you can
[INAUDIBLE].
TONY VOELLM: So the question is, is will you start to see
models of how you leverage access from the phone, and
failover to the cloud, or using the cloud.
In fact, we actually do a lot to make this possible.
This is one of things for the Google Endpoints that make
programming easier.
We also have things in App Engine like task queues, XMPP.
We have this thing called the Channel API, which will call
back in to your cell phone to deliver notifications.
So there's a lot of social sites out there that use App
Engine, where you're walking around, and it's sending GPS
location or whatever to their app.
And then it's like, oh hey, you have three of your best
friends right next door.
And that's all built on top of the services in App Engine.
So absolutely what you're asking for is there.
And it's getting used.
AUDIENCE: Thank you.
AUDIENCE: This is a curiosity.
When you upload, or when you access a Street View image on
the computer, how many machines do you have working
in a typical browsing in like Street View image?
TONY VOELLM: Yeah, so the question is, when you're doing
Street View, how many machines.
are back there working on that I can't tell you.
But what's interesting is, is in the last year, Google used
to have this thing called tile servers, and we'd serve out
these tiles.
We actually moved away from that now.
And we're actually rendering now in the browser.
So we're sending the data.
And we're allowing you to cache it locally on the phone.
So if you suddenly drive out of Wi-Fi area, the map keeps
working for you.
On the back end of that, go look at
the Google data centers.
And we tell you where all the Google data centers are all
over the world, and you can just start to like-- wow,
there's probably a lot of servers out there handling
things like Gmail and Maps.
Maps in particular is heavy with data.
So I can't tell you.
But it's probably a big number.
MALE SPEAKER 1: All right.
So I want to thank everybody for coming.
Thank you, Tony, also, for taking your time to educate us
on all these things.
There are quite a few Google people around.
If any of you have questions for any of us, we're all
wearing Google shirts.
Tony's also going to make himself available for the next
few minutes to answer any questions.
Thanks again, everybody.