Subtitles section Play video Print subtitles CHRIS RAMSDALE: Hello, and thank you for coming out to this year's Google I/O conference. I'm Chris Ramsdale. KATE VOLKOVA: I'm Kate Volkova, software engineer on App Engine team. CHRIS RAMSDALE: Yes. And today, if you didn't get a chance to attend the keynote session, there was a lot of great technologies that were announced and talked about. Android had a slew of amazing technology that's coming out, for both the consumer and the developer. Chrome had some great advancements. The Cloud Platform has some great technologies that were coming out. And I'm happy to talk about a few of those as we go through the session today. So if you did get to attend, you saw that our director of product management, Greg DeMichillie, was using a demo application called WalkShare, which was an Android client that was hooked up to back-end services that are running on our Cloud Platform-- namely managed VMs that were running on top of App Engine and a Redis Cluster that was running on top of Compute Engine-- and using the Datastore to store data. That allowed you to save walks, and then share them with your friends, and then have your friends comment on them. Well, today in this session, Zero to Hero with Google Cloud Platform, we're going to take a look at that application and do a deeper dive into how we built it, using our unified tool chain, our managed platform. Kate's going to talk a bit about how we run Google production services on your laptop so you can be an efficient developer. And then finally, we'll look at some advancements we're making in the DevOp space so that you can actually debug your application in production and feel confident about what's running. So to get started, we need to start with the foundation, a cloud platform project. And that's super simple to do. All we need to do is bump out to our developer console here. We do Create Project. We'll give it a sample name, demo name. We'll call it walkshare10. And we'll go ahead and create that. Now, that's going to take about 10 to 15 seconds. And while that does happen, let's take a look at some of the changes that we've made in our Developer Console since our Cloud event back in March. So the focus has been on taking the user experience and really consolidating it down to the core pieces of your application. So as you can see on the left-hand side, we have APIs and Auth so that your application connect back to Google Cloud services and other Google services, as well as third party applications connecting back into your application, as well, via the endpoints that you might surface through Cloud Endpoints or any RESTful style. We have Monitoring, right? So a consolidated view into the metrics that are coming from your application-- the performance of that application as well as centralized logging, coming from Compute Engine and App Engine, which I'll touch on throughout the talk. Source Code for storing your source code in the cloud, as well as doing your builds in the cloud. Compute, a consolidated home for both App Engine and Compute Engine. And finally, Storage for all things storage related, whether it be non-relational, relational, or blob data. And then Big Data for our analytics tools, such as BigQuery and Cloud Dataflow, that we announced today. So now we'll see that our application has been successfully built. So simple enough? Well, actually, through that process, within that 10 to 15 seconds, we've created quite a bit of infrastructure for you and on your behalf. We've created namespaces so that your application can connect back to our multi-tenant services, our cloud services, via Memcache, Datastore for storing NoSQL type data, task queues for communicating within your application. We've created those namespaces for you so you can securely hook into those services. We've given you a centralized logs repository so you can funnel all of your data from your compute back to one spot, where you can view it and interact with it via the Logs API or through our Developer Console. We've given you a Git repository so you can actually store all your source code into the cloud, enable things like Cloud Debugger, like you saw today from Greg. And then we also give you agents that are running on top of these VMs that are hooking back into all of our monitoring data. So they're monitoring the applications that are running, they're monitoring your compute, and they're funneling all of that data back into the dashboards that we have. OK, great. So now that we've got this up and running, we've got our project created, let's actually add some source code to it. And I want to do that with our Google Cloud SDK. It's our unified tool chain that brings together all the services within Cloud, be it App Engine, Compute Engine, Cloud Storage, Cloud Datastore, pulls it all into one unified tool chain so you have those services available at your fingertips. So see that if we bump out to our terminal here, I have some local source. And what I want to do is I want to take that local source and push it into the cloud, and then actually have it built and be deployed, and we can check out our application running. So this is pretty straightforward. I'm going to use our G Cloud application, or Google Cloud SDK. And since I'm terrible about remembering command line options, command line parameters, I'm happy that they actually have code completion and command completion built into the SDK. So if I just do a double tap, I'll get the commands that I can run. You know, sometimes in life, it's just the little things that actually make your life much, much better. So I do gcloud init, and we'll use that same application that we-- same project that we just built. All right, and that's going to go through, and it's going to create some local directories for me, in which lies some metadata about the Git repository. All right, let's clear that for ease of use. Now, what we'll do is we'll navigate into that directory, and we'll copy in our source. OK, so we get a Java application, represented by a pom.xml file and some source. What we'll do is we're going to go ahead and add that. And commit. Let's see, initial commit for the comment. All right, all looks good. And then finally, if we just do a Git push, it'll push that up into our Repo. OK, there we go. So it's taking my local source and pushing it into the cloud. And the idea there is that we want you to be a productive developer and allow you to use the tools that you're used to, in this case, Git, to develop locally and then finally, run. And I mean run, I mean in Google production data centers. So as this Git push is going from source into the cloud, into that Git repository, we're going to see that there are services that are picking it up and actually building it. So let's funnel back over to our developer console. And if we go to our project, we do a refresh on the Git repository. OK, so we see my source code now, up in the cloud. And you see my last comment, which was just initial commit. And then since this is a Java application, we need to build it somewhere. What we'll see is if we click down into the Releases section here, we should see a build that has been kicked off. Give it just a second. OK. There we go. And actually, by this time, it's actually build, tested, and deployed. So where is it actually building? So we saw that we have a Git repository in the cloud. I pushed everything up there. Something had to kick in. What we're doing is, on your behalf, we're spinning up a Compute Engine virtual machine that's running Jenkins. So to do continuous integration for you, it's picking up that push, because there's hooks into it, it's building on the VM, it's running my tests. And if all my tests pass, it actually does a deploy out to App Engine. And we can see that right here. And if we drill in, we can see the build logs and the diff and everything like that. So if everything is working correctly, we should have a new version up and running. And if I go to walkshare10.appspot.com, voila. So there's our application running. If I click here-- so we'll post a silly comment. Good. Everything is saved. So now we've pushed everything into the cloud, and it's running. Now, once this is running at scale, let's say that we wanted to do some sentiment analysis or something on this application. So I've got hundreds of thousands of comments that are running in, that are being stored. And I want to take and do some sentiment analysis on those comments that are coming in. Now, to do that, I know that I'm going to need a bigger, beefier machine. I'll need more CPU and more memory, right? And furthermore, I'll need some kind of library that will allow me to do analysis on the streams that are coming in. Something like OpenCL, which is a fantastic library for doing this. Now, the problem is that, historically, App Engine hasn't supported this. For security and scalability reasons, you're not able to run native code, so C or C++ code, or access things like the file system or the network stack. It also doesn't have the memory configurations and the CPU configurations, the footprints, that I need to run sentiment analysis. At the same time, though, I don't want to jump all the way over into unmanaged infrastructure as a service and run all those VMs myself. So lucky for me that back in March of this year, at our Cloud Platform Live event, we launched into limited preview a new feature called Managed VMs, which takes the management platform capabilities of App Engine and merges those with the power, the control, and the flexibility of Compute Engine, thus providing you the best of both worlds. And in the spirit of making developers highly efficient, we've made this super simple for you to get up and running, to move from App Engine into Managed VMs. All you have to do is change your configuration files. So here, we're looking at a Java configuration file. You set the VM property to true. Easy enough. You specify which machine type you would want. In this case, we want an n1-standard, but actually there's a little typo in this [? deck. ?] You actually want a high CPU machine here. But the nice thing is that with this property, you can specify any Compute Engine machine type, both that we have now and the ones that we're investing in in the days in the future and in the months to come. And then we need to specify the number of instances that we want. In this case, I just say that I want five. You can put whatever you want to in here. And furthermore, you can programmatically change the number of instances when you're running in production. And then, in the coming months, we'll have auto scaling that will apply to this as well.