Where Should I Run My Code? Choosing From 5+ Compute Options (Cloud Next ’19)


Written by:

We’re going to talk about how to make sense of
all of our compute pieces, where to run your
stuff, give hopefully a good lay of the land
of where things are at. I was talking with
folks ahead of time– a bunch of data science
related folks in the room. I’m not going to talk about
anything machine learning or data science directly,
but about the platforms that run a lot of that
stuff on our system. So might be useful there. Let’s get going. So the key question. Where should I run my code? And unfortunately, the
answer is it depends. Thus we have a
whole talk about it. So let’s get into it. At a really high
level, I’m going to talk about five
different products. And I was talking with folks. I think half the challenge in
getting started in Google Cloud is actually just so many
names of all of the things. There’s like a
couple hundred names you need to learn just to kind
of make sense of all the parts. So these are the names we’re
going to talk about today. And starting at the top, we
have Cloud Functions, which is functions as a service. App Engine, which is
for taking a set of code and running that as
a website, usually. Cloud Run, which
is new, and we’ll talk about that in details– announced today. Kubernetes Engine, which is
a hosted Kubernetes cluster. And Compute Engine, which
are virtual machines, network and disk, running there. So just out of curiosity, how
people heard of containers? Sorry. Thank you for
raising your hands. And serverless? And everybody has a
different definition. We have 100 people here. We probably have 100 definitions
of serverless is my guess. So my operating
general definition here is mostly around the kind
of operational model of you pay for the actual
usage you get. The infrastructure
itself is managed. You focus on your code,
that sort of thing. There’s another angle
as well, though, that I think is interesting. And we usually take
these directly together. And there are cases where we can
tease these apart a little bit. It’s the programming
model itself, like what it looks like
from a developer standpoint. And most things
that are serverless are not actually storing state
between function calls, right? You have side effects of
your code or return values of the functions. Usually kind of
a hosted service. Event-driven is a word I’m
going to talk about a bit more. But usually there’s something
that causes it to happen. A request comes in
or an event fires. And we’re trying to make
these more and more open so that you can run
them in lots of places. And I’ll talk about that a bit. So the key question here
is, there’s so many choices. Am I going to make
the right decision? Kind of decision
paralysis sort of thing. And I get there. And my goal for the talk
is really two things. We kind of get a big
map of the territory about what these pieces
are and relax a little bit about the risk here. I’m going to try to
make the case that it’s fairly easy to move
around after you’ve made a starting decision. So no worries. And at a really
high level, and this is the kind of able
to move up and down. The top two, you’re mostly
focusing as a developer on the code you write– the actual function signature,
what returns from it, or the URL maps
to different parts of the code, that sort of thing. And down here,
we’re mostly focused on building a
runtime environment with the right
binaries, the files it needs, the container
of the code itself. And then at Compute
Engine, we’re looking at a whole
operating system. They’re virtual machines. You can install
anything you want in them, that sort of deal. So just going to go all
the way through all of them and move kind of quick, and
then circle back around. So Cloud Functions. When you’re using
Cloud Functions, you are writing
just one function, and it maps usually to a
URL, but some kind of event that comes in. And as a developer, you just
think about what inputs, what side effects, and what outputs. And that’s the whole
world while you’re thinking about that function. The events can come from
a lot of different places. It’s very common for them to
come in as an HTTP request. But in cloud– more words– Pub/Sub is our messaging bus. Cloud Storage is
an object store. And there’s a few
other options as well, like hooks to
Firebase and the like. And these are fully managed. You just write the
code, hit Deploy, and it scales up and down. And you pay for exactly
what you actually use, nothing more, nothing less. And it auto scales
with actual usage. So the idea is,
hopefully, you can just concentrate on that
one part of the world and not worry about
anything else. So when you’re using
these, you are thinking about doing system design. You’re thinking
about what events are going to cause the function
to execute and what it does. So that’s the mental
space you’re in when you’re working with Functions. And it’s the classic
definition of serverless, in a way, so it’s a good fit
for things that are serverless. When you’re making integrations
between other pieces, events are coming from
Pub/Sub or Storage, you can set things up so you
send a new object to a Cloud Storage bucket and
that causes a function to fire that does
something to it, maybe makes a different
version of it, copies it somewhere else,
that sort of thing. And it’s used sometimes
in ETL processes or transactional things where
you need to, for example, the storage example– every
time a new item goes in, you do something to it. And then my favorite
kind of mental model is just thinking of these
are the glue of the web. This is the HTTP glue that
connects everything together. On the constraint side, you
are seeing the entire world through this
function granularity. So as you build more
complicated systems, you piece together more
functions to do that. And that works pretty well. And then at a certain point, it
might be hard to reason about. Or it might be more challenging
to monitor or troubleshoot. And so pay attention to that. And in Cloud Functions, there
are only specific runtimes available. So if you’re running in
those languages, awesome. If you’re not, you might
not find them as useful. So what does this look like. Let’s see. Look at Cloud Functions. Actually, let me just go
to the top a little bit. This is the Google
Cloud Platform web UI looking at a specific project. And in my opinion, this is the
single most important thing, the hamburger button, because
it gets to all the other pieces. If you don’t find that, it’s
really hard to do anything. But if we come in and
look at functions, I’ve got several
functions set up. And let’s go ahead and use Node
because I think a lot of folks are using Node JavaScript
based functions. And this one’s already built.
So it’s got some source code. And all it’s really
doing is saying, for every request that
comes in, let’s look for some stuff in the message
body, or in the request, or in the body. And if I don’t find that,
just use hello world and return that back
out to the function. So this is kind of hello
world of functions. And it automatically
gets a URL, and you can map additional ones. But if we run this, we
get the default input. OK. But I wanted to do
something different. So there’s this testing
window over here. So we can actually
kind of simulate giving it a body in a POST
request as part of the post. And so we go message, and
hello lovely Next peoples. That’s you. And we run the function, and
we get a different output. So yay, proof that it’s real. Additionally, we
can view the logs because the actual
execution logs and any log messages you
emit during the function call go to Stackdriver Logging. So you can see them all in a
central place and the like. So it’s a very, very quick taste
of what that can feel like. And of course, you can also do
that through the command line or via APIs as well. Just kind of the
web interface to it. So why would you
pick Cloud Functions? So a big part is you don’t
think about the infrastructure of the servers at all,
like classic serverless. And this granularity of payment. So if you have things that are
very spiky or you don’t run very often, they will
be extremely afford– like inexpensive– I’m trying to avoid
saying “cheap”– they’ll be inexpensive
all the way, if you’re not running
them very often. And they can scale
up to lots of load. And it’s a very straightforward
developer experience. You’ve got your
code and it runs. Deep breath. And now App Engine. So App Engine takes
the code focus but goes out as a level to
think about a whole application. So we’re talking about
usually a web application because that’s the sweet
spot for App Engine. And so you’ll have your
URL mappings of this URL calls this code, this
URL calls that code. Maybe there’s some shared code. There’s a whole structure
of the application that’s all one piece. So that’s kind of the way
you see the world when using App Engine. Again, no service to manage. It scales up and
down really fast. But it has some
additional features like versioning
of the code base. And then you can do
traffic splitting across those versions. So as you do a new
release, you can say, oh, I’d like to give a
small amount of traffic to the new release. And then– whoops– roll that
back, that sort of thing, if it doesn’t work out. App Engine has existed longer
than Google Cloud itself has, actually. It predates GCP. So it actually has three
different execution environments. There’s a classic kind
of Standard Edition, and there’s our newer
second gen runtimes. And additionally,
you can actually use the same view of
the world and have the code deployed to
VMs, and that’s called the flexible environment. So there are some differences
between these environments. If you’re starting
new projects, I highly recommend go straight for
the second gen pieces. If you need to, for example,
if you need to listen on ports to do web sockets
or something other than HTTP, other
than short HTTP, you can do that on the VMs. If you need certain
machine sizes, like if you need a really
particular big machine size, you might go to flex. But by and large, people are
running in the second gen standard nowadays. And in this space, the runtimes
are actually open source. They’re written to be idiomatic. They should feel like
the programming language you’re using. So it should feel like
Python to Python people and feel like Node
to Node people. We have the set of
supported runtimes. There will be a talk
at this event talking about a new alpha for our
Ruby runtime for Ruby folks out there. And you basically call
GCP APIs directly, whereas in the original App
Engine standard runtime, which predated the rest
of cloud, there were a lot of built-in
APIs for things like memcache and other things. So when you’re using
App Engine, you are primarily thinking
about your code base, the HTTP requests that
come in, like what URLs and where they map,
that sort of thing, and different versions of your
app for going forward and back. In fact, you can actually even
break the app up into modules if you need to. But that’s the
primary mental model you’re in when you’re
using App Engine. So it’s a great fit. Its natural sweet spot is
HTTP web request response applications. There’s an execution
timeout so you can’t do really long running things. But it’s meant for these back
and forth request things. It scales very well,
both down to zero instances of your
back ends running, all the way to very high. So a lot of folks are
using it in advertising, for example, where you have
almost no traffic until an ad thing runs, and then it
goes really, really big, and then it drops
back off or maybe long tails out for a while. But you need to
leave it up, only paying for what you’re using. Again, there are only
certain runtimes available. So if you’re running
in those languages, you’re going to be happier. You might not be able
to use it if not. And the window to
the world is the web. That’s how it sees
everything is through HTTP. And on the flexible
side, it can run anything that fits in a container,
but it’s running on VMs and they don’t scale
quite as quickly. So we need to
leave a few running so it doesn’t scale to zero. And it takes a little
longer to respond to new traffic coming in. By longer, I mean like
minutes-ish, a couple minutes kind of territory,
rather than seconds or sub-second kind
of time frame. So you might choose App
Engine because it lets you just focus on your code. Maybe your organization
is primarily developers. That’s what you care about. Or maybe for this
particular app, you don’t want to
invest the ops into it because it’s not
your core thing, so that part of your system. It’s very much optimized
for web-focused workloads. And it’s especially
good for things that vary a lot over time. And this stat is
probably out of date, but I couldn’t find
the newest one. Definitely lots and lots
and lots of traffic on App Engine as a whole. And we can handle
the load that you’ve got there is the
point to make there. So now, actually,
we’ve got a new thing. And there is a talk
later today that goes into the details of this. This is Cloud Run. And what we’re trying to do– if you look around
the internet, there’s a lot of serverless
versus containers kind of conversations,
like which one do you do? Like they’re in a duel to
the end of time or something. And we’re trying to
bring these together more like peanut butter
and jelly or some best buddies or something like that. So we’re trying
to give serverless kind of agility,
that pay for what you use to scale
up and scale down, to nearly anything you can put
in a container that listens on HTTP. So what it is– you give it a URL
to an image that has some code in it that
will listen to HTTP whatever the port environment
variable is. And in return, you get something
that scales up and down very quickly. You get the SSL
termination, the HTTP request binding through all the
load balancers and the like. And really nice
thing for efficiency is that it’s not
just single threaded. If you’re running Java or you’re
running Go or something has really good concurrency,
you can actually handle multiple requests from
the same binary execution. And so if you’re running
something that actually has to wait on
other network calls, you can actually get
a lot of efficiency there in what you’re paying for. And scales up and
down really fast. And you’re paying
very, very precisely for the CPU and memory
you’re using down to 100 millisecond granularity. That’s the hosted,
fully-managed version. With the same
developer experience, there’s also a back end that
runs on top of Kubernetes. And so you can deploy
things in the same way, have all the load balancing and
everything set up correctly– the service endpoints and
everything hooked up– but it’s part of a Kubernetes
cluster you already have or that you’re trying to
build out on your systems. It deeply integrates with
the policy and control you’re already running there. If you need custom
hardware, you need specific kinds of accelerators
like GPUs or TPUs available, you can do that. And because it’s running
on top of Kubernetes, we can actually run
this in a lot of places. So essentially,
we’re trying to– if you’re coming from the
serverless angle of not thinking about back ends and you
want to just have more options, think about the fully
managed Cloud Run. If you’re coming at
this from, I want to offer serverless
experience to the people who are using my Kubernetes
cluster, then the running on top
of GKE angle makes a lot of sense for Cloud Run. So same developer experience,
two different back ends. You can move between them just
by redeploying the same app. So you can start one place
and just redeploy to the other and go. So let’s try to make this real. This is the Hello World app. So we’re not going to go
too real, but it is real. So we’re basically– sorry. Let’s start at the beginning. We’re back at our project top. Choose Cloud Run. And then we’ll go straight
to Create Service. It includes a handy
little URL to an image that’s known to work. So I’ll go ahead
and paste that in. I’m just going to call
it hello us-central1. And here’s where you can set
some more information about how much memory you’re
going to give to it and how many requests you’d like
each instance of the software to handle. So if you’ve got a
single threaded app, you can that to 1. If you can handle more
things at the same time, you can set it higher. So we go ahead and hit Create. This is doing a bunch of
stuff in the background, actually deploying
the containers, configuring load balancers,
making sure we’ve got SSL and all stuff set up. This is going to be
the URL to our app. If we click on it, it
doesn’t work right now. So yay, it’s actually real life. And something that might
be a little bit surprising is if I put my cursor in
the lower right hand corner, the screen turns off. That was probably not expected. Under the covers, there is a
YAML file to describe this. And it is based– if you’ve done a lot
of Kubernetes stuff, you might have seen
these configuration files before in YAML format. And this file, you can
take this and run it in other environments. So you don’t have
to care about it, but you can take this
full configuration and run it in other places,
which is pretty fun. OK. And it says green check box,
so let’s try to refresh this. Forbidden. What did I do wrong? Let’s refresh all the things. Is this the Chrome thing where
you need to Control Refresh? Demo fail. Oh. See, I’m not authenticated. Thank you, member
of the audience. I didn’t check the box for
actually authenticating this. That’s not going to
work very well, is it, for leaving it wide open? I did that wrong. Let’s deploy a new revision. No, we’ll go all the way
back and just make a new one. This is speaker being stubborn
after making a mistake. This is the box that
I should have checked. Thank you. And we will grab this URL, give
it a new name that is awesome. And hit Create. So while that’s going,
I’m going to give you a sneak on the next little bit. So when you’re using
Cloud Run, you’re thinking about building
the container environment for the processes you have. So you can run any
language you like. Anything that will run
on Linux in a Docker container you can run that
understands how to do HTTP. So you look for the
environment variable port, you open a listening
socket on that port, and you’re good to go. It is, however,
stateless, in that there is a local file system
but it’s actually in memory. And so between invocations of
your app, it just goes away. So you can’t store a
lot of stuff locally and you shouldn’t, other than
maybe cache if you have to. It’s mostly there
for compatibility with libraries that expect it. So you should think everything
that comes in and goes out. Let’s try to go back and see if
we got a new URL deployed just now. Moment of truth. It’s running. Yay. Thank you, members
of the audience and supporting me in this
really alive demo thing. So this is a good fit for
things that are stateless. Again, HTTP request
response workloads. That’s how you talk to
it is through the load balancers over HTTP. It can handle bursty traffic. It scales down all
the way to zero. You pay for exactly
what you use. And if you have a scenario
where you really need specific runtimes or languages
or binaries around there– because it’s not just the
code you’re actually writing. You could include other
things that you shell out to or whatever you need to
do in that Docker image to solve problems. If you’ve got some really
gnarly stuff that’s been around the office forever,
if you can put in a container, you can put that on the web,
make it feel serverless. On the constraint side
it is, again, containers. So it has to be in a
container to run it. And because we’re getting
a little more focused here, how you build those
images is up to you. So it depends. You have to decide how
you’re going to do it. We have Cloud Build. There’s lots of other
CI/CD tools out there. Anything that results
in a Docker image in a repository that has
the other things like listens on a port and
stuff you can use in here. So why would you use it? If you want this
developer experience, this kind of serverless
developer experience, you have the option of having
it be fully managed or deeply integrated with Kubernetes. And you can decide later at ops
time, even a different group of people, what that
deployment environment actually looks like. So you can do all of
your dev work in one and then decide later
to switch to the other just by deploying the code. And you can run
basically anything that runs in a container over HTTP. And then I’ve got a new word
that shows up here at the end. I’m claiming open and
Knative, Kubernetes. So you can actually run
these same images on Knative on top of Kubernetes anywhere
that Kubernetes runs. So if you want to run this
on your own machines– you’ve got your own data
center, you’re in another cloud, you want to run it
in all the places– you can take this same
runtime environment and run it in all of those
and make that decision at deployment time as well. So there’s Cloud Run. Hopefully you
think it’s awesome. Give it a try. The place we’re at right now
is we’re just releasing it. So we want everybody
to try it out, see what appeals to them
most– maybe it’s something we didn’t think of– and let us know how that works. What did you try to do
and how did it turn out? So I will have my
contact info at the end. I would love to hear
from you, did it work? Does it work for you
for the problems? Did something come to mind
as I was describing it? And if you try
that, does it work? Next level down, Google
Kubernetes Engine, which is just
managed Kubernetes. So the thing I’ve
been doing, though, is I’ve said
Kubernetes a lot here, but I never said what it is. And I won’t make you
raise your hands, but I’m sure somebody is
like, WTF, Kubernetes? Sorry. So Kubernetes is a
management system for running lots of containers. So containers give you this
isolation for a process. It sees the same files
every time it turns on. Every time you start one up,
they see the same exact state. So try to solve that, well,
it worked on my machine, but it doesn’t work
over here problem. And if you want to
do a lot of those, you end up wanting to
that on lots of machines. And that’s what
Kubernetes is for. It lets you talk
to a whole cluster as if it’s kind of
one big machine. So you can say,
oh, hey Kubernetes, I want to run 1,000
of those, and it’ll figure out where to run
them, that sort of thing. And then a whole
bunch of features for making that
relatively easy to manage, reliable, sensible,
troubleshooting, all the fun stuff. And I’ll make the claim. I think it’s become a de
facto way of doing that, running containers
on lots of machines. So Kubernetes Engine is
hosted and managed Kubernetes on Google Cloud. So we run the
master node for you. We keep the compute
nodes up to date, basically kind of moving
things off of them and rebooting, creating new ones
if they need security patches or what have you. Do the software
updates for Kubernetes itself and the underlying
OS, and then do integration with things the load
balancer, and do cluster auto scaling to follow the
load that you have. So basically makes it easier to
operate a Kubernetes cluster. And if you’re starting
with Kubernetes or interested in getting started
with Kubernetes, in my opinion, no matter where you
plan on running it, this is a really
great place to start. Because you can just,
in about five minutes, have a cluster up and going. You can experiment with
it, see if the model works for what you’re trying
to do, and go from there. So when you’re using
Kubernetes, you’re definitely thinking at a
different level of abstraction than we talked about so far. You’re thinking about
how different parts of your software talk to
other parts of your system. So you might have five
instances of a web front end, and one database, and a
couple of cache servers or something like that. So it starts to feel a little
bit more like a UML diagram, or a diagram you might
draw on a whiteboard with your colleagues. And then we express them
as these YAML files. But you can actually
take these– that are computer-oriented
descriptions of that whiteboard thing– and push them in
a cluster and have it actually create
that structure, which is really powerful. And you’re thinking about
the application as a whole, and hopefully not
thinking much about, how many computers do I have? How do they talk to each other? Because Kubrick and his
managers how the things find each other, where the
processes actually run, and that sort of thing. So it keeps you thinking
about the logical connections between your app and
insulates you, in many ways, from the actual
execution environment. So you can run it in different
clouds or on your own machines. So that’s the key
thing in my mind. It’s a really good
fit for scenarios where you need to run in
multiple environments. So you need to have
the same thing run on a dev cluster that’s
on your own machines, but you’re going to deploy
it to a cloud or two clouds. Or you need to
make sure you have the same environment
for dev, test, and prod, but you can’t have all the
same number of machines, that sort of thing. If you really want to take
full advantage of containers, go all in, there’s just a lot
more configurability available in Kubernetes. It does make the
most sense when you have really good communications
with the other teams in your organization
because you’re going to need to have
conversations about how things get built, how security
patches are going to work. The ops folks and
devs folks agree on approach and some
conventions in places, probably that they can all
commit the same repos to make changes if they need to. And you’re probably
going to want some sort of build
pipeline system to do that collaboration in. And it does give you– like you have
processes listening on ports that can talk to
each other via load balancing routing. Everything I’ve
talked about so far has all been like
HTTP, HTTPS, right? So you want to do
other stuff, there’s lots and lots of options for
connecting the pieces here. Still, you must
be in containers. There can be some
challenges around licensing, where licenses for some apps
are actually per machine. So you have to do some
pinning or some special things with labels in order to make
sure that the processes always end up on those machines that
you’ve got the licenses set up for. And Kubernetes has
an opinion about how things talk to each other. And so that can influence
the architecture that you decide to do. So Kubernetes, Kubernetes
Engine can insulate you from a lot of infrastructure. The reason Google’s excited
about a lot of this stuff is it enables high
utilization, which saves money. You can run the same stuff
reliably at higher utilization and not leave a bunch of
open headroom for every app individually because you’ve
got a reliable cluster you can move the processes around on. So you can actually
safely and reliably run much higher utilization, which
directly equals save money. The abstractions
that it provides are a real sweet spot
for a lot of folks. And you are going to
have to figure out what you’re going to do
for logging and monitoring and how all the
pieces fit together. So there’s that. OK. Next level down,
virtual machines. So now we’re in the
territory of we’ve got an operating system of some
kind and everything above that is up to you, all
of it, including OS patches and the like. Which means you can install
whatever kernel you want and additional things
you may need to do there. If you’ve got scenarios
where you need that, you can do that on these VMs. One thing I want to
highlight is we often talk about scaling
out in cloud, right? You know, lots of little
processes and the like. This is an area they’re
getting quite large. We just last week
announced machines with up to 12 terabytes of RAM. And I went to another
company’s retail site and looked for big hard disks
that I could order yesterday. And the largest I could
find was 14 terabytes. So if you want to go order a
hard disk, it’s 14 terabytes. Pretty soon you’re going to
be able to just virtually turn on a machine that has
12 terabytes of memory. So yes, there’s limits on
how far you can scale up, but they’re probably higher
than we are thinking. They start very quickly,
usually around 20 seconds. We have a bunch of
pre-built OS images that are managed
in the sense of we make sure that they’ve got
stuff installed on them that makes it easy
to use Google Cloud. You can get the On OS
Update systems kind of go through repo mirrors
that we have. So as security patches happen,
it all happens fairly locally. So consider those if you can. But you can actually make a
block device that is bootable, and upload that
and boot off of it. So you can do all the way
down to running whatever you want on these machines. I want to highlight– these are virtual machines. They’re CPU, network,
disk and the like. But a lot of the pieces
are not so intuitive. So the disks are most– the persistent disk,
which is our default disk, is a network attached storage. So the block device
is actually spread out on thousands of machines. And they actually compete
to return the data back. So the random read that you
expect from spinning disk, even though it’s spinning disk,
it’s actually lots of them. So you get a really
flat latency instead of a spiky latency on reads. And it’s faster than
you would think. And because these pages are all
spread out all over the place, you can actually take
a snapshot of the disk while it’s connected with almost
no interruption on the machine. There’s just a
little blip where you need to have a lock for a
couple of milliseconds to say, this is the most recent
block that’s there. And then behind the scenes, it
can actually copy that all off and make a snapshot
of the full disk that you can then restore
to make another computer with exactly that data on it. And you can do that anywhere,
in any of the zones we have. So you can get a
snapshot in the US and restore it in
Asia or Europe, or wherever, and do that. I mentioned to
somebody earlier, that leads to some
non-intuitive effects that larger disks are faster. Wait, what? So bigger disks are
actually faster. So if you’re doing tests
of speed on these VMs, look at the docs and
look at the trade-offs because you need to
make sure your disk is fast enough for
the IOPS you want. And the reason for
that is that disks come with a combined amount
of I/O and storage on them, and put those on
the data center. And we want to be
fair to people who are trying to get
all the IOPS possible and other folks who are trying
to store big piles of data. So the two are
actually linked up. So if you want the fastest
throughput on the disks, you need larger
disks and vise versa. I guess you want
lots of storage, you need larger disks too. So pay attention to that when
you go do performance testing. And the other piece. These machines come and
go really quickly, right? 20 seconds, the like. You don’t need Kubernetes
to get auto scaling. You can actually make what’s
called a managed instance group of identical– you make a VM template. And then it will scale up
and down multiple machines, load balance across
them, and do that based on the traffic you have or a
value you can set in the API. So you can actually scale up a
cluster and down very easily. If you’re trying to build
a disaster recovery site, don’t leave all of them
running all the time. Have a managed instance group
at the front ends running one really small one. And then, when the
disaster actually happens, then spin up all the machines. You save so much money. It’s really easy to
think of these as a one to one equivalents. And I want to
encourage you to think of them as being very elastic. And that’s true for the
individual machines. So you have these
groups of machines, but I mentioned
these rates, right? You can actually mix and
match and have a lot of memory and very little CPU
or the opposite. And you can start with a
machine that’s very, very small, stop it, change the settings
and reboot it to have 160 VCPUs. So it starts with two when
you’re like, OK, just reboot. Now I’ve got 100. So it’s very, very elastic. Take advantage of that. So when you’re using virtual
machines, using Compute Engine, you’re thinking
about your software, what’s running on the machine. You’re thinking about
the operating system itself, the disk images,
the CPU, RAM, disk ratios, the networking, how
they talk to each other. There’s a lot more
moving pieces. But you have control
over all of them. There’s cases where you
really want and need that. So it’s all there. So it’s a really, really, really
good fit for existing systems. So it’s almost always
the right first step for a system that
already exists and you’re trying to get some
advantages of cloud from it. This is almost always
the place to start. You’ll get a lot of
benefits just moving the machines over, things like
these snapshots to take backups and the like, the networking. There is a possibility. All I want to do
is run a container. I just got this one image. I just want to run it once. As you’re starting a VM, you
can actually click and say, I want to run this container. And we’ll start a
container optimized OS and start that one container
and just do the one. If you have needs for a
specific kernel or OS version, particular license
requirements, probably if you’re trying
to run a database, you’re going to be happier here. It’s possible to do in
some of the other things but there’s a lot
more moving parts. And then, again, if you’ve got
network protocols beyond HTTP, HTTPS. The scaling is more granular. It’s still pretty
quick in the big terms. But it takes 20, 30
seconds to set up a VM. You can start lots of
them in a minute or two. But there’s a granularity there. If you’re trying to do
really spiky workloads, it might not keep up, and
you want to look higher. I’m going to skip most of
the demo but I can’t resist. There we go. And basically, the way this
looks is you pick a name. You choose the kind of balance
of preset number of CPUs versus memory. Or click Customize and
you get these sliders. And you’re like, oh, I
want this shape machine. And I’ll pick a different
disk and that sort of thing. So I’m not going to
actually do this and log in because I’m trying to say
too many things in one thing. But I wanted to highlight
down here at the bottom– and this is true for
a lot of the UI– there is this little thing that
says, oh, what’s the equivalent REST or command line? And this will give you the
actual JSON that the web app is going to send to the API to
do what you do when you click, or the G Cloud command
to do the same thing. So if you explore a flow
that you like and you want to automate
that, you can actually copy this out, put
it in a script, put it on a scheduled
task, and go. So it’s a really powerful way to
kind of learn your way around. So why Compute Engine? You want consistency. You should be able
get the same behavior. I stopped and somebody
laughed– hey– the same behavior in test
and then later in prod. You get these very custom VMs. You can actually– I
didn’t even say it. Because these disks are
virtual block devices, you can actually
make them larger while the machine is running. So anybody run out
of a disk before and had a machine go down? You can actually make the
disk bigger while it’s on. It’s really powerful. We have a lot of
things we’ve done in billing to try to make it
really easy to understand. So it’s basically billed in
small increments, like seconds. And if you just leave
it on, we automatically give you discounts. So there’s up to
like a 30% discount if it runs for a whole month. And buy “it,” I mean number
of CPUs and I’m out of memory on the same kind of general
machinist shape, not specific machines. So you can restart them and that
sort of thing and pay there. And we have this thing
called preemptible machines that are our attempt to get
you to think really flexibly. Because they’re
up to 80% discount of the price of a regular VM. They’re the same VMs. But they could be stopped within
30 to 60 seconds at any time and they will not live
more than 24 hours. So it encourages you to think
about writing your tools in terms of jobs that
come in, do some work, move on, that sort of thing. And if you do, you
can just immediately save a quarter to a fifth of
the overall price, just boom. It goes down to that. So it’s 80% off,
like 70% to 80% off. Look at preemptible machines. It’s totally worth it. But it will turn off. So make your stuff so that
it reboots and works off cues and things. And we use Compute
Engine to build a lot of our own services. So a lot of folks here,
we’re talking about data. So Dataflow and
Dataproc are actually built on top of Compute
Engine instances. The managed SQL services
we have actually run on top of Compute instances. These are very powerful
and really strong building blocks for
your systems as well. I promised to answer
this question, right? We’ve mostly just talked
about a bunch of things. So we’re back to here. Hopefully these make more sense
than they did a little while ago. If, in hearing this, you’re
like, oh, that’s it, great. Start there. But probably we’re still in
“it depends” a little bit. So here are some
additional thoughts to think about that may
push you up or down in between these abstractions. So you may have a
different abstraction level you want to work at. There may be some technical
requirements you have, or some things about your
team, the people you work with, that might make you want
to choose one or the other. So thinking in terms
of abstractions– this is just summarizing
what I said there– you’re thinking about events
and functions, or just your code base, or
the container format, or the UML diagram of the app,
or the actual representation of a machine. So what abstraction do
you want to be working at? And it might be different
for different problems. You may have
technical requirements that are going to push
you one way or the other. And in case, usually
down, like the stack. So you’re usually going to need
to go below a given abstraction level. So if you need direct
control over URL routing, you want to share
code more easily, have more control of versions
and traffic splitting, that’ll bring you from
functions to App Engine. If you need very specific
programming languages or environments and
the like, that’s going to bring you more towards
setting up the container to run in Cloud Run. If you need specific
things from your OS– you’re doing hybrid work,
network protocols beyond HTTP, that’ll bring you
probably to Kubernetes. And then you want to just
basically own the whole thing, that’ll bring you to VMs. There’s also billing model
differences between these. So how you plan for paying
for them and how it works. So Functions, App Engine,
and Managed Cloud Run are very granular,
pay for actual use of the CPU and memory,
network involved in doing that specific transaction. Cloud Run on GKE, GKE itself,
so Kubernetes and VMs, you’re standing up
a set of resources and paying for them
while they’re on. And then when you turn them
off, you stop paying for them. So there’s a different
model for how you pay for it, how you
plan for that payment and predict what it’s going
to cost, how you do that. So that may affect
your decisions. The teams you’re working on. Is it a group of all devs
working on a new thing? That’s going to have you
in a very different place than we’re trying to keep this
stuff working and we have to. My favorite definition
of Enterprise is it’s any environment where
most of the applications don’t have an application
team working on them. You’ve got a whole bunch
of stuff that has to run, but you can’t change them. So that’s going to probably
have you start more towards the Compute
Engine side of things. So some balances there. If you’re trying to find a
mapping of other things– I attempted to make a
map of how you might do similar things in other places. So functions as a
service, there’s lots of– I think all the clouds and lots
of open source environments have a way to run functions. I struggled a bit to
find a clear equivalent for App Engine, maybe something
like Cloud Foundry or AppScale, which is an open source App
Engine like environment. Cloud Run is basically– the UX is a little
bit different, but the execution environment
is Knative and Istio on Kubernetes. So you can run that
same stuff there. You can move those
workloads very easily. Kubernetes is Kubernetes. So the environment around it is
different, like what you call, but like the same
stuff should work wherever you can run it there. And then, basically,
there’s lots and lots of options for running whole
OSes on virtual machines. So some of these are easier to
do hybrid or multi environments than others. So back to making
the right decision and kind of no worries. Hopefully, this feels a
little more comfortable. So you can definitely
use them together. Most real systems use
multiples at once. It’s not like an all or
nothing kind of thing. We have tools that make this
a lot easier and better. I won’t go into details. The photos here
are probably good. But Pub/Sub allows
you to send messages between all the things. Storage lets you store
arbitrary blobs, like data, separate from all the things. Cloud Tasks are like a queue
of things that need doing and you want to make sure
that they all happen. So transactional
queueing kind of things. And Scheduler is Cron
in the cloud, basically. So at this time, run that and do
that every week kind of thing. So those all help you
glue the pieces together. And you can move
up and down these. I’ll be honest. It’s easier to move down
in terms of human effort than it is to move up. So if you get things
into containers, that gives you more options,
and you can move back and forth more easily. And we’re trying to
make the environments as similar as possible. From all of these
environments, you can hit a thing called
the metadata server and get tokens for the
scope of access rights you have around Google Cloud. So you can always look to
there to get your security token for what
you’re allowed to do, whatever the environment is. You can use Stackdriver
from all of them. We’ve just today
announced VPC access. So you can have your App
Engine and Cloud Functions show up on the 10-Dot network
of your VMs [? and not– ?] like do the public
internet loop. We’re working on
that for Cloud Run. And here we are back here. So my claim is if
you’ve got something that looks like
these, that’s probably the place to start evaluating
and then look at those options. So thank you all
very, very, very much. [MUSIC PLAYING]

2 Replies to “Where Should I Run My Code? Choosing From 5+ Compute Options (Cloud Next ’19)”

  1. Patrick Parkins says:

    Good talk, definitely interested in cloud run

  2. 0311mitza says:

    i figured a sweet spot thats still kind of fuzzy: what about app engine flexible vs cloud run. both run containers, both support whatever environment as long as you can get into a container. only difference i can see is that for GAE flexible you cannot have scale to 0 while on cloud run you can. also traffic splitting and versioning and custom underlying VM for GAE flex vs cloud run. so is it safe to say that cloud run si something of a mix the capabilities of GAE flexible over GAE standard, with the simplicity of GAE standard instead of GAE flexible?

Leave a Reply

Your email address will not be published. Required fields are marked *