GREG: Chris is going to give us a demo of managed
virtual machines.
He's going to take an application like Brad used,
but he's going to add in, now, C++ code and some open source
packages, while still keeping the capabilities that he
thought App Engine was great for to begin with.
So Chris why don't you show us managed virtual machines.
CHRIS: Cool, thanks, Greg.
Appreciate it.
So what I want to show you today is
how we use managed VMs to take and add real time image
collaboration in the cloud and add that to Brad's demo.
Alright?
So what we're going to do is we're
going to have clients that are running inside of Chrome,
they're communicating back with a fleet
of managed VMs via WebSockets, for low latency communications.
Right?
And on those managed VMs we're going
to rely on ImageMagick, a third party, open source library,
that's an optimized C library, for doing image processing
and image rendering.
They want to use local disk to cache the renderings,
make it super snappy.
They want to use App Engine's Java runtime as a serving stack
to get data flowing from the front ends to the back ends.
Now, as Greg alluded to, that kind of technology
is not typically supported on platforms as a service.
And not what App Engine is today.
With managed VMs, this is totally possible.
Furthermore, we make it very easy to get up
and started with this.
So let me show you.
I want to pop over to my terminal here.
And what we see is a typical App Engine configuration
file with a few parameters.
So we have an application, we have a version,
we have what module's running.
With a few more lines of configuration,
we're actually going to turn this into a managed VM.
So let me walk through these settings here.
So the first thing is, we're setting VM true.
That's telling the system I want to run this on a managed VM,
so I have access to native resources and the ability
to run native code.
Furthermore, we get into a new section called VM settings.
Here we specify machine type, for example.
And since we're doing image rendering and image processing,
we're going to crank up the horsepower on these VMs
and deploy eight core machines.
GREG: Now this could be any of the Compute Engine
virtual machine types.
One, two, four, eight, or more cores.
High MEM, High CPU standard, whatever is available in GCE,
you can use with App Engine as well.
CHRIS: Absolutely, Greg.
And furthermore, as we innovate here,
those innovations will flow back to this configuration as well.
The next line is the settings for deploying the third party
code that I want on those managed VMs In this case
we're using ImageMagick and just doing app-get install
to those managed VMs
GREG: And again, anything installed
will be an apped get, I can specify here,
and it becomes available to me in a managed VM.
CHRIS: Absolutely, this is how we're opening up
App Engine so you can use third party libraries like that
and get them onto those VMs, those
managed VMs, in a super simple way.
The next line, is we're opening up
a port, in this case it's an arbitrary port 65080,
and that's how we're going to do the WebSocket
communication from the clients that are running
in Chrome, back to those fleet of managed VMs.
And then for the sake of this demo,
we're going to specify two instances,
because that's more than enough for this demo,
especially since we're running eight core machines.
So we're going to escape from this, save it.
Now since we're running on the Java runtime,
and it's a Java application, we can use Maven to deploy this.
OK, so while that's running, I'm going
to talk about what's happening under the hood.
So can we cut back to the slides, please?
Alright, the first thing that's happening
is that we're relying on our G Cloud tools
to parse and to validate the configuration file that I just
showed you.
Assuming that's valid, which it is,
It's going to communicate to our deployment endpoints
and say, OK, I want to deploy this application.
Those deployment endpoints are going
to store some metadata about the application, the version,
the template, the number of instances that are running.
And then from there we're going to go off,
and we're going to create the actual containers.
In this case, we're creating eight core, Compute Engine VMs,
and we're installing our Debian OS on top of that.
After that, we're going to carve out the managed services
and make sure that everything's lined up correctly for you.
So in this case, we're going to do monitoring,
and health checking, task queues, Memcache, and data
storing.
We're also going to create secure name spaces,
so that everything is secure within
those multi-tenant systems.
And we're going to set up smart defaults,
so it's very easy to access the APIs
and get data flowing back and forth.
From there, it's on to the serving stack.
And since we're running on a Java runtime,
we're going to install a web server, an application
server, and a JVM, and then it's is
on to the interesting parts, the parts that you provide.
So in this case, the third party code
we specified, so ImageMagick on those managed VMs.
And then, most importantly, your code.
We're going to bring all that up.
We're going to do some health checking,
make sure everything's running correctly.
I'm assuming it is.
We're going to install a load balancer,
and then we're going to wire everything up for you.
The final step is we're going to take all of that
and make sure it's co-located with the other pieces
of compute that your running.
So in this case, Brad had showed you
some front ends that were running.
We're going to take your managed VMs
and co-locate those with your front end,
so you get low latency and improved overall performance.
Alright, so we can jump back to the demo.
So our build has succeeded.
Let's go check that out in Chrome.
So we'll pull this up, and we'll navigate
to the URL that's provisioned for us.
Alright, and there we see our new front end,
cloud collabo, collaboration in the cloud.
This is pretty straightforward.
We're going to be able to upload an image.
We're going to do some edits to that image.
Those edits are going to be shared with people that
are collaborating, and we can do some real time conversation,
back and forth.
So let's pick an image.
Alright, meme two looks good.
Alright, man of the hour, Urs, we're
going to use his meme to actually get going.
So that's uploading to Cloud Storage right now.
Alright, there it is.
So it's uploaded, we see that I'm the only collaborator.
So let's change that.
I'm going to share this with Greg.
Now demo [? note, ?] I'm going to use Chrome profiles
to simulate Greg and myself communicating back and forth.
So we're going to bump over to Greg's profile.
Oh yes, looks just like you, Greg.
Oh, you're a "Despicale Me" fan as well.
I love it.
It's great.
That is like the craziest theme I've ever seen in my life.
Alright, back to business.
OK, so I'm sharing this with Greg right now.
It's going out, it's going to log him in.
Wait for it.
There he is, alright.
And you see now that Greg and I are
collaborating on this image.
Now to show you happening in real time,
as I try to move this over here--
So I'm going to pretend that Greg is actually
doing the editing, and you're going
to see things happening, if everything works correctly
in my browser as well.
So we'll dress it up with a frame first.
Nothing goes with green like magenta.
Grab that.
Add border.
Alright, good, we've got a border.
And now we're going to add some high end doodling.
Somebody had mentioned that doodling on Urs's image
is probably a career ending move.
I said hey, why not.
GREG: Only if the demo doesn't work.
[LAUGHING]
CHRIS: Exactly.
So we're going to give Urs a big smile, good prices in cloud,
and his famous earring, a little more bling.
There we go.
And now we see that it's happening in real time
back to my browser.
And so, again what's happening is
that these two clients, connecting over
WebSockets back to managed VMs.
We're doing the rendering, we're caching in local disks,
then we're sending updates back to the Chrome clients.
Now I want to take a second and say, to all the App Engine
developers and users that are in the crowd,
this typically wasn't and was not supported on App Engine.
But yet it's been a top feature request, consistently, year
over year.
So I'm happy to announce that those feature requests are now
fixed, and available to you.
OK, so it's not just about-- thank you, thank you,
thank you, all the App Engine developers in the crowd.
So while the ability to access native resources
and run native code on these managed VMs is fantastic,
it's not just about that.
It's about great developer experiences and great developer
integration.
So to show you that, I'm going to bump
back out to the developers console here.
It's the same UI that Brad had shown previously,
it's our developers console.
And I'm going to show how we've integrated App Engine
and Compute Engine by drilling down into the App Engine tab.
And we see our dashboard.
We see our modules.
I'm going to select our back end module, that's
the one that's handling all the real time
collaboration and communication.
We'll drill into the instances.
And here we'll see the instances that
are running from my application.
So, remember, back in the configuration file,
we specified that we want two managed VMs.
Here we see those.
And if we drill into this VM over here,
give it a second, OK.
And so there's the dashboard for the underlying VM.
And if we move down the page, you
can see that it is, in fact, an eight core machine.
We've automatically configured an external IP for it.
And there's some metadata here that
allows us to manage the VM, quite a bit of it actually.
So that's drilling down into the VM.
Now we'll have to bubble back up and see
how we've integrated all the managed services.
We come back to the App Engine tab,
we'll go to our unified logs viewer.
Now what's nice about this, is it's not just unifying
the logs on all my managed VMs.
It's actually unifying the logs across all the compute
that I'm doing.
Be it a front end running on App Engine,
or managed VMs that are running on top of Compute Engine VMs.
So here we see that there is a fair number of servlets
that are being hit, for my back end.
Got one for serving up an image, one for
create a WebSockets connection.
And while you could do all of this on an unmanaged VM,
you could do it on a raw Compute Engine VM,
you could deploy syslog or rsyslog.
We think there's more productive way.
We think that by offering a managed and centralized service
like this, you become a more productive developer.
And furthermore, if you apply that philosophy out
to things like authentication, deployment management,
configuration management, developer tools,
developer console, that you could
be a more productive and happier developer for the cloud.
Now let's take a look at how-- speaking of developer
productivity, let's take a look at what
we do with the underlying VMs.
Now, we had mentioned that these VMs are locked down by default.
So they're not-- you don't have root access,
you don't have SSH access in to them.
And that's for a good reason, we don't want people
going out into production and making changes
to one of those VMs that are running inside
of a large fleet.
It makes it hard to manage within a high availability
manner.
But we recognize the fact that there
are times when you need to get to those VMs
to do things like-- do some kind of debugging,
or check on a configuration file that you have,
or make some configuration change,
just to see what happens to the underlying VM.
We make that super simple as well.
So if we come back here to the terminal,
we're going to do a G Cloud-- instances-- [INAUDIBLE] gcloud
compute-- instances-- list-- and there's
our two VMs that are actually running.
And now we're going to enable debugging for one of those.
So I'm going to do gcloud debug-- [INAUDIBLE]
compute debug.
Use the local directory, which has
the configuration for these managed VMs.
And what that's going to do is it's
going to go through that deployment end point
and put those two managed VMs into debug mode, which
is what you're seeing here.
I'll clear that up.
And if we do gcloud compute instances-- list, again.
So I can grab the name.
Let's grab the first one, and we'll SSH into that.
So we'll grab that guy.
Instead of list, we'll do SSH.
OK.
Now that'll SSH us into the underlying VM,
what you see here, cramsdil@ae-backend1-0.
Clear that up.
once we're on this VM, you have access to common tools
you would normally use on a virtual machine.
In this case we do things like run netstat.
We see all the activity that's running
through the various connections on the VM.
In this case, we can actually see up there at 65080
with the port we're listening on for the WebSockets
communication.
And then we can do things like interact
with the Debian package [INAUDIBLE]
and see that the package that we specified inside configuration
file is actually on the VM.
In this case we would do DDKG and we'll
do a grep for the same Magick.
And sure enough, there you see that, in the bottom
there, we see that our package is actually
installed on the VM.
And so all we need to do is we exit,
we'll seal that VM back up, and things are good to go.
So what we've seen here is that with managed VMs,
we can take advantage of the auto management
the App Engine provides with the control and flexibility
of underlying Compute Engine VMs.
We make it super simple to get started
with easy configuration, easy deployments,
integration back with managed services,
as well as integration with our developer
console and our developer tools.
So that you don't have to make a choice between
I want platform as a service and auto management,
or I want to choose flexibility with Compute Engine.
Managed VMs brings both of those together,
giving you the best of both worlds.
And so, with that, I'm going to turn it back over the Greg.
GREG: Thanks, Chris.
[APPLAUSE]