[MUSIC PLAYING]
STEREN GIANNINI: Hi.
I'm Steren.
KAROLINA NETOLICKÁ: And I'm Karolina.
STEREN GIANNINI: Today, we are going
to talk about how to run your jobs on surveillance
with Cloud Run.
First, let me recap what Cloud Run is.
Cloud Run allows you to deploy and scale applications
fast and securely in a fully managed environment.
Let's jump into a quick demo.
I will show you how easy it is to deploy your Python
app to Cloud Run from a GitHub repository.
From the Cloud Console, I navigate to the Cloud Run page.
I create a service.
I select "Continuously deploy from a source repository."
The panel opens where I can connect to GitHub
and select one of my Git repositories.
My repo is a Python application.
It doesn't include any Docker file.
Cloud Run can build from sources from many popular languages.
For the sake of the demo, I will make my service public
by allowing unauthenticated invocations.
And I click Deploy.
My code is built into a container image by Cloud Build
and then will be deployed to Cloud Run.
If we take a quick look at the code,
we can see it is a standard Python flask application.
I used a requirement that takes the file
to declare my dependencies.
And there is no Docker file.
Once completed, I get a stable and secure HTTPS endpoint
to invoke my service.
Cloud Run will start as many instances
as needed to handle all incoming traffic, including scale to 0.
Let's give it a try by providing an image.
We can see that our microservice has
transformed my picture of Half Dome into a coloring book.
Nice.
Back into the user interface, I can see which
Git commit is actually running.
When I push to my Git repository,
my code will automatically be built
and new revisions of this service will be deployed.
I can see at the top a build history at a glance.
I can see key metrics of my service and my service's logs.
I can quickly edit settings of my service,
like environment variables, mounting Secrets,
connecting to Cloud SQL.
Let's select More Memory in order
to be able to process bigger images.
By default, these new settings will roll out
as soon as I click Deploy.
But let's do something different and not serve this new revision
immediately.
Once deployed, this new revision is serving 0% of the traffic.
I can test it using a dedicated URL endpoint.
And then I can gradually roll out traffic
to it-- let's say 10%.
If anything goes wrong, I can always roll back
to a previous revision.
So hopefully, this demo shows you
how easy it is to deploy an app from a GitHub repo
to Cloud Run.
Cloud Run allows you to deploy and scale applications
fast and securely in a fully managed environment.
As you've seen, it is simple and automated.
You have no infrastructure to provision in advance,
no cluster to manage.
And it allows you to be more productive, to move faster.
So when should you use Cloud Run?
We identified three big categories--
first, websites and APIs.
This goes from traditional server-side rendered web pages
to REST or GraphQL APIs.
But Cloud Run also has built-in support for web sockets,
allowing you to stream data between front end and back end.
Then private services-- for example,
you can put a website behind an authentication page
with Google Cloud Identity-Aware Proxy.
You can build private microservice-to-microservice
architectures, either over HTP or gRPC.
And last, data processing--
Cloud Run services can be invoked by Cloud Pub/Sub,
can receive tasks from Cloud Tasks,
and receive events from Eventarc.
Cloud Run automatically scales the number of instances
of your code, even down to 0.
If your app suddenly gets a burst of traffic,
there is nothing to worry about.
Cloud Run will scale fast to handle all incoming requests.
And when fewer instances are needed,
Cloud Run will automatically reduce their number down to 0
if no traffic is received after a while.
But how is Cloud Run priced?
Well, first, Cloud Run has a free tier.
Each month, you get 2 million requests
available at no charge.
Then Cloud Run truly is pay per views.
You pay for the exact CPU and memory used by your services
when they are processing requests
with 100-millisecond granularity.
That means that there is no charge if it's not in use.
As we've seen, we can deploy source code written in Node.js,
Python, Go, .Net, Kotlin, Scala, Java,
and any other language via containers.
Container images are, basically, like a ZIP file.
They allow you to package everything
that's needed to run your code.
This, of course, includes its language packages,
but also any native libraries or custom
binaries that you would need.
And finally, I want to highlight how Cloud Run integrates
with Firebase.
Your code on Cloud Run can query data from Firestore
or use Firebase clients or admin SDKs.
But you can also use Firebase Hosting
in front of your Cloud Run service
in order to host static files or assets,
to cache your HTTP requests using the cache control header,
or to easily set up your own custom domain.
And now let's hear from Karolina.
KAROLINA NETOLICKÁ: So now that we've learned about Cloud Run,
let's talk about Cloud Run jobs.
Imagine you're using Cloud Run to run an e-commerce site
and it's working great.
Cloud run is autoscaling your service to meet demand.
You're really happy that you don't need
to manage any infrastructure.
And your developer velocity has gone up.
But you find yourself with pieces of work
that don't fit neatly into any Cloud Run service.
For example, your suppliers send you
invoices that you need to periodically process and pay.
You could write a web service that does this task.
But what you'd really like to do is write a script
to process all these invoices and then
run the script as a cron job.
This is where Cloud Run jobs come in.
Cloud Run jobs are a new feature of Cloud Run that we just
announced here at I/O. Cloud Run jobs
let you run scripts and data processing jobs in Cloud Run
right alongside your services.
This means that you get to benefit from Cloud Run's
simple integration with the rest of the Google Cloud ecosystem,
including Secret Manager and fine-grained IAM.
Cloud Run also works with many common storage systems.
So you have flexibility on where to store any data
that your job is processing.
What's unique about Cloud Run jobs
is that they start up much faster than starting
a VM to run a script on.
In fact, many jobs start running in as little as 10 seconds.
If your workload is parallelizable,
you can further speed it up by splitting your work
into multiple tasks, each of which
handles a subset of your input.
Between the fast startup and running in parallel,
Cloud Run jobs work particularly well for situations
where you need jobs to complete quickly--
for example, because there's a person waiting for the result.
So what are Cloud Run jobs useful for?
First, they're a great match for scheduled scripts, things
like nightly reports, database maintenance, and audit scripts.
You can run these scripts on a schedule
by using Cloud Scheduler.
Cloud Run jobs are also great for background processing,
where some user interaction has resulted
in offline work that needs to be done in the background--
for example, sending email campaigns for
abandoned shopping carts or running web testing suites.
Finally, you can use Cloud Run jobs for batch data processing.
So let's go back to our previous example of processing invoices.
I'm going to show you how you can use Cloud Run
jobs to process these invoices using Document AI
and to store the parsed data in Firestore.
To speed up processing, we'll run the job
with eight parallel tasks, each of which
will process a subset of the invoices.
We'll also show a simple web service
that lets us review the processed invoices
and approve them for payment.
Here's the Cloud Storage bucket where our invoices are stored.
New ones come in every day and are
placed in a folder called Incoming to indicate that they
haven't been processed.
Right now, this folder has a few dozen invoices
waiting to be processed the next time the job runs.
Let's take a look at a few of them.
You can see that these are designed for humans to look at
rather than to be machine-readable.
Here's the code we'll use to process these invoices.
The code loops through the contents of the storage bucket.
First, it skips any invoice that will
be handled by a different task.
Each running task is aware of its task index.
So it can look up which file name prefixes it is responsible
for versus other tasks are responsible for
and decide whether to skip or process
this particular invoice.
It also skips anything that looks like a folder.
Then it calls Document AI to extract
the invoice data, such as vendor names and totals.
And it saves that information to Firestore.
Finally, it moves the invoice to a different folder
so that it won't be processed again
the next time the job is run.
Now let's build a container.
I'm going to use Cloud Build from the command line
to create the container and save it to a repository.
Now I'll create my Cloud Run job.
I'll specify the image to run, the region to run in,
the number of tasks, and a few environment variables
that the container needs.
And I have a job.
Let's take a look at my list of jobs in the Cloud Console.
There it is.
I'm going to click Execute.
And here's my job running.
I'm going to click on it to get more details.
The progress bar at the top is going
to update as tasks start and finish.
While we're waiting for the job to complete,
let's take a quick look at the logs.
You can see the debugging messages right here.
So you don't have to navigate away.
The job succeeded.
Let's take a look at the output.
The data that's been pulled out from these invoices
has been saved in Firestore.
We see here that we have a collection of invoices.
And for each invoice, we can see the amount, the company it's
from, the due date, and so on.
And to make it even easier to see,
here's a simple web page hosted as a Cloud Run service that
lets you review the processed invoices
and select whether to approve them for payment.
Finally, we want this job to run every night.
Cloud Scheduler is perfect for this.
I'll give Cloud Scheduler a name and a region.
I'm going to run my job at 1:00 AM every night.
My Cloud Run job will be triggered via an HTTP request
through the Cloud Run admin API.
You can find the URL in the documentation.
As the last step, I'll give Cloud Scheduler permissions
to start the Cloud Run job.
The Scheduler trigger is ready.
It will run tonight.
But let's test it once.
I'll click Run Now.
And then I'll go take a look at my job.
I see a new execution has already started.
And I already have tasks running.
So let's recap what I've shown you here.
I built and deployed a Cloud Run job, which loads invoices
from Cloud Storage, calls Document AI to analyze them,
and stores the parsed invoice data in Firestore.
My job runs every night.
And we have a nice interface for our team to approve invoices.
And at the end of all of this, we have no VMs or clusters
that we need to manage.
And we only pay when our services or jobs are actually
running.
So to summarize it all, Cloud Run
lets you run your containers in a fully managed environment
so that we take care of infrastructure management
and you focus on your business logic.
Use Cloud Run services for web services and Cloud Run
jobs for containers that run to completion,
such as scripts and data processing jobs.
STEREN GIANNINI: Cloud Run is a simpler way
to deploy your web services--
KAROLINA NETOLICKÁ: --and your jobs.
STEREN GIANNINI: Go check them out at cloud.google.com/run.
Thank you.
[MUSIC PLAYING]