Cloud Functions Overview: Get Started Building Serverless Applications (Cloud Next ’18)


BRET MCGOWEN: All right. Hello everyone, welcome. My name is Bret McGowen. I’m a developer
advocate at Google. We’re focusing on
all things serverless as part of the Google
Cloud Platform. You can follow me on
Twitter at @BretMcG. So today, we’re going to talk
about Google Cloud Functions. And this is designed to be
kind of a gentle introduction. So we’re going to assume
maybe you don’t know anything about what the word serverless
is or what cloud functions are. We’ll take you
from the background into some concrete what are
the actual commands, what are the APIs, to actually
writing your own cloud functions. So before we get into
what is Cloud Functions, let’s take a step back and
let’s answer the question, what is serverless? So this is my opinion. This is my definition
that I like to use. So invisible
infrastructure– you write code that
runs in the cloud. But you don’t necessarily know
what machines it’s running on. You don’t necessarily
know what– you’re not managing,
updating the operating system or installing security
patches on the base OS or trying to figure out
networking, and load balancing, and attaching disks. And there’s all
kinds of stuff that goes along with running
your code that serverless takes care of. We’ll look at that a little bit
more concretely in a second. Automatic scaling– so as
traffic comes into your app and it gets higher and higher,
we’ll scale up for you. And on the flip
side, we scale down. And in fact, we’ll
scale down to zero, which means you only pay while
your code is actually running, while it’s actually
doing something. So if it runs for
three seconds a day, you pay for three
seconds of run time. And this is different than maybe
traditional cloud computing, where you’ve got some virtual
machine that’s just running 24/7 waiting to do something,
runs for three seconds a day, but you’ve paid for maybe
the whole day, unless you’re manually spinning it
up and spinning down. So that’s kind of the
definition of serverless. And let’s look at this a
little bit more concretely. So say I have an app, we’re
going to call it Emojinizer. And the idea behind
the Emojinzer– let’s say it’s a mobile app,
runs on my Android phone. It takes a picture, maybe
some hilarious picture with your friends
in your elevator. And it’s going to go through. It’s going analyze the sentiment
of everyone’s face in the photo and replace it with
the appropriate emoji. In this case, we’re all
happy, but maybe we’re surprised or sad. And it would put the
appropriate emoji, right? This is my brilliant
idea for an app. Actually, it’s real. If you want to text
a selfie to 312– I’ll leave this number up
for a second, 312-313-4664– this actually will work. But your photos may show up
later in the presentation. Be warned. But it would be awesome
if you texted something so we don’t have a blank screen. But anyway, so we’ve
got this mobile app. Things are going good. But we decide at some
point, OK, maybe I don’t want all of this logic
to live in my mobile device, on my actual device. I want to extract it
and put it into an API. And this seems like a good
idea for a few reasons. One, if I want to have my
app run on other devices– so maybe a web app
or an iOS app– maybe I want to expose it
as an API to third parties, it makes a lot of sense
to put it in the cloud. I don’t have to redevelop
this business logic every time I have a new app. And conversely, if I want to do
things like different effects, I don’t have to have a new
update roll out to my app. Or if I want to do some really
heavy processing that maybe wouldn’t make sense
to run on device, it makes sense to
do it in the cloud. So this is a fairly
typical journey from, say, mobile
app to something that runs in the cloud. But there’s this little thing
floating in the middle, API. I want to dig inside. Because it looks nice and
tidy as a little cloud icon in an architecture diagram. But what’s actually
going on inside? So this might be one way
you would create your API. I would create a
virtual machine. Maybe it’s running
Nginx as a web server. Maybe it’s a Node.js app. And it just sits on this VM. Everything’s hunky
dory, well, kind of. Because already, there’s
a bunch of things we now have to worry about
besides my app, right? Again, I had this dream. It was this cool Emojinizer app. That’s what I want to
spend my time working on. What I don’t want to
have to worry about is, what if this VM goes down? Am I getting paged? How do I restart it? Do I need to get to a computer? Do I have an IT person
that I need to call? What if there’s a
new version of an OS? Should I update it? What does that look like? Do I have to take my app down? What if there’s a
networking blip? What if traffic
overwhelms this one VM? There’s a lot of things
already just out of the box, as soon as we go into
the cloud, that we have to start worrying about. When, again, all I
care about, my business value that I’m contributing,
is this cool Emojinizer app, whatever your particular app is. And the problem compounds
as we come in scale, so if we grow beyond
the bounds of one VM or we just want to have more
than one machine around in case one goes down, our whole
app doesn’t go down. So we start to scale up. So for each one of these,
we have the same problems we just had with one. But we have compounding issues. One, we now have to manage
versions of the operating system all the dependent
libraries, all the security patches, make sure
everything is good. And we need to manage
versions of our application and make sure nothing
gets out of sync. Because you don’t want to
have every once in awhile a request has some
weird response and it takes you
forever to figure out like, oh, our
script that updates the app missed this
particular one. And there are tools around. There are things like Chef,
and Puppet, and so on that help you coordinate all of this. But it’s still
something you have to manage, you have
to be aware of, you have to have some
process around it. And then things
might get even worse. Because say get a
lot of traffic and we have a lot of variability
in the traffic, so we don’t want
to necessarily have 500 VMs running all the time
to handle peak capacity. Because maybe overnight, no
one’s really using our app. So we either can configure
those to scale up and down independently, or
maybe we’re going to set some cap so
we don’t go broke, like paying for
our peak workload. So maybe we have to have
things like a queue that sits in front of us and absorbs
all the requests so that, as you spin up more
virtual machines to handle a spike in load, those
requests don’t get dropped, so some queue that holds them. And once your VMs have capacity,
then it hands off that job. So again, there’s already a
lot of stuff we have to manage. And all we care about
is making hilarious cartoon faces in our example. So the idea behind serverless
is putting your focus on what your users
will experience and what your business value is. What are you doing
fundamentally that’s important? Keep the important
things important. And probably, load balancing
and scaling virtual machines is not what’s super
important to your app. So I won’t say that
we are entirely here, where all you have to
care about is code. But that’s the goal and that’s
the dream of serverless. So I think we can get
on board with that. It makes sense. But there’s a lot
of ways to do that. So why functions specifically
and not applications? Why am I not scaling
up my whole web app? Maybe I have my Python Flask
app or my Node.js Express app. Why don’t I just scale
that up and down? So let’s dig in a little bit
to the back story of how we got to functions as a service. So there’s this
shrinking scaling point. So back in the day, we had
these physical machines, these actual servers that
lived in a data center, maybe co-located, maybe it
was under your desk like it was at a
couple of my startups. But you have some issues. So people installing
different applications on the same physical
machine, they start to step on each other. So I have some version
of a graphics library that this service uses,
and another service on the same machine has
a different version, and they start to conflict. So then we said, OK, lets
move to virtual machines where we can isolate that. So I can pretend like I
have my entire own server, install all versions of
whatever I want, and it’s fine. But there’s kind of an
issue there in that, do you really need a whole
different operating system with a whole different kernel? That’s really heavy isolation. So maybe there’s a
better way to do that. And that’s where
containers came. So you can run a
lot of containers more efficiently on
the same hardware. And these can kind of act
like the virtual machine and they have that dependency. But you still manage containers. You have to schedule them. You have to define them. You have to declare them. So then we start to move into
serverless territory, which is just focused around code,
the actual code that is running. And we want to have everything
else abstracted away from us. That’s kind of how we arrived
at functions as an abstraction. And that helps in a few ways. I put microservices
with a question mark. Because I don’t really
want to have a debate what is or isn’t microservice. But I get buzzword bingo
points if I say microservices in my talk, so there you go. But the idea is, just briefly– so if I have my
traditional app– this is my e-commerce app–
and it’s got these components, right? It’s got a shopping cart
component, and a pricing component, and an
authentication component. And they all live in
the same application. Everything’s great. But again, as you
scale, you might have some pieces of your app
that you want to abstract out. And there’s a couple of reasons
you might want to do that– or extract out, I should say. One is maybe it
scales differently. Maybe your pricing service
gets hit all the time. Because for every item someone
looks at in the shopping cart or on your catalog, it’s
calling the pricing service. Whereas, maybe your tax
calculating service only happens when the user checks
out or very rarely changes. So it lets you scale different
parts of your application independently when you extract
them into their own piece. It lets different teams
work on different pieces. Teams can release more often. So maybe your pricing service
wants to release 30 times a day because they’re
testing out new models and they want to do
live pricing based on historical purchases,
whatever your use case might be. Maybe you want to
release more often. Whereas, your auth service
or your credit card payment service, it works. Let’s leave that alone. I don’t want to accidentally
redeploy my payment service every time I do some change over
here in pricing or in catalog. Does that makes sense? So you can scale differently. Different teams can work on it. They can use different
tech stacks, for example. So there’s a lot of benefits
to extracting these pieces. So that brings us back
to Cloud Functions. So it’s the marriage
of serverless, which is all the underlying
management, with the appeal of microservices, where you have
these individual components. Because one of the pain
points of a microservice is you now have to manage
all of the infrastructure, and the deployment,
and the scaling, and the load balancing of
each individual service. And that’s a lot of headaches. So with serverless,
when that’s abstracted, it makes a lot more sense. And it’s a bigger benefit to
having these microservices. So Cloud Functions in
a nutshell is this code that runs in a cloud that is
triggered whenever some event happens in the cloud. And we’ll look at what
the specific events are. But that’s sort of the premise. These are designed to be fairly
narrow-focused bits of code that run in specific instances. A couple of types of
cloud functions– so HTTP, which is probably the most
common, is just what it sounds. So you can make an HTTP request
from a browser, from an API. So you could build
your REST JSON API on top of Cloud Functions. It also has nice
integration via HTTP with things like the
Google Assistant. So if you want to build
a custom app for Actions on Google when
you have your own, there’s a Google Assistant app. There’s actually integration
with Cloud Functions through the Google Assistant
Google Actions on Google UI. But you can also use these as
callbacks to things like Stripe or Twilio for
texting that you say, I want some third party to
handle some service for me. And when you’re
done, here’s my URL. And let me know
when you’re finished and give me some metadata. So Cloud Functions is a
really nice way to do that. So there’s HTTP functions. And then there’s what we
call a background function. So these are things that
happen to events in the cloud that maybe there’s no direct
person requesting them, if that makes sense. So it’s not an explicit
call like an HTTP call. It’s some event happens,
your Cloud Function triggers and takes some
action based on that. So Cloud Storage will
trigger it, Pub/Sub, and there’s a bunch of
Firebase events, which we’ll look at a little bit
more in detail in a second. So to how Cloud Functions
helps you glue these pieces together– so here we’ve
got all these events– again, Storage, Pub/Sub, HTTP,
Firebase, and Cloud Scheduler, which is new as of yesterday. So this lets you schedule
your Cloud Functions on a timer essentially. And I guess actually
behind the scenes, Cloud Scheduler still
uses HTTP or Pub/Sub. So those are still
fundamentally triggering your functions the same way. But you can say, hey,
run this every minute, or every 30 minutes,
or twice a day, or whatever your
schedule might be. You can actually have
that fully managed in the cloud with
Cloud Scheduler. I have been asked about this
a million, million times over the past couple of years. So I’m really excited
that we finally have Cloud Scheduler available. I believe it is still in alpha. So stay tuned until you can
actually get your hands on it. But it’s coming. It’s here. And once your Cloud
Function runs, it’s automatically
authenticated by default to other Google
services, so things like the Google Translation
API or, say, Firebase or Cloud Storage. You don’t have to manage
service accounts or API keys and lug all of this
authentication with you. It’s already authenticated
in the context of your Google Cloud Services account. So it can reach out to
these really, really easily. So what is the environment? So right now, so we went into GA
yesterday, which is fantastic. And the GA environment,
which is on the left, is our Node 6 environment. It’s running Debian “jessie.” It has ImageMagick
pre-installed. You can write to disk at /tmp. And it has auto
authentication, as I mentioned. But we also have
now, thankfully– I’m super excited. I’m a Node guy. So we went Node. We added Node.js 8 as an
additional environment as well as Python 3.7. So I’m really, really excited. I do get asked a lot
about other languages. So we’re excited to have these
in beta with more to come. All right, let’s take a
specific HTTP function. And then I’ll actually
show one in action. So here’s what it looks like. And if you’ve done web
development before or written in HTTP REST API, this
should be pretty familiar. So we’ve got two objects here. We’ve got a request object,
which has all the data coming in from the user. So this could be something like
an HTTP post with a JSON body. And then we’ve got
a response object. So this is what goes
back to the user. So you can give them things
like a 500 error code, or some kind of message, or
hopefully a success message. But by default, it has
all these other things. So it creates an HTTPS endpoint
for you, takes care of SSL, gives you a fully qualified
domain with just these three lines of code, no
additional configuration, no additional
routing, or mapping, or having to manage
any of that for you. It is created automatically. And it automatically parses
incoming request objects. So if there’s something
in the query string, it’ll put it into request.query. If there’s something
in the body, it’ll put it into request.body. So let’s actually take a look. If we could switch over
to the demo machine, I will attempt to
write a cloud function right before your very eyes. So here I have a brand
new file, index.js. So just so that I show there’s
a little bit of something behind the curtains here, I
have in my package.json, which is how you manage
dependencies in Node.js, I have included the
Google Translation API so that I can do
some translations, a bit of a sneak peek
into what’s going on. So here’s the bones of it. So this is importing
the Translation API. And again, normally,
you can, if you want, put a specific service account
or credentials as part of this. But by default, it’s
auto-authenticated, so again, really, really easy. And I don’t do a “Hello
World,” because I’m from Texas. So I do “Howdy World.” So howdy. How can you tell if
someone’s from Texas? They always tell you. Exactly. I’m surprised I made it 10
minutes before mentioning it. So we’re going to do a
couple of things here. I’m going to look
at the query string. And if there’s an msg, if
there’s a message property, I’ll use it. If not, I’ll default
to “Hello World.” I’m going to look
at the language and, if they provide it, use it. And if not, then
I’ll use Spanish. Then we’re going to
call the Translation API into that particular message. And if there’s an error,
which I begrudgingly added because I choose to think
that it always works perfectly every time, I’ll log
that out as an error, and if not return a
status code of 200. So let’s go ahead
and deploy this. So gcloud functions deploy– name of my function– trigger-HTTP. And assuming the
Wi-Fi co-operates– come on, buddy. All right, it probably
won’t take two minutes. But just again to
reiterate what’s happening, I have no configuration. I literally have two files. I have an index.js
and a package.json, so again, the code-first
approach, where all I have is what is useful
and interesting to me and, again, no
routing, or mapping, or worrying about SSL certs. So here is my output. This is just a link
to the source code if I want to download it back. But here we go. I’ve got my URL. Let me copy this. Howdy World. Let me go over to my browser. And I’m going to say,
message equals “Hello my dear friends
in San Francisco.” And then the language
will be, sure, Spanish. And so just like that,
it translates to Spanish. And all I have to do is
change this parameter. So let’s translate to Japanese. And does anyone speak Japanese? Is that remotely correct? What about– anyone
speak French? Come on, come on Wi-Fi. There we go. I see the words “San
Francisco” and “Bonjour.” So that’s probably close enough. All right, oh, I heard correct. So that’s good. So if we could go
back to the slides, so that was how
easy it is to get started writing
your cloud function. Again, it’s just the code
that you’re worried about. It created the SSL cert,
the endpoint, and all that automatically for me. So that was HTTP. Those are explicit
functions that you request. And now, let’s talk a little
bit about background functions. So these are things
that happen when an event occurs in the cloud. So as an example, here’s
a Cloud Storage event. So this is a file that gets
uploaded to Cloud Storage. And there’s a couple of
events we can look for– finalize, which is when a
file is finished writing; delete, which is when
a file is deleted; archive; and then
metadata updates. So in Cloud Storage,
you can have metadata associated with your file. So you can watch
any of these events and take some particular action. So if a user uploads a
file, a CSV for example, your code will
automatically run. You could churn to the data,
and then write it to a database, or do whatever interesting
thing you’d like to do. And here’s the syntax if you
want to see how to do it. This analyze image we’ll
actually take and look at a concrete example of that. So I love raccoons. It’s a long story. I probably follow more raccoons
on Instagram than human beings. But it’s all right. They’re adorable. So let’s say I take a picture
of this adorable raccoon and upload it to Cloud Storage. It’s going to automatically
trigger a Cloud Function based on that image on, say, the
finalize event that we just saw. Then I’ll have my
Cloud Function. It’s automatically
authenticated again. So it will call to the Vision
API to do some analysis. And it will say that it is 99%
a raccoon and 100% adorable. Oh, I think that one is missing. But it should be there. And so this is fine. This is cool, event driven. But where Cloud Functions
is maybe different is if you wanted to have
some other action also taken on that file. You might normally have one
function that listens to it and then does two things. So it calls the Vision
API, does some analysis, and then maybe also
creates some thumbnails– so a big one for your
desktop app, a thumbnail for thumbnail purposes, a
small one for phone, whatever. But here you can actually
have two functions completely independent. Whoever’s in charge
of the thumbnailing doesn’t need to know
anything about what’s happening in the Vision
Analysis side, right? So it lets you split these
out and actually run them in parallel. And you can imagine
you might have like four, five, six
different functions that run at the same time triggered
by the same event, all managed and deployed independently. So it keeps your
code nice, and tight, and focused around
one particular case. Do you want to know what the
code looks code looks like? So here’s my analyze
image function. It has one parameter
here, which is event. And event has a
couple of properties. It has data and it has context. So context is, what
kind of event is this? So in this case, it would
be a Cloud Storage event. And what time did it happen? What’s the time stamp? And then data is specific data
about this event of that kind, if that makes sense. So this would have things like–
since it’s a storage event, it would have data
like file name. If it was a metadata, it
has the metadata associated, if it was associated
with the file, if it was a metadata event. And then here, I’m just
going to call the Vision API, churn through the labels, and
then write out the results. A quick note– and I will
probably bring it up again. But before I forget, this
isn’t the current environment. This is what the event.data
and event.context look like currently. That is changing slightly, the
function signature, with Node 8 and in Python. So you will actually
have two parameters here. We’re just splitting out. Instead of event.data
and event.context, it’s just going to
be two parameters. So there’ll be data and context. Does that makes sense? So if you’re using Node
6, this doesn’t change. And it will continue
to operate this way. But going forward in
Python and in Node 8, that function signature
is changing just slightly. But we just didn’t want to break
everyone who’s using Node 6. All right, so if we can
switch over to the demo, let’s see this back in action. Whoops, where is my– boom. All right, so here is
my Cloud Storage Bucket. It is empty. So I’m going to do basically
that exact raccoon thing where I’m going to upload a photo
and have it make a thumbnail and do some analysis. And what better way than to
take an awkward selfie on stage? 3, 2, 1. Yes, I cannot wait to
see what that says. Awkward is probably going
to be one of the labels. Well, you can see
what size it is. Come on. So all right, yes, apparently,
I’m having problems dragging. All right, so that will upload. And you can see this is
now in the In Bucket. And this is automatically
going to trigger those two functions– one to do
Vision Analysis, and then one to create a thumbnail. So that’s Resize Demo In. Let’s go to Resize Demo Out. And we should see– some leftover files
from my testing– and if we have Thumb,
should be a tiny version of that, sure, and the labels. Zoom in a little
bit, and let’s see– thumb, fun, finger–
there we go– selfie. There we go. That’s exactly what it is. Every once in a while,
it says man, which is very reassuring to me– or human– that I am, in
fact, an alive person. So if we can go
back to the slides, all right, so that
was a storage trigger. And then I’m not
going to do a demo, but I’ll briefly
talk about Firebase. And if you don’t
know Firebase, it is a cross-platform suite of
tools across iOS, Android, web. There is a C++ SDK if you’re
doing embedded devices. There’s a Unity plugin
if you’re doing games. Super, super cool, it has
a ton of different things you can do with it, everything
from virtual Android devices in the cloud to test
your Android apps to providing a fully managed
serverless notification system, so actually doing push
notifications to your apps or to your web apps. You can do things
like Remote Config, like change how your
app is configured on the fly in the cloud. It’s killer feature
is the databases. So there’s a Firebase
Realtime database. And then you probably
may have also heard of Firestore which is a
super powerful, highly scalable, NoSQL database. That’s killer feature, at least
from the Firebase perspective, is Realtime syncing. So the idea is you write
to the Firestore database, and you have a whole bunch
of clients connected, and they’re all
listening for updates. And Firebase takes care of
notifying them automatically without you having to
write any WebSocket code or long pulling code. It’s fully managed,
super, super cool. And there are specific
triggers from Firebase events into Cloud Functions. So we’ve got database events– so an insert, a delete,
an update, and so forth on a database. So that’s really powerful. People do everything
from data validation to make sure the data
that gets inserted looks good, conforms to some spec,
things like replicating data to another database. So Firestore and the
Realtime Database are NoSQL, which is great
for running your app but can often make
reporting difficult. So what people will do is
they will have listeners on their Firebase database. And when data gets
inserted or changed, then they’ll just replicate
that data in a Cloud Function off to the reporting database,
so something like a BigQuery or if you have some
sort of SQL server that you can just
push your data. And your app isn’t maybe
running on that server, but you want to use it
for a reporting database. There are other events
like authentication. So when a new user
signs up for your app, you can get some Cloud
Function that runs, maybe send them a welcome email,
do whatever sort of action you want to take. If you know Google
Analytics for web, you know you can track users as
they go through your website, and what are the
popular pages, and what are the routes that they take. So there’s Google
Analytics for Firebase, which is a similar suite of
tools but for your mobile apps, for your iOS apps and
your Android apps. And it’s cool because
you can actually have Cloud Functions run in
response to those events. So if you have some part of
your app that you want to track, some survey that
you want to take, and when they
complete the survey, you can say, oh, whenever
they complete the survey and this analytics event
gets triggered, run my Cloud Function, which is pretty cool. Because you just
wire it up and you don’t have to actually make
some call inside the app to run some Cloud Function
in the cloud to do whatever you want. You just say, hey, run this
Cloud Function automatically tied to your analytics event. Firebase hosting– so if
you have a custom website on Firebase, which is
cool– it has a whole CDN– you can say, if a
request comes in that looks like this is kind of
URL, map it to this function. If it looks like this URL,
map it to this function. And it actually lets you do some
really interesting things as far as building web apps
or single-page apps. Crashlytics– sort of what
it sounds like, if your event or if your app, heaven
forbid, crashes, you can have a Cloud
Function automatically run and do whatever you want
with that reporting data. How do you deploy
Cloud Functions? I used the GCloud
Functions command earlier. So you can do it from
the command line. There’s an API. So if you have maybe
part of some CI/CD system or you want to
actually integrate and automatically do
deploys of these functions, you can do that. If you want to edit
code in the browser because you are a monster,
that is an option as well. No, I’m just kidding. It’s fine. But I prefer on my machine with
an editor and all that stuff. Anyway, but it’s cool with
the syntax highlighting and it does make it really
nice, especially if you need to do quick tweaks, right? You can just open it in the
editor and make changes. But part of why I
like to do it locally is because we have
a local emulator. Right now, it’s only
for Node 6, which is, again, our GA environment. But it’s nice because
you can plug it in, and set breakpoints,
and run locally, and step through your code. It’s one of the
things that’s often a challenge when you
are developing code that runs in the cloud is you’ll
do a deploy, actually test it– OK, it fails– do a deploy,
that takes a few seconds, wait for it, test it. So it’s really nice. And it builds a much
faster development loop if you can do that all locally,
emulate the functions locally and actually use a
real IDE with attaching a debugger and all that. Where are we seeing people
use Cloud Functions? A whole wide variety. So Webhooks I kind
of talked about, if you want to do callbacks from
things like Stripe credit card payments and so forth. If you want to
create your own API, you saw how easy it was to
create an HTTP endpoint. Literally, I just said,
deploy it as an HTTP trigger and all of that
is taken care of. If you’re doing lightweight
data transformation– so if you’re doing really
serious data transformation, we have other products,
things like Dataflow. But if you’re just
doing casual things like I want to transform this
CSV file a little bit or– I mean, I guess you could even
call that image processing– make some call, take the
result, put it in a database, Cloud Functions is a really,
really easy way to do that. IoT– so this is integrated with
our Cloud IoT Core Platform. So if you’re streaming hundreds,
or dozens, or thousands, or millions of messages,
those get pushed to Pub/Sub. And you can have
a Cloud Function run every time one of
those things come in and take some action. And then I always forget–
because I’m an application builder, and I want to know
how serverless can help me, and Cloud Functions
can help me build apps. But if you actually are
managing infrastructure– so you have servers and
VMs for whatever reason, maybe that’s how your app
runs already in the cloud, you can actually have
Cloud Functions watch your infrastructure logs,
your Stackdriver logs. And you can say, oh, shoot,
I see some VM shutdown event. That VM should not
have shut down. I want to take some action
and notify someone, or maybe automatically start
it back up, so forth. So you can actually monitor
your infrastructure– monitor your servers using serverless. Just some customer
examples, I won’t get into necessarily
specifics, who are using it for
things like building their whole app backend
on Cloud Functions, doing real time data processing,
building intelligent apps. So again, I talked
about Google Assistant. But people are using it
for all kinds of chat bots, and Slack bots, and
things like that. Smart Parking, super
interesting customer that I’ve worked pretty
closely with– they’re based out of New Zealand. I got to see their operation. They have really
cool IoT sensors, so things that are really
serious use cases where, if I have these IoT
sensors out in the field and they’re reporting
temperature, humidity, and every once in awhile, one of
those temperature measurements gets dropped, like
no big deal, right? But when you talk about law
enforcement, and parking, and literally a police officer
gets involved and is writing someone a ticket,
you better be damn sure that that is the
same car that was there a few minutes ago, right? This has to be really resilient
under some pretty difficult circumstances. We’re talking about sensors that
are in the ground for years. And you’ve got huge, 1,000-pound
vehicles driving over them and sitting over them. And so if you’re
interested in that, you can check out Smart Parking. We did a whole blog
series with them diving into their architecture. And I think it’s interesting as
well because they’re doing all of their stuff in the cloud. But again, it’s IoT. So a lot of it lives
in the physical world. So as we get to the
end, it’s kind of easy to do a “Hello World” or an
“Hola World” or a “Howdy World” depending on how
you want to call it. But how do you build some
more complicated apps? Once you start to get into the
world of 2, 3, 4, 5, 60, 70, 100 functions, how
do you connect them? How do you coordinate them? So let’s first talk
about chaining functions. So we’ve got a bunch
of these functions and we want to
put them together. For that, I usually
recommend Cloud Pub/Sub. So Pub/Sub is a
publisher/subscriber messaging system. So the idea is– just generally, not
related to Functions– but I publish some
message to Pub/Sub. And I can have 1, 10, 100,
1,000, subscribers potentially. And it works over HTTP and gRPC. So you can have any
system listening to these. So even if it doesn’t
run on Google Cloud, as long as it speaks
HTTP, it can respond to these Pub/Sub messages. So it’s a real nice
way to do integration. And rather than just having
one function directly invoke the next, you just
publish it to Pub/Sub, and then whoever wants
to respond to it can. So it’s a nice way of
decoupling your system. So let’s see these
things in action. So let’s say I have an app
where my user inserts– I get a new employee. A user inserts the new
employee data into the database and into Firestore. And we have a Cloud
Function that’s listening for new
employees getting inserted into the employee database. So now, I have a
few other things that I want to do as a result
of this new employee coming on. So I’ll publish a
message to Pub/Sub. It says, hey, here’s a new
employee, user ID Bret, location New York City. And I have a building
badge system, let’s say, that runs on Google Cloud. So I have some Cloud Function
that’s automatically listening to this new user topic. And because it’s part of
Google Cloud and Functions is tightly coupled with those
events, it automatically runs. I don’t have to wire it up. But let’s say I also
have a helpdesk system, some third-party thing
that I’m running that’s not part of Google Cloud. It’s not my app,
but it speaks HTTP. So we can actually be listening
to that same message that comes in. So I’ve got one
published message to Cloud Pub/Sub that says,
new employee, user ID Bret. And we’ve got two
or more systems listening to that same event. Does that makes sense? So this is a good way
to do integrations with third-party
systems and also chain your functions together. Because then if you want
to pull out one function and replace it with a different
one or pull out one function and replace it with
not something on Cloud Functions at all,
if you use Pub/Sub, it’s already nicely abstracted. So it just has to
speak HTTP or gRPC. For monitoring and
error reporting, Stackdriver is built in. So without doing anything,
it’s automatically looking at your logs. So everything you
write out to console– standard console or the
error console– it’ll pick up and flag appropriately. And monitoring is important
because Cloud Functions is billed per usage. So what that means is,
again, if your function runs for three seconds, you
pay for three seconds. And that’s scaled according
to how much memory you’ve allocated, memory in CPU. So if you allocate a
ton of memory in CPU, if it runs for
three seconds, it is going to be more expensive
than if you give it a little bit of memory in CPU
and it runs for three seconds. Does that makes sense? So because of that, you
do want to be aware of, how long are my
functions running for? And how much memory
are they using? And this is a little different. Because normally if you
have a VM that’s running, you’re not paying that much
attention to execution time, unless it’s a response thing. And you’re not really paying
that close of attention to how much memory it’s
using, unless it’s bumping up against some limit
on the machine, if it’s running out of memory. But otherwise, it
doesn’t really matter. But because there’s a direct
financial repercussion, especially if you’re running
thousands or millions of these at scale, that can add up. So that’s all captured
automatically. And you can look in a chart and
see how are my functions doing. It helps you identify memory
leaks and things like that. Just a quick look at the logs– I may not have
time to do a demo. So it captures it. You can do reports
like, hey, automatically let me know when some certain
filter is met on my logs. This is across all of Google
Cloud and not just Cloud Functions. So you can also dive into life
of one particular request. So if it’s doing multiple
things and has an execution ID, you can dig into it
across multiple log lines And then it’s also integrated
with Stackdriver Error Reporting, which is just
watching these by default. Again, this is all
automatically out of the box with Cloud Functions. It’s watching your error
logs for things to happen. And it’s intelligent
about the error logs. So if you have the same
error happen 10 times, it’s just going to give
you one notification so you don’t get blasted
10 different emails or 10 different texts about
some error that’s occurring. You can see this last
happened 10 days ago, and here’s the particular
error, click on it, and see more details. All right, so some
things to consider before using Cloud Functions– I alluded to this,
but it is pay per use. So it’s kind of a complicated
math problem, unfortunately. We do have a
calculator, which helps. But especially when
you’re getting started, it’s a little hard to know
how many times exactly is my function running,
how long does it run for, and how much memory does it use. So general rule of thumb
is just spike out a sample, and start to play
with it, and see what happens so you
can tweak those knobs. There’s a pretty
generous free tier. It’s two million
invocations a month scaled to some amount
of execution time. So a lot of people actually run
their entire serverless apps for free. Because two million is
a lot to get for free. But above and beyond that, you
can use a calculator we have on cloud.google.com/pricing
and tweak those knobs and see. Again, it’s in 100
millisecond increments. So if you run for half a second,
you pay for half a second. So should you go serverless
with Cloud Functions? Yes, otherwise I
wouldn’t be up here. But it’s actually not
for every use case. If you have an existing app and
you want it to go serverless, odds are not super great that
you could just lift and shift that to Cloud Functions. Because you have probably
an entire web backend. So the approach that I typically
recommend– and it is usually successful– is you identify
some piece, some service, you could pull out
of your existing app, put that into a Cloud Function,
have your existing app wrap that call, and now instead
of doing it within your bigger app, make your call out
to the Cloud Function and have it come back. And piece by piece,
you can pull it out. But it’s really unlikely you’ll
be able to lift and shift your app into Cloud Functions. And a lot of that is
because of the second point, which is Cloud Functions
are designed to be stateless or ephemeral, which means,
if my function gets invoked, and I write to disk at
/tmp, and I write some file, the next time my
function gets invoked, that file may or may not be. If it happens to get routed
to that same instance and it’s still warm from
before, that file will be there. But there’s no guarantee. Because I could
scale down to zero. And then the next time
a request comes in, it created a new instance
in a brand new instance. So that’s gone. So your apps have to assume
that anything that they do is gone the next time
the function runs. And that’s not always the case. Sometimes, you do get
the same instance. So you can do tricks like have
some local cache precalculate some intense computation
and store it. So then the next time your
function gets invoked, you check, hey, did I
already calculate this? Is it still on disk? Yes, cool, I just
saved myself some time. Check that value, reuse
that database connection, or whatever. But if it’s not, then you
have to create a new one. Long running compute tasks– so Cloud Function times
out at nine minutes. So you’re probably
not going to render the next awesome digital
Pixar movie on this. But again, the philosophy
is these small, quick, single-purpose functions
that you stitch together to make a larger whole. And then guaranteed
response times– so one of the benefits
of Cloud Functions is that it scales to zero. So when you’re not running your
code, you don’t pay anything. The problem is, if it is at
zero and everything is asleep, the next time a request comes
in, it may take a half second, a second to spin up your
function and do a response. Again, it’s not a long time. One second is not a
long time in most cases. But if you’re doing
gaming, for example, one second could be
pretty significant. So if you need a
guaranteed response time– sometimes we call
that cold start– that first request when
everything is asleep can take a little bit of time. All right, did anybody
text that number earlier? Not one single– OK, too cool. I hope it wasn’t anything weird. If we can go to
the demo machine– maybe I should
check it before I– all right, nothing too weird. Yeah, so it was basically
piggybacking Cloud Storage. So here’s the diagram
at the bottom. It’s a little small so
I’ll explain it verbally. So I’m using Twilio
to create that number. Twilio gives a callback. So I say, hey, call
this HTTP function, which is a Cloud Function,
whenever a text message comes in. So a text message comes in. There’s an image attached. It sees that there’s an image. Oh, there’s even a group text. That’s fun, a group photo. And you can see actually it
replaced the face in the front is an angry one and
other ones are smiling. So Cloud Function then takes
that image from Twilio, saves it to Cloud Storage,
which triggers a Cloud Function to send it
to the Vision API, do sentiment analysis, and
it sees where the faces are in the photo, and
then replaces them with the appropriate emoji. And so you can see how these– when you build with
Cloud Functions, you tend to have
this chain of events. And at first, it
can be intimidating. Rather than just having one
big function that says– if we could switch off from
the demo, that would be great. Thanks. By the way, you texted that. So your phone number is
associated with it, just FYI. I will find you. It wasn’t that bad. But anyway, something about
chain of events, yes– so when you’re building
with Functions, you’ll start to see
this chain of events like a function does
this, writes a file. A function is triggered by that
file, writes to the database. A function is triggered
by that database– I’m almost off the stage now. But when you first see
these architecture diagrams, they can be daunting. And it looks more complicated. And the thing is, you’re just
surfacing what your app was probably already doing. But you’re surfacing
it and you’re decoupling all of those
pieces, rather than having them in one big function. All right, so we have
just a few minutes left. I want to touch on
some things that are new in Cloud
Functions as of yesterday. First is it is out of beta, yay. [APPLAUSE] Yes, very excited about this. It has been a long time coming. It is hard. So it turns out it’s hard to
have these little functions that spin up quickly, run
for a bit at massive scale, and do it under a
service level agreement, particularly in Google Cloud. So we have an SLA behind
Cloud Functions, which is fairly unique in the market. And so it has taken us a while. But we are now there and super,
super excited about that. Python I mentioned earlier. We support Python 3.7. To do it, you do the same
deploy that I did earlier but with –runtime Python 3.7. If you do an HTTP
app, it uses Flask. So if you do a Node app, it
uses Express under the hood. If you do a Python app, it
uses Flask under the hood. So really, really
excited about this– two things I always
get asked about, timed functions, scheduled
functions, which we have, and then Python. So super happy about that. Across the two, both
Node and Python– we talked about Stackdriver
Logging automatically picking up your log files. So that is true whether
you’re using Python or Node. Error reporting also works. And then we build your
dependencies in the cloud. And that’s useful for
a couple of reasons. One is you don’t have
to necessarily know what architecture we’re
using in the cloud. So if you’re doing something–
so in the case of Node.js, we have what’s called
native modules. So this is a Node module that
relies on some actual system dependency. So you need to know what is the
architecture that I’m actually running on, what processor
type, or what OS. And it’s kind of annoying. If I’m writing a
function, I have to know what
architecture we’re using. You as a developer have
to know what we’re using and precompile it and upload it. But since we build in
the cloud, we actually will build it at deploy time. So you just give us
entirely your source. You could point at a GitHub
repo that just has packets.json or requirements.txt. It looks at those, pulls
down those dependencies, builds them when you deploy it. So that’s really nice. Context object changing– I
won’t get into the details. But I mentioned it
just very briefly. Right now, you get one parameter
for these background functions. It’s called event. And you have event.data
and event.context. And we’re splitting those
out into two parameters, data and then optionally context. And this here is just
what context looks like– an event ID, which again
is this ID that traces through the life of your event,
time stamp, and a resource. And then more concretely,
if you’re interested, here’s what one looks
like for Pub/Sub. It says this is a Pub/Sub topic. And the reason it’s so verbose– the
Google.Pubsub.topic.publish– is because there’s part
of this broader effort to do a standardized thing
called Cloud Events so events look the same across
any cloud that you run. And you can actually
identify a specific event across cloud providers
based on the event. Does that make sense? So the structure of an event
is becoming standardized. And then Firebase, I
mentioned very briefly. There’s a new command
line and a new SDK to support Node 8 with
all the same triggers that we had before. But now, you can
actually deploy them through Cloud
Functions on GCP rather than having to deploy
them through Firebase. So before if you wanted
to listen to a Firestore or Firebase event, you had
to actually use the Firebase Tooling to do your deploy. Now, you can actually
do it directly through the gcloud command
line as I did earlier. Multiple regions– so we
were just in US-Central 1. But now, we are in Asia, Europe,
and then two in North America. And the way that it
works is you can actually have multiple regions and
functions in different regions within one project. So you can have the same
function deployed in Belgium that you do in Tokyo, that
you do in South Carolina. And then yeah, –region
and then give it the name of the region you want it in. So currently for the
GA environment, Node 6, we’re using Debian. Going forward, we’re
going to be using Ubuntu. So the one with
ImageMagick and FFmpeg, the FFmpeg was tons and tons
of people were asking about it. So it’s actually just
in the image now. And the other one that I
get asked about all the time is for doing headless Chrome. Our Debian instance before
lacked some system libraries. So if you’re doing things
like automatic scraping, and you want to have this
fake Chrome browser that’s going out and
rendering web pages, you can do that now using the
headless Chrome libraries. Other new stuff I’m just
going to mention– security controls– we’re announcing
that, at some point later this year, you’ll be able
to have your Cloud Functions talking to– if you have a
private network in Google Cloud, right now you can’t
actually get into that. But that will be coming. IAM– so right now if
you create a function, say an HTTP function,
by default it is just available to the
whole world to invoke. And if you want to do off,
you have to actually put it in your function. So coming, we’re going to
have IAM integration so you can control not just
external users calling your application
or your function, but you can actually
set up which functions can call which functions
and have access to resources, to really help
you tightly control the security model around there. Cloud Scheduler, I
mentioned, if you want to run every minute,
or 10 minutes, or whatever. Scaling controls– so one of
the problems with serverless Cloud Functions is it
scales up big, right? So that’s nice in
the sense that, if I get 1,000 requests
that come in, it will scale up and handle them. But if all those
functions are now talking to some third-party
API that’s rate limited or some database
that I have that doesn’t scale up to infinity,
we can crush our own database, right? So this part scales up, but
maybe the parts behind it don’t. So you can actually
set scaling controls and say, hey, don’t run any
more than a 100 or 200 Cloud Functions at the same time. So that way, I don’t take
down my external resources. And then Cloud SQL
Direct Connect– it may only affect a few people. But if you’re using Cloud
SQL from Cloud Functions, previously you actually had
to go through its public IP address. You had to leave Google Cloud,
go through the public internet, come back in to get
to talk to Cloud SQL. And now, it remains within
the Google network and secure. So those are all of the new
things with Cloud Functions. If you want to know more,
Cloud.Google.com/Functions. We’ve got a bunch of tutorials. We’ve got updated docs
for Python and Node 8. We’re answering questions
on Stack Overflow. You can find examples on GitHub. And like I mentioned,
there’s a free tier, two million invocations a month. So super easy to check out. And I look forward
to hearing from you. Thank you. [APPLAUSE] [MUSIC PLAYING]

8 thoughts on “Cloud Functions Overview: Get Started Building Serverless Applications (Cloud Next ’18)

  1. Great talk. Couple criticisms/questions:

    Development workflow:
    There seems to be no emphasis on the development workflow. How can developers effectively BUILD functions, debug them, and know that when they deploy them that they will only need to solve small wrinkles? The current workflow involves writing the code(unit testing is more or less going to catch only trivial items because CFs biggest win is the integration with storage buckets), deploying it, waiting 2+ minutes(its realistically around 3-5 minutes FYI), hitting the http endpoint, the sifting through Stackdriver logs with a bunch of console.log statements such as console.log("Step 1"), console.log("Step 2"), etc. The reason for this is because you have no idea why your cloud function failed since there's no way to debug.

    Node Version:
    Why isn't at least the LTS version of Node supported? Thankfully we got version 8, but its 8.11.1, and the LTS version of Node.js is 8.11.3. Yeah I know its not a big difference but there are substantial security improvements that are made in the Node.js runtime and its painful to constantly dev in a version that you know isn't supported. Additionally, node 8 runtime is in beta with no SLA, deprecation policy and YMMV if it actually runs in production. Node 6 is VERY old and outside the LTS.

    Debugging:
    https://github.com/GoogleCloudPlatform/cloud-functions-emulator

    `Disclaimer: This is not an official Google product.`
    This tool is absolutely critical with regard to any kind of sensible debugging. It's in an alpha stage according to the GCP documentation:
    https://cloud.google.com/functions/docs/emulator

    Additionally, " The Emulator currently requires Node.js >= 6.11.1. Note that the Node.js Emulator only works with Cloud Functions written for the Node.js 6 runtime.".

    So while cloud functions are a great concept, the developer aspect is totally forgotten. Aside from super trivial functions(which may be the main use case, at which point, why not just run an App Engine instance?), its very difficult to dev for.

    Machine Size:
    Any hope for anything over 2gigs?

    A New Hope(yes star wars pun):
    Any hope for Cloud Functions with Go? with robust debugging support?

    Thanks and apologies in advance if overly critical but I've been using CF in production over the past year and have felt a lot of pain.

  2. I have been a Software Architect for over 20 years and this is one of the best presentations I have seen. From a point that I have never worked with Cloud Functions, this was the greatest starting video, and quite a pleasure to watch. I learned everything that I needed and you sprinkled a lot of other valuable information in between. Very nice job!!!

  3. If you organize your functions in folders like: users/addUser.js, users/renameUser.js, orders/addOrder.js, orders/search.js,
    can the URLs be made to include the folder name like: http://mybaseurl/users/addUser, http://mybaseurl/orders/search ?

Leave a Reply

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