[MUSIC PLAYING] BRIAN DORSEY: Hello, everyone. Thank you for coming. Thank you for being here. This is going to
be a lot of fun. And this is, where
should I run my code? A few minutes late-- so awesome, thank
you very, very much. My name is Brian Dorsey. I am in developer
relations on Google Cloud. And let's get going. So I wanted to quickly get a
sense of kind of who's here today. How many people are relatively
new to Google Cloud products? Awesome, so like
most of the room. We're in the right
place together. And this talk is geared
mostly at that level. If you already know
deeply the stuff, you might learn a few things. But it's mostly going to
be kind of overview things, and what's a good fit, what
are the challenges, what's not a good fit, that sort of thing. Other quick question. How many folks here are
kind of developers, kind of that angle of the world? Kind of writing
code, IT operations, kind of that side of the world? And maybe you raised
your hand both times. Awesome, or perfect. OK, so we've got maybe
70%, 30% kind of mix. That's great. So here's a bunch of logos. And we're going to talk
about all these today. So these are the four primary
places to kind of run software that you write or
bring to Google Cloud. And Compute Engine is our
VMs, our Virtual Machines, the networking around that. Most of the rest of this
kind of lies on top of that. So that's kind of why
I drew it this way, so that it's kind of
in layers, logically. Container Engine is
hosted Kubernetes, so it's the system for running
lots of containers on VMs. App Engine is the original
Google Cloud in a way. You kind of push your
code up, and then we will run it for you. And Cloud Functions
is just one function. It takes some inputs, has some
outputs, and does some work. And we handle all the rest. So that's the
high-level hierarchy. If you just want to bail
right now, or the take away at the end of the talk, very,
very some simplistically, Cloud Functions are when
you have a primarily event-driven work. You've got some HTTP
request that comes in, or a new object in a
cloud storage bucket, and you want to do
something about it. App Engine is focused
on making your web code run extremely well. It's optimized for that. And it's code first
kind of thinking. Container Engine is a system
of containers working together to solve your problems. And Compute Engine
is, basically, kind of everything else,
or even all of those things if you want. It's VM. So you have full
control to do whatever you need to do to
connect things together. It's also a really good
fit for existing systems. OK, so that's the
framework for the talk. But does that
answer the question, where should I run my code? Probably not. And the real answer is, as
in all good computer topics, it depends. And so what we're going to do
is run through each of these. And I'm going actually
start at the bottom-- because they work in layers-- and kind of work our way up
through the different pieces. And for the most part,
they inherit the attributes of the lower layers. So you just get to work at a
higher level of abstraction, so kind of a more
focused workload. So I'm going to
start with bottom, work our way up, talk
about things that are a really good fit for those. And you may, at the end of
that, or through that process, say, oh, that looks like
my problems, like my world. And you may just go, boom. And then I'll point you to some
talks, and some other resources to follow up on that. But there's some other angles
of thinking about this too, not just kind of
straight product-centric. So we'll revisit the where
should I run my code, and then go into next steps. But this is kind of
like this big decision. Like, we're going to spend
the whole talk on how to make this one decision. And I'll get this
back at the end, but this is a relatively
low-risk decision. You can move things around. You can mix and match. And there's a lot
of options here. So no worries on-- it's a low risk. Let's start with Compute Engine. And Compute Engine
is virtual machines like at a very high level. It's virtual machines, network. You get to inherit the
network the Google Cloud platform is built on. And what makes these virtual
machines special, in a way, is that they're built
in Google data centers. They live, essentially,
on the internet. And the interconnect
between those machines is very, very fast. In numbers, these are very,
potentially, large machines. So you can go up to 64 CPUs. You can go up to 416 gigs of
ram, 64 terabytes of disk. We now have GPUs, if that's of
interest for your workloads. And all of these pieces are
independently configurable. So you can mix, and
match, and create the machine shape that's
right for your workloads. So especially for a lot
of existing workloads, it's hard to tune them. They're kind of like
a certain shape. And if you're in
that situation, you can kind of create machines that
are the right shape and size. So this is, you
could put whatever size disk on whatever size
instance, that sort of thing. The one constraint is
there's a ram to CPU ratio. They're a little bit connected. These start relatively quickly. So you go, in about 30 seconds,
you're running your code. So the machine gets
provisioned, boots, and gets off into your boot
scripts and your software. We have a bunch of
pre-built images. And it's virtualized hardware. So you can take your own images
from other places and use them. Lots of different options
for Linux OSs, and also Windows Server. So got that there. I'm going to dive down
deep in just one part, just to give you an example
of how rich this really is. And there's a few
Compute Engine talks I'll recommend you to later. But just to dive deep
for just a moment, the disks here are amazing. So you get a slice of an entire
data center worth of disks. So while you're
provisioning something that is a spinning
disk-- you know, I'd like a terabyte of disk. That's actually on hundreds
or thousands of disks out in the data center. And so when you
make a read, we pull from a couple different
places, and actually, bring that back up to you. So you get very
consistent performance. And the random
read is very good. You can pick whatever
size you need. And network-attached
storage is our default. That's what we boot
all the machines on. That's how most of our
internal workloads work. We're really big fans of
network-attached storage. There are some cases where you
just need the really, really low latency IOPS. And so we also offer
machine-attached SSD for those scenarios. But most of our workloads,
most of the workloads we see people use, use the
network-attached storage. And they're independent
of the VM lifecycle. So you can detach one from a
running VM if it's a data disk, attach it to another one. You can make snapshots of
them while they're running. You can take those snapshots. And you can create
new disks from them, including in completely
different regions around the world. So if you're thinking of
things from an IT perspective, and you need to image a box,
it's just a button click, or API call. And then you can make that
available somewhere else. One gotcha as you're
evaluating the disks, larger disks have
higher throughput. So you get a bigger
slice of the data center. And so you get more throughput,
and higher IOP quotas. So if you're evaluating this,
there's some dock on it. But pay attention
to the disk size. OK, so I'll pull
back up a level. Most to talk is
not at this level. But the whole
platform is like this. Everywhere you look, there's
all kinds of good things that are there to
make your life easier, as you're operating
these systems, and as you're running
your software. So there's that. And then, it's more than
just virtual machines. So this is kind of
an orchestration system for virtual computers. So one example-- actually,
somebody I talked to earlier was saying they want to run
containers on virtual machines. And you may have like a
one-to-one-- a lot of times, it's really convenient
just to run one container on and one machine. You don't really want a
big orchestration system. So you can actually do
that straight to the UI, and point it at an image. And we'll start a
managed OS, and just run your one container for you
if that's what you want to do. So that's an option. There's also groups
of all these machines. And this is where it
gets really powerful. One computer is only so big. But if you can
think of your system as a collection of
computing devices, the data center
is your computer. Then you can go
much, much further. And so we have something we call
managed instance groups, where you have a template for what
you want a machine to look like, either based off of
a snapshot of a disk, or a machine you've
pre-populated, or a script that sets them up. And then you say, OK, I'd
like to run five of these. And I'd like them all to be
behind the same load balancer. And you have a dial to
make more or less of those. Or you can hook up an
auto-scalar based on load, or CPU usage, memory,
that sort of thing. That instance group
can actually span multiple zones, multiple failure
zones, within the same region. So if you have a
system where you can have multiple workers
that are all collaborating on getting the work
done, you can very easily have a very high
reliability by having those in different failure zones. And then with using
that, we can actually-- when you make your base OS,
base image, or your software, you can actually roll them out
with this mechanism, as well, and roll them back. And then just to
kind of highlight, the load balancer is the data
center level load balancer. So we've got an article
online talking about this. But you can basically
go from zero to a million requests per
second with no pre-warming, no talking to somebody. You're configuring
the data center to do the load
balancing for you. That's all happening
off of your machines. So when you're thinking
in Compute Engine, when you're thinking in
VMs, this is logically virtual infrastructure. So you're thinking about your
software, the operating systems it runs on, the size and
shape of those machines, and what the networking
looks like between them, the configuration there. So this is, as a software
developer, as an IT person, this is what you
think about when you're working at this level
of abstraction, these pieces. Constraints-wise, if you need to
adapt very, very quickly, like in a few seconds
to a burst of load, that may be a little
bit challenging. So each machine starts very
quickly, about 30 seconds. But it does take 30 seconds to
get up to running your code. Now that's per machine. You can run
thousands of machines in a few minutes, no problem. So if you need to do a
big batch job, no problem. But if you need very,
very quick stuff, you may need to break
things up a little bit. And it is a whole
computer, so you'll have to decide how you
want to do your updates. It's an incredibly good
fit for existing systems. The abstractions
model very closely to what we're used to seeing,
both in our own data centers and in other virtual
environments. So you can usually
move very quickly from software you have running. I mentioned before, this
one-to-one container scenario. Sometimes, you've
got a container. You just want to run it. It's very convenient for that. If you need specific kernels,
licenses, other very particular criteria about your
operating environment, usually that'll push you
towards Compute Engine and virtual machines. And let's go from there. OK, it's demo time. Too much talking. And we will do live
demos, because scary. OK, so you may or
may not have seen it, but this is the web
console for Google Cloud. And this is the single most
important piece of that. This button is access
to all the other pieces. It might not have looked like
it, but this is important. OK, Computer Engine
is down here. And when you first
come down, you can see your virtual
machines, these instances groups that I mentioned. You can play with
disks, and snapshots, and all this other stuff. We're going to spend
just a couple of minutes looking at this. So we can make an instance. We can pick which part
of the world it's in-- data centers in
Asia, Europe, the US. We've got a whole lists of
things coming online this year, more in Europe, more in Asia,
Australia, and more places. So I can go ahead
and pick a location. I can pick a kind
of preset shape. But I can also kind
of drag and drop. OK, I'd like a machine
with more CPU than memory, or more memory than CPU. I can pick a particular
number for no good reason, and make this very
awkwardly-shaped machine. Maybe I'll name it
answer, and do that. We have a bunch of
maintained by us images that have software pre-installed
to do updates of the OS in the background, and connect
to the cloud a little bit easier, so that the security
tokens are available to you, and things like that. So these are all here. You can change the size
of the boot disk there. And then you just hit go. So this is now being
created off in Google Cloud. So we've said we
want this much space. We want it to be
running this disk. And this web UI uses
the HTTP REST API, the same API that the
command line tools use, and that you can also use from
your applications directly, if you like. So this usually takes
about 30 seconds. There it is. It's up. And we'll click my favorite
button, which is SSH. And since I'm already logged
in on the web with OAuth, Google Cloud knows who I am. We can do-- kind of
pre-populate some SSH keys, and SSH directly
from the web, you're on a Chromebook
or wherever else. I think I'm going to have to
push questions to the end. I apologize. And we're on a real computer. And there we go. So that's end of that
little quick whirlwind demo. But hopefully, that
gives you a feel of what Compute
Engine looks like, and how quickly it reacts. So why might you choose this? Consistency-- so this
is kind of actually true across Google Cloud. We are very concerned about
our systems working well all the time. And when you have distributed
systems, the one way you do that is getting your
long tail latency down low. And you want very
consistent performance. So if you do your load testing
with 10 computers on one day, and a week later,
you run them again, you should see almost
exactly the same performance. Choose the right
VM size you want. We can actually
resize disks that are attached to running machines. And then you can go in and
run the commands so your file system can actually see it. And I'll bet almost
everybody in the room has run out of disk before
on a critical machine. So that's super useful. On the billing end, we
try to make this really, really easy to think about. There's an entire
talk on billing that I'd like to point you at. But we're trying to
keep it really simple. Basically, if you use it more,
you get a bigger discount. That's the fundamentals there. So if you use a certain machine
shape for a whole month, you automatically get a
big chunk of discount-- 30% to 40%. If you have batch jobs, you
can use preemptable machines. And they are far,
far less money than the actual regular machines. Then they, actually,
are automatically shut down at 24 hours. And they could be shut
down at any point. That's what the
preemptable means. And then we bill per minute-- so a minimum of 10 minutes. And if you run it
for 12 minutes, you pay for 12 minutes
of that computer. So if you want to make
something faster, you can. And then I just want
to kind of highlight that this architecture is
what most of us are used to. It's a really good fit
for most existing systems. So that's Compute Engine. We have multiple talks today. Or you can check
these out online-- or and tomorrow
throughout the week. And you can check
these out online later. SQL Server on Compute Engine,
more Windows overall things, how to kind of scale really
big, and do updates and things with the managed
instance groups, saving money, which
is the billing talk, and more batch stuff. So check those out
for more details. And we'll move up one
layer of the stack. So now we're going to move
to Container Engine, which is hosted Kubernetes,
which for running containerized applications. So how many people here
are using containers now in some form? OK, big chunk, like, what,
75%, 80% of the room. And then I'm just going to
assume everyone's interested, because this is my talk. So containers are exciting
for a bunch of reasons. And to just highlight a
few things very quickly, you get isolation. You get repeatability. You can bring your same work
into different environments, and have it behave the same. As a developer, I think
of it like solving the, worked on my machine, problem. And that consistency
is really valuable. You end up wanting
to use a lot of them. And you want to use them
on a lot of machines. And that's where
Kubernetes comes in. And Kubernetes is an
open source project that was started by
Google, and very quickly, moved into the open. This has been built by a
community of people, including Google, and many, many other
companies and individuals. It is inspired by some
patterns that we know work on running lots of
containers at scale, but informed by that
community of people who are trying to use it in
places that aren't Google. Sometimes, have our
own look at things. So that just is a
fantastic place to be. It's already very mature. It can scale up to you,
I think, with the 1.6 they're hitting the SLAs
at 5,000 node clusters. You may have seen the Pokemon
Go news, that sort of thing. That's all on Kubernetes. And it really lets you think
about applications, not specific computers. And the mental model I
like to use for this is think about it as like
a white board, right? When you talk to
your colleagues, you're usually drawing lines
and boxes of how the system-- what pieces there are, how
they talk to each other, and what the data
flows look like. That's how you talk to
Kubernetes, as well. So when you
configure Kubernetes, you say, I want to
have 10 web front ends. And they should be named Foo. And I want to have these
five back end processors. And they should be able to
find the database at this name. And you can even
have kind of proxies for things that are outside of
your cluster that are named. And they can all find
each other the same way. So you basically, when you're
thinking about your systems in Kubernetes,
you're thinking about the logical infrastructure,
how the pieces connect to each other. And that is really powerful. So what are the programs? How are they connected? Where do they store
their information? Container Engine is
hosted Kubernetes. So there's two
parts to Kubernetes. You've got to have a cluster,
and have it up and running. And then you use the cluster. And Container Engine is
focused on just solving this problem for you
of keeping the cluster running, and updated, and happy,
changing its size as your load changes, that sort of thing. So there are a few
constraints here. It is a container first system. So you need to have your
software in containers. And there are some
architectural constraints. Like, it's designed for
most of the processes to come and go over time. There's some tools in new
releases for handling things that need very specific
state, that need to a disk available to them
wherever they move. But if you have an
existing system, you're probably going to
need to take a bit of time, and think about
your architecture, and how it maps with containers,
and this sort of thing. It's a really good
fit for systems that need to run in lots
of different environments. So you can think at
the logical level, and then deploy this using
the same configuration on different clouds,
on your own machines, in dev test prod environments,
all of these different things. And it gives you a
lot of portability of entire workloads,
whole systems. That's really powerful. It's designed for
containers up front. And I will say, it's a good fit. But this is also a
little bit constraint-y. You need to have
good communication across your organization
with your teams. Because these containers are
the kind of unit of deployment. This is the process, and
all of its configuration, that sort of thing. So your dev team, and your ops
team, and your security teams, they actually all need to be
able to make changes to these. And so hopefully, there's
a build environment. And hopefully, they
have good communication. So that's a place where
it's a good fit, which implies you probably want
a good build environment, some sort of
continuous integration, continuous deployment,
perhaps, that sort of thing. And it works with layer
3 networks and above, so you can host whatever
you want if the pieces talk to each other. So a quick demo on this note. So now we're in the Container
Engine portion of the web UI. And in here, I've actually
already created cluster, as you do on cooking
shows and demos. It takes about five minutes
to start of cluster, usually. And this cluster, there's a
bunch of settings and things we can poke around at. But one thing I
wanted to highlight is this is just using
a managed instance group from Compute Engine. And these are the
VMs under the covers. So Kubernetes is actually
hitting the same API as a Compute Engine
that you could hit if you want to do your
own orchestration stuff. And the auto scaling works
via that, and the like. So this is the open source
dashboard for Kubernetes. And we can see that
it's actually got-- the same nodes are listed there. I've gone ahead and created a
thing called a service, which is just basically
a load balancer for the cluster for
this particular app that I'm going to deploy. And it's called nginx. And it's on a public
IP address if anybody can type really quickly. But there's nothing there. It doesn't go, because
there's no software running. We can see that over here. So let's close that up. And there's a command line
tool called cube control that talks to its REST APIs. And we can run. There's a little
bit of shorthand if you just want
to run one image. So I'm going to use that. I'm going to call
it nginx, which is-- you may of may not have
heard of-- it's a very, very popular web server. And it's based on an image
that is called nginx. And this is a Docker image
curated by the nginx folks that we're pointing out here. OK, what did it do there? That was fast. Thw And it's already up. This is deployed. And if we come back over here
to services, click on this, we get the happy
default nginx screen. So that's kind of awesome. Just for fun-- so we have one
of these running right now. So there's a bunch of
things that happened here. And I'm going to refer you to an
introduction to Kubernetes talk to go through what
these concepts all are. But basically, I said, I
want to run this image. And it kind of patched
it up in the management abstractions that
Kubernetes uses. So it puts the
containers in a pod. And that's what gets scheduled. And then we have these replica
sets, which are the templates, and how many of the
pods should be running. And a deployment lets you
roll forward and backward among these things. So we have, by default,
just one of one. And so I can come back
over here, and I can say, can you control a
scale deployment nginx. And I want to have,
let's say, 12 replicas. And it says, OK, scaled, baby. And we come back over here. And 11 of 12 of
those are running. And refresh again, and
12 of 12 are running. And one of those are
running for a minute. The other ones are six seconds. So you can very quickly respond
to new needs in your system. And this is very, very high
level, but just kind of to get a feel of what it might
be like to use Kubernetes. And we have great talks. So today, right for lunch, from
Kelsey Hightower, I believe, is a nice introduction
to containers. Oh, no, sorry. That's the second one. So 2:40 is Kelsey's. There's an introduction
to Kubernetes at 1:00-- or whatever the times have
turned into after lunch. It might be that. Or it might be a little later. And so check these out,
either today in person, or online later. And now we move up one
layer to App Engine. And now we're
talking code first. The abstraction
that you use when you're talking to App Engine
is like, I have my source code. And the idea with App Engine,
the goal from the beginning, is let developers
focus on their code, and have the infrastructure
handle the rest. A Little bit snarky,
we'll say it's serverless before it was cool. But it started in 2008
with this trade off. If you write it this way,
then we'll scale it for you. And there were some
constraints about how you had to shape your
applications, what APIs you could use to get
that automatic scaling. We have a new flexible
runtime environment that is very much informed by
the modern container world. So it is Docker containers
under the covers. And therefore, you can
run any application that will run in a Docker container. It is still web-focused. So it's primarily
geared towards things that are HTTP requests
responses working through. We have run times that we
maintain for these languages listed here. But also, if you
can run something that listens to HTTP be
in a Docker container, you can deploy that in
whatever language you have, whatever tools
you use currently. Or something you've got set
up for another environment, you can use it here. So that's the high level thing. You, when you're working with
it, you think about code. You think about the kind
of HTTP requests responses. And then you might-- this isn't quite core. But you think about
like, which version is served in
production right now, and like, roll forward and
back, and that sort of thing. Constraints-wise,
the kind of standard run times that we've
had forever and we're going to keep working
with, we just updated Java, continuing there. But we have run times for
Python, Java, PHP, and Go. These are a very
constrained, fixed run times. So you can't add new
binaries to it, for example. In return, you get this very
fast performance out of it. The flexible run times, they
have whatever constraints are inherent in Docker. It's kind of like HTTP
focused in this context. And the way they're
implemented right today might not be the best fit
for really low traffic sites. We keep two VMs running
under the covers, so that there's always
something going there. So if you have
really low traffic, your end up paying for two VMs. And that's not perfect
in that scenario. There's work going on there. But where things stand
today, there's that. All of App Engine is a good
fit for apps that are primarily HTTP request response,
that are web-focused, that are developer heavy. You may scale to high traffic. You may seen the
snapshot kind of things. Santa Tracker from Google
is run an App Engine, whole bunch of stuff. I think we're doing 100 billion
App Engine requests per day. There's a lot of applications
running on App Engine. So what that might look
like in practice, I have another app deployed,
as you might guess. This is the flexible run times. It is an app to show
you pictures of fruit. This is a very highly demanded
application, so I had write it. We can see, at a high level,
you have these kind of services. So that's one portion
of your application. In this case, it's
the default version. So it's at root. And if I click on
this link, it'll take me to the
photo of the thing. And we have some lemons. And I can refresh
that over and over. And I will get lemons all day. And you know, maybe
we don't want lemons. I got some feedback that
maybe life and lemons is not the best thing. So we've deployed
some other versions. So we can go for cherry. And the other versions,
they're currently not serving any
traffic publicly. But we can still go for test,
or verification, or whatever. We can go to a sub-domain and
hit that version directly, and see that there. Oh, we get cherries
on this version. So we can do apples. Or probably, durian is
where we want to be, right? How many feel like durian? Oh, we got one. OK, maybe durian isn't the
most popular in this room. But we've gotten
requests for durian. And what we're going
to do is migrate all of the public traffic
to this version of the app. And then we come back over here. I'll click here to
make sure it's real. That version is actually
serving all of our traffic. So then we've had the
public moved over to that. If we needed to roll back, we
can just do the version back, as well. We can do more complex
traffic splitting. We can say we want
to give, actually, lemon most of the traffic. But we want to
actually give durian to 15% of the people who
come, something like that. So you can do that sort of
thing as well at a high level. And of course, you
get tons of stats. This app, as you
can imagine, isn't getting a whole lot of traffic. But you'll get nice stats
for how much traffic you're getting,
latency, all sorts of different metrics about
your application, full logs, and that sort of thing. So that's what that looks like. So why might you
choose App Engine? To focus on your code, and
have that scale, and go. It is very much geared
towards web workloads. If that's where you are, it's
going to be like a good fit. The new flexible run
times are very portable. So you can take these
Docker containers that are produced by this system
and run them other places. Or you can take container images
that you've preset elsewhere and run them in flex. It is a fully
managed environment. But it is also running on
the same infrastructure. So from the flexible
environments, you can actually, what we
call, kind of break glass. You can go in SSH
into the machine, and use your regular
debugging tools to investigate some
situation that's come up. And then you just remove
that VM from rotation. And it makes a new one. And things are back the
way they were before you started poking around. But you've been
able to investigate using the tools you're
familiar with and know well, and a hundred billion
requests a day. So a lot more talks
on this today, including .NET running .NET
containers on Google Cloud. Scaling things, a talking
geared towards the Ruby world, and how this works really,
really well on Flex. If you were coming from
Python or other languages, actually, that talk will
also be pretty relevant, how the budgeting works,
and that sort of thing. And the demo that
I barely skimmed the top of, if you want
to see more about that, the talk list at the
bottom, I swiped that demo from Justin Beckwith. So you could see the
full version there. And he'll go into more detail. OK, up one more level in
the stack, cloud functions. So this is just-- if you could imagine just
having a function in the cloud that does work for you. There's so many different
APIs on the internet. Most of them are
available over HTTP. And we start needing to glue
them together, and figure out how to connect them, and either
augment our existing systems, or in some cases,
actually build systems out of connecting
the pieces together. And I'm particularly
excited here. Because I think this can
allow people to kind of go a step beyond what we
normally think about as our current
primary developer IT ops audience, people
inside of organizations, automating things, gluing
things together, doing data transformations, and
things like that. It is primarily event driven,
so either like an HTTP request comes in, or a new object
is added to a Cloud Storage bucket, and a
notification happens. Or we have this thing
called Cloud Pub/Sub, which is a message
bus-like thing in cloud. Did you know we
have this thing that is both high throughput
and durable for all of your messages? Check it out. It's awesome. And for my biases to
show, basically, I think Pub/Sub and
Cloud Storage are APIs that nearly every
op should investigate. Check them out. It is very much serverless. I put it in quotes
because there's computers down underneath. But from your perspective,
you have a function. You write the code. You push that up. And it gets run. Pay only for what you use. The run time is
currently Node.js. So you can take
these same functions and run them in other
environments, as well. So if you want to run
the same implementation, you can run it on
your own Machine. You could run other places. So as the user of these--
usually the developer-- you think about events,
and you think about, so what happens in
the system, and then what you want to do to transform
that, what your function does. And that's almost it. Constraints, today it's
JavaScript on node. So that's the language we get. You are thinking about
things at the function level. So I think of this
more in terms of like, as your system gets
larger and larger, there are some cognitive
overlap-- you know, [INAUDIBLE] to kind of think about. And the system must
work through events. It is almost pure
surrealist promise. You just take this function. And we run it for you. And they scale incredibly high. We've got people doing IOT
workload handling, where they have devices in
hundreds of thousands of different locations
all pushing their data up. And the same function
definitions scales up and down, depending upon the load there. If you are using
Pub/Sub and Storage, it's a really, really good fit. If you've got some kind of
somewhat lightweight ETL data transformations, if
you've got some JSON that comes in some
format, and you tweak it a bit for some other
system, super good fit. Or just in general, I
like to think it like, it's the glue for all of
these Cloud HTTP Functions. So is internet
duct tape or glue. Put all the things together. Demo here is more of
kind of like a tour. This is the Cloud Functions
portion of the web UI. Just to kind of pick on
HelloWorld, as one might do, we again, get a bunch
of stats, information about how this thing's working. The trigger for this
is an HTTP endpoint. So you can do a get or
post request against this. If I do that, I
get some text back. No message to find. Where did that come from? We can also see the source code. This is a very,
very simple function that is looking for
JSON Dock to come in, and to see if it has a message
key, and then do something. If that doesn't happen, we get
the message that we just saw. So let's try to do
something closer to what the function expects. So I'll go ahead
and paste that in. Do that. And we test the function. And we get, basically,
log output, in this case. But it gives you a sense
of both how quickly the functions execute, a
little bit of play environment. And you can connect almost
anything together this way. And this environment
will also let you see the actual console log output. So you can see what came out
of your logging as you go-- so just a quick
feel of Functions. So with Functions,
you don't even have to think about
servers at all. You purely have the
event that comes in, what you do with it, move on. You pay only for what you use. Don't need to think about
the big architecture pieces. And it is very
straightforward for developers to reason about in the local. You just have your inputs. And then you have some
side effects, some outputs. And you go. As everbody knows, once
you have a lot of those, there's complexities. But the model, while you're
working on Functions, is very, very clean. To learn more about
this, we have a talk specifically on
serverless architectures, and how to think about them,
and where they run well. It's mostly around Functions. Later today-- or two of them,
actually-- today and tomorrow. The second one is
actually where I-- head this way. And actually, that's
not the demo there. So anyway, apologies. And now we get to this kind of-- so we've done the run through. Did we find a good
fit for folks as we were walking through this? I think, for some folks here,
one or two of those things jumped out as, OK, that's the
thing I should look into next. For other folks,
it's not so clear. I'm still kind of confused. Or maybe I want to use multiple. And it does depend. So here's a few more directions
to think about this from. So the abstraction level is kind
of the structure of the talk. We're looking at different
ways to think about an offer rate on your code. Also, there are just sort
of technical requirements. So you might need certain
network protocols. You might need
certain other things. That might change your
decision, and just push you directly into one
answer, or a subset of answers. And there's also,
what is your team, and what does your
organization like? If your entire team
is very proficient in a particular programming
language, if your company has made some decisions about where
they want to focus languages, or what's the future of
technology the company, that also may affect where
you decide to go for these. Because many use cases could
work in one or two of these. So on abstractions, just
kind of collecting things from throughout the talk,
for Cloud Functions, you're thinking about
mostly events and functions. App Engine is your code
and the HTTP interactions. This is actually kind of the
summary that talk, I guess. So we'll just pause
here for a moment. All the phones come out. And Container Engine
is about applications, whole applications, and the
logical architecture of how the pieces connect
to each other, and being able to run those
in multiple environments. And Compute Engine is
your virtualized hardware. You think about the actual
machines you've got there. So that's abstraction. Technical-wise, I
think what tends to happen is tech constraints
will kind of pull you further down the layer of abstractions. And a couple of examples
to talk about this. So Cloud Functions has
particular languages it works with right
now, particularly, in what kind of shape of things. If you need more
than that, you're going to be in App Engine
or that space for sure. Depending upon what language,
whether or not you're kind of web facing,
you might actually come down a layer beyond that. If you need to have hybrid
portability, if you're doing protocols beyond kind
of standard web protocols, you're going to be in leasing
container, Compute Engine kind of space. And then if you need like
a very specific kernel, you're running Windows today,
you need certain software licensing things, you want to
own all of the orchestration yourself, you might be
down in Compute Engine. So the technical
situation that you're in with the problems
you're trying to solve may kind of push you in
one place or another. And then your team-- at a very high level, the
higher level abstractions are a little bit
more dev focused. And as you go down, they tend
to be a bit more ops focused. Obviously there's
a lot of overlap between that generalization. But if you have a team that's
entirely made up of developers, you're going to be happier at
higher levels of abstraction. And if you have very
specific operations needs, those particular
chosen paths might not be the best fit for your app. And then, I think I kind of hint
at this in the Container Engine thing, but where is the future
of your organization going? If you know you're
all in on containers, that might also push you
towards Container Engine, Kubernetes kind of world. So keep that in mind. What are your people like? Where is your
organization going? And then, again, just
to come back on-- this is actually low risk. So we spent this whole
time, like half an hour, talking about, here's
how to make the decision. But it's actually a
fairly low risk decision. And I'll try to
convince you of that. So one, containers
are really giving us a lot of flexibility here. So as an example, if you
start in App Engine Flex, as a side effect of its normal
operation, when you give it the code, it produces
a Docker image. You can take that
same Docker image, and you can run that in
different environments. So you can run
that on Kubernetes. And you can run that same
image on Compute Engine. You can even run it outside
Google Cloud, other places, depending on how many APIs
you're using and the like. There might be some
latency effects there. But you can run these same
containers kind of anywhere. So if you start at a high
level of abstraction, it's very easy to kind of
like bump down a level, or move down another level. So that's cool. If you have an
existing system, it does take more work to move
up a layer of abstraction. You're going to spend some time
investing, doing some learning, that sort of thing. But you can definitely do that. So this isn't a final decision
on where things actually run at all. And most systems
in the real world run their code in
multiple places. They might be mostly
Compute Engine based with a dash of Functions,
or primarily Function-based, but there is some extra
work that they need to do in another environment. You might be all
in on containers, but yeah, there
is that one system that nobody knows anymore. We're just going to
run that in the VM. Or whatever the
situation is, it's very likely that
you're going to have a mix of different
pieces over time. And that's normal,
and probably healthy. If you think about, at a
really kind of high level, even if they're not
quite microservices, but you have different
pieces of your application, you're going to run them where
they're the best fit for. And so it's very common to see
an API endpoint being an App Engine, where some
data processing might live somewhere else. So that's the TL;DR. And
we'll circle back around. The take home, for your
colleagues and other folks, is if you are primarily
thinking about events, kind of internet glue, HTTP duct
tape, think Cloud Functions. If you primarily have code
that is meant to be web-facing think App Engine. If you are primarily thinking
containerized applications, think Kubernetes and
Container Engine. And for everything else,
for existing systems, start with Compute Engine. And think about where the
right fits are for there. [MUSIC PLAYING]
