Deciding how to run your application code in the cloud
can be difficult.
You have a variety of options and probably
many dependencies and requirements.
And it all seems so complicated.
Well, my name is Mandy and I'm here
to show you that it's actually not as complicated as you first
thought.
There are two main ways to run your app in the cloud.
Infrastructure as a Service, which gives you
maximum flexibility by providing virtual machines in the Cloud.
Or Platform as a Service, which provides fully managed software
stacks to which you can deploy your application code,
but which has a more restrictive environment in terms
of supported languages and features.
This is a tough choice and one that we
had to consider when building the Google I/O WebRTC codelab
application.
This is a simple demo application
that allows you to use WebRTC-- which stands for Web Real Time
Communications-- to perform peer to peer real time
streaming between multiple clients.
While the app wasn't complicated to build,
there were some complex requirements
unique to the application that we
had to consider when choosing between infrastructures
of service and platforms of service.
Because we just wanted to focus on the code
and not worry about all the other stuff,
we really wanted to use Google App Engine.
The main function of this app is to allow
users to connect to the server and create rooms which
another user can also connect to.
The two users can then stream data to each other.
The JavaScript Socket.IO Library is extremely popular.
It is well known for simplifying the development of networking
for real time applications.
It looked perfectly suited for the task
as it has all of our requirements covered.
App Engine supports applications written in Python, Java, Go,
and PHP.
But how can we use it to run Node.js applications?
Well, it turns out that App Engine
has this cool new feature called Custom Run Times.
Custom Run Times allow you to define your own runtime stack.
As an example, a runtime stack could be the Node.js
interpreter, using MPM for package management
and running your application code.
App Engine takes care of provisioning virtual machines,
which are then used for building and deploying your runtime
stack on to.
You also have the option to define health checks
that App Engine can use to monitor
the health of each running instance of your stack.
Because custom runtimes allow you to build and run
your own runtime stacks, you could not only
run Node.js code, but you can run Rubium Rails and Pearl,
too.
In fact, you can run anything that
will run in the Standard Virtual Machine
and which can respond to HTTP requests.
Best of all, in many cases you can run your existing
application code on custom runtimes without modification.
One of the coolest things about working with custom runtimes
is that they are really similar to how App Engine already
works.
If you're not familiar with App Engine development,
you basically develop your application code,
pull in any dependencies, and supply a configuration file
that provides metadata which will be used by App Engine
to deploy and run the app.
You can also factor large applications
into logical components called modules.
Modules within an application share
states but have their own performance settings,
with each module having its own configuration file.
Our WebRTC application has two modules.
One is for the front end component
that handles incoming requests and is a standard App Engine
autoscale module.
The second is the custom runtimes module written
in Node.js and which does all of the heavy lifting
via the Socket.IO Library.
The first step towards deploying the example app
is to place the application level, a module level
configuration files, alongside the application
code and its dependencies.
We then need to provide some configuration
for custom runtimes.
And this comes in the form of a Dockerfile.
Custom runtimes are actually Docker containers
running on fully managed Compute Engine Virtual Machines.
Docker containers are portable, lightweight virtual machines
that allow code to run in isolation from other containers
but at the same time safely share resources
from the host machine.
The Dockerfile defines a configuration of a Docker image
and can reference another image which
you can use as the basis for a new image.
In this example that's all we're going to do.
But you can define more complex images via additional commands
in the Docker file.
Now when you deploy to App Engine with Cloud SDK,
it takes care of building the required Docker images
as well as creating and managing the containers
and the virtual machines needed [INAUDIBLE].
Once deployed your app is immediately
ready to start serving requests.
It's really that simple.
You can manage and monitor your running application
through the Developers Console as you would
any other App Engine app.
And you can also see the status of the managed virtual machines
that are running the Docker containers that
run your application code.
Behind the scenes, App Engine does
all of the work to keep your code running, including
monitoring instances and checking that they are healthy.
Custom runtimes make it easy to run Node.js applications
in the cloud.
And because you don't have to worry
about managing systems and software stacks,
you can spend more time writing code, or even using
all the time you save for a well deserved vacation.
Go here to find out how you can get
started testing with custom runtimes.
And go to developers.google.com/cloud
for more information about Google Cloud Platform.
Thanks for watching.
Now go out and build something amazing in the cloud.