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