Hello, cloud gurus and welcome to GCP service spotlight.
In this series, we put the spotlight on specific GCP services,
walking you through detailed technical demos to explore their features,
benefits, and costs. I'm Tim Berry.
And today we're going to talk about Google cloud functions.
Cloud functions is a fully managed serverless service for running your
functions. Well, what do I mean by functions?
They're small pieces of code that perform a single action,
and they're usually triggered by an event like a change in a storage buckets or
a database, or even a call to an HTTP endpoint.
Cloud functions go from zero to planet scale.
You only pay for the execution time of your code down to the nearest 10th of a
second. And because it's serverless, there's nothing to install, manage,
or update. So you can just focus on your code. In this episode,
I'm going to show you a technical demo of what cloud functions can do.
Then we'll discuss the pros and cons. And finally,
like some self appointed judge of cloud services. I'll give you my verdict.
Cloud functions is a serverless service in the truest sense.
The infrastructure it runs on is completely abstracted away from you and managed
by Google. You just consume it in terms of the execution time of your code.
It also provides automatic scaling based on the demand of your workload.
That means if your code is idle, you won't pay a penny.
But if your function is suddenly in high demand,
the resources required are already there to handle the load without you having
to lift a finger.
Cloud functions is an event driven functions as a service or FaaS
product.
Using events driven functions allows you to connect and extend cloud services
using other GCP products as building blocks or integrating with third party
services through web hooks.
If you need some logic or application glue to hold your infrastructure together,
find functions is the perfect place to run it.
Cloud functions can be written in node.JS versions eight or 10,
Python three, go or Java 11.
So what events can trigger the execution of your code right out of the box cloud
functions can provide an HTTP endpoint for your function.
Simply calling that URL will trigger the function to execute.
By default functions expect the request to be authenticated using IAM,
but you can disable authentication if you want to make your function open to the
world.
Cloud functions can also be triggered by messages in a pub sub topic events in a
cloud storage bucket, or changes to a cloud fire store database.
There are also triggers for events in Firebase Google's mobile application
development platform,
including changes in Firebase realtime and Firebase authentication events
and functions can even be called by workflows in cloud scheduler and cloud
tasks. Now, as I said,
one of the main benefits of using a serverless functions model is that you only
pay for what you use. And just like with other GCP products,
cloud functions also comes with the generous free tier. Now cloud functions,
pricing breaks down into two components,
invocations and compute time.
And invocation is when your function is run every month,
you'll get the first 2 million invocations of your function for free.
And after that you'll pay 40 cents for every million invocations.
In terms of compute time, it's a little more complicated.
Your function can be provisioned in one of five different sizes.
Each getting an increase in the amount of memory and CPU assigned to them.
For example,
the smallest size gives you 128 megabytes of memory and about 200
megahertz of CPU to run your function.
The compute time price for this size is $0.00000231
per second.
The price then goes up gradually to the largest size of two gigabytes of memory
and 2.4 gigahertz of CPU at
$0.000029 Per second. More generally,
then you can work out the compute time cost of any function in gigabyte seconds
and gigahertz seconds,
which you can now see on your screen because I can't keep reading out long
decimal places. You'll also get a monthly free tier allowance of compute time.
Bear in mind that some newer regions have slightly higher pricing and just like
every other service and every other cloud you'll always pay for network egress.
So yes, the costs aren't simple,
but it's got to be this granular to give you the best possible value and to make
sure you're only paying for what you're using.
There is some really helpful pricing examples in the cloud functions,
documentation,
and you can always use the GCP cost calculator to check your numbers.
Now we've already talked about the main benefits of cloud functions.
It's serverless, it's pay as you go, and you can get up and running in no time,
but why might it be a good fit over other serverless providers? For a start,
just like with every other GCP service you get end to end encryption of your
data at flight and at rest.
And you benefit from Google's own private super-fast global fiber network
functions are deployed regionally with built-in resilience across multiple
availability zones,
and you can apply the principle of least privilege to secure your functions.
Using granular IAM permissions.
Cloud functions also has built in observability and debugging with integrations
for cloud trace and cloud debugger.
And you don't need to worry about vendor lock-in as functions are easy to port
to other frameworks and serverless environments. Okay,
enough talk let's head to the demo and actually see some functions in action.
[Inaudible].
Cloud functions can be found in the compute section of the GCP.
Menu.
Let's look at the most basic way to create a function.
We can do everything from right here in the UI.
First I'll click create function. I'll call my function.
Hello world. Here.
I can select a region for my function to run in.
Remember you get built in multi zone redundancy across the selected region.
I'll just leave mine on the default, us central one for now.
Next I can set the trigger type. As I said,
there are many types of trigger you can use.
These are all things that emit an event that your function will respond to.
I'll stick with HTTP for now.
And as you can see this automatically configures a URL,
or I can send HTTP requests to my function.
There's nothing else I need to spin up and secure connections through HTTPS are
built in as standard.
Cloud functions let you get as granular with security as you like restricting
access to specific surface accounts or IAM roles,
but for now I'll just select allow unauthenticated invocations,
which basically means anyone in the world can access this URL.
I'll click save on my trigger. Then click next.
The cloud functions UI actually has a built in editor so I can write my function
here in the browser. In fact, it looks like it's trying to write it for me.
Here's a basic hello world function in node dot JS.
I can switch to any of the other supported languages and I'll get the same
boilerplate function. Just specific to the language I've chosen.
The thing they've all got in common is that they all have access to the HTTP
request. So your function can deal with whatever data has been sent to it.
Of course, you don't have to write your code right here in the browser.
And from the UI, you can choose different sources,
such as a zip file or a get repository. In fact,
there are much more efficient ways to deploy a function,
which I'll show you in a moment.
For now I've selected go and I'll just click deploy.
It'll take a minute or so to complete.
The first time I deploy a function under the hood cloud functions is preparing
my code to serve requests.
The green tick means my function is ready. So let's take a look at it
under the trigger tab. Here's the link to my function. If I click it,
my function will execute, do its job, which is to say, hello world and quit.
This is the important distinction of functions based compute services until
the event is triggered. Nothing is running and once it's done its job,
nothing will be running again.
Let's look in the logs and I can see that I've consumed four milliseconds of
compute time to run my function. It doesn't get much more granular than that.
Now let's do something a bit more interesting.
Cloud functions are a great way of abstracting away services from other
applications.
You can run multiple and then loosely couple them using cloud pubsub as your
message bus.
Let's say I've got a website that lets users upload images,
and I want to generate a thumbnail for every image uploaded rather than do that
image manipulation in my main application,
I'll abstract it away into a function.
That way it can carry on in the background without blocking my main application.
So here I've written a simple cloud function in Python.
When this function is triggered,
it's going to receive the name of a newly uploaded image and a cloud storage
location.
Then it's going to use the Python wand library to resample that image into a
thumbnail and write it into a different bucket in cloud storage.
Rather than use the UI I can deploy this with the G-Cloud command line.
I'll use G cloud functions deploy. Then the name of my new function,
which I'll call make thumbnail.
I'll specify the runtime of Python 3.7 and then my trigger resource,
which this time is the name of a cloud storage bucket that I've already created.
My trigger event is google.storage.object.finalize.
This is an event that occurs when a file has been successfully uploaded to cloud
storage. Let's test it out.
I'll go into my uploads bucket in the storage browser and upload an image.
And now here's the original image in my uploads bucket.
When that image upload completed,
it created an event that triggered my function.
So let's go and look in my thumb nails bucket,
and here's my thumbnail. Let's deploy another function.
Now let's say I want to run a responsible website and I need to make sure that
what my users are uploading is family friendly.
So I've written another function here that runs the image past Google's cloud
vision API, which can rate it against a variety of categories,
including the likelihood that it contains adult or violent content.
If an uploaded image gets flagged,
I can send a message to a pub sub topic containing the location of this image.
And again, I want this function to simply trigger.
Whenever an upload is written to my uploads bucket,
I'll use the G cloud functions, deploy command again, to deploy this function.
The trigger resource and trigger event are the same as last time.
So now let's upload an image that's likely to get flagged,
rather than that adorable pony. I'll use a picture of a zombie. This time,
both functions will be triggered by the uploaded image.
The thumbnail gets generated by the first function and the second function
scans the image through the cloud vision API. If it flags the image,
it will send the cloud storage location to my pub sub topic.
And here's that message. It must've been a really scary picture.
What happens next could be anything in theory,
a message published to this topic could spawn another function or a separate
application could pull messages from this topic to deal with them.
So we can start to see,
there are a variety of ways to connect multiple services together with functions
and pub sub for easy deployment of cloud functions.
You can integrate G-Cloud commands into common CICD tools like cloud build,
or you can even deploy cloud functions with Google's own deployment manager,
or infrastructure as code tools like Terraform.
Now you've seen code functions in action. Let's sum up the pros and cons.
Just like we saw in the demo, it's the perfect place to run event driven code.
And because it's completely serverless,
we don't even have to think about infrastructure yet.
It's still really cost effective.
If my thumbnail function that you saw in the demo got called half a million
times a month, it would still only add about $5 to my entire GCP bill.
That's just awesome.
The other thing I love about cloud functions is how developer friendly it is.
Not only do you get integrated tracing and debugging,
but using Google's functions framework,
you can easily port your functions to other environments like cloud run and K
native. Really, there are only two cons to using cloud functions.
The first is just the nature of a functions as a service model,
meaning that your code must be event driven. It has to respond to a trigger,
do something and quit long running processes are not supported,
but there are plenty of other compute options for that. And finally,
you have to use one of the supported node, go, Python or Java runtimes,
but as those are the most popular languages,
I don't see this as such a big deal.
If your team needs to use an unsupported language or runtime check out cloud run
instead. So should you invest, evaluate or revisit?
My recommendation is evaluate,
and this was a really tough call because I'm a huge fan of cloud functions.
And I really want to tell you to invest,
but the truth is event driven functions might not be quite the right fit for
you.
And the nice thing about GCP is there are plenty of other options that might be
better for your organization like cloud run or even Kubernetes engine,
but definitely evaluate.
If you have any event driven code that you need to get up and running quickly,
cloud functions is the obvious choice. It's low cost, high performance,
developer friendly, and maintenance-free check it out and you won't regret it.
So that's it for this episode, keep being awesome cloud gurus.
And I hope to see you next time on GCP service spotlight.