字幕列表 影片播放 列印英文字幕 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. 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.