Serverless at Google Cloud

The Cloud Run deployment workflow is elegant

So, I hope you liked that demo.

The Cloud Run deployment workflow is very straightforward.

First, you write your application using your favorite programming language. With it you'll be bringing up a an HTTP server of some kind.

The second steps is to build and package your application into a container image. You can do this yourself, for example by providing a Dockerfile, or you can have Cloud Run handle the packaging.

Finally, you deploy the container image to Cloud Run. You'll get a unique HTTPS endpoint back.

Cloud Run starts your container on demand to handle all incoming requests.

As a software engineer, I'm really excited about this. This is a process that lets me focus on writing code, and it shields me from all the infrastructure toil underneath.

You didn't see me write 5 yaml files. You also didn't see me create a cluster, or a virtual machine. That's not because I did that before I came here to give this talk. It's not necessary with Cloud Run.

About me

Wietse Venema (pronounce Wee-tsuh)

Engineer at Google

I'm from the Netherlands

I'm not the famous Wietse Venema who created Postfix and coincidentally also works at Google Cloud!

Before I dive deeper into serverless at Google Cloud, I'd like to tell you who I am.

My name is Wietse Venema. My name is pronounced like this: “Wee” (like in we) “tsuh”. “Wietse”

I'm a software engineer at Google. I work on serverless primarily. My mission is to keep serverless easy to understand while we make it even more capable of running different workloads.

I'm from the Netherlands - which you could probably tell from my accent. That means I own more than one than one bicycle.

In case you're Googling me right now - I have a very famous name twin.

There's the famous author who created Postfix and works at Google Cloud, and then there's the author who wrote the book on Cloud Run and works at Google Cloud (that's me)

About me

Daniel Stamer

Customer Engineer at Google

Digital Natives, Berlin

stamer@google.com

Before I dive deeper into serverless at Google Cloud, I'd like to tell you who I am.

My name is Daniel Stamer.

I am working with digital-native startups and scaleups out of Berlin.
I am a Software Engineer first and as such I love to build things and I am a huge fan of infrastructure that's enabling me, rather than getting in my way.

My way into cloud was romantic: I remember a time where I had to wait 3-4 weeks for a VM and once I realized that this takes only a minute in cloud, cloud had my interest, like completely.

When Google introduced Cloud Run in 2019, I was immediately into it. This is what I've always wanted and ever since, Cloud Run has become go-to platform of choice and I hope I am able to explain why in this session.

Serverless at Google

Demo
Serverless at Google
Cloud Run

Services
Jobs
Integrations

Autoscaler Demo

What is serverless?

Serverless is a funny word.

It's funny because it's a misnomer (there are still servers involved).
It's funny because it means different things to different people.
(As you can imagine, that makes marketing incredibly hard.)

I'll say serverless, and you'll think of one thing, while I meant something else.

Let's make this more interactive. What does serverless mean to you?

[Allow some time for audience input. Here are some words to start the conversation]

AWS Lambda (or functions in general).
Event-driven programming.
Additional new concepts and idioms to learn.
Impossible to debug.
No code.
It's stateless. You can't store data.
You need a complex architecture to do simple things.
Vendor lock-in.
Low interoperability.
It's for newly built apps.
Great for a hobby project, but don't try to build something serious.

This is a serverless product at Google

It maximizes developer productivity
It is self-operating
It is scalable out of the box
Its cost model is pay-per-use

Simple…......…... is what makes you more productive

Simple and capable is what makes you more productive

How does serverless make developers more productive?

Serverless lets you focus on your application code and shields you from infrastructure management toil.

It does this by being simple, and automated.

Simple means you can use a small amount of code or configuration to a great effect.

Simple means there is a low barrier-to-entry.

Simple means you can get started with what you know today, using the patterns you're already familiar with.

[advance to transition]

Simple is a word with multiple meanings.

It can mean limited in functionality, but that's not what I mean here. If I say serverless at Google is simple, what try to communicate is that it is simple and capable.

Simple means easy to understand, as well as effective and constructive.

Self-operating means there's less to worry about in production

Self-operating means there's less to configure

Self-operating means there's less to worry about in production.

For example, you can't configure the Cloud Run autoscaler. It figure out how to do the right thing and makes sure to handle very request.

Self-operating also means that we'll give you helpful recommendations if you've configured your Cloud Run service with more permissions than it actually needs.

[advance to transition]

We believe that the only decisions a human should make, are the decisions only a human can make.

We solve that by providing better abstractions and using automation to prevent toil.

It means we expose less configuration settings because the product automatically makes good decisions and does the best thing for your workload.

The effect is that your experience is easier, and it also means that your application is more reliable.

Serverless runs directly on top of Google's scalable infrastructure

Serverless has a pay-per-use cost model

Summary

It maximizes developer productivity
It is self-operating
It is scalable out of the box
Its cost model is pay-per-use

Serverless products on Google Cloud


Run	Build	Connect	Data

Run your code

	Cloud Run
	App Engine
	Cloud Functions

Build your code


Cloud Build	Artifact Registry

Connect your services


Workflows		EventArc		Pub/Sub

	Scheduler		Tasks

Storing data

Firestore, BigQuery, Cloud Storage

Serverless at Google

Demo
Serverless at Google
Cloud Run

Services
Jobs
Integrations

Autoscaler Demo

This is Cloud Run

Run your code in containers directly on top of Google's scalable infrastructure

Container images are archives with files

A container represents a running application

Build your source code to create a container image

Containers can run anywhere

What's important to remember

A container image is an archive with files.
A container is a running container image.
A container image has your application and all files your application needs to run.

Two ways to run your code

Cloud Run service

Used to run code that responds to web requests, or events.

Cloud Run job

Used to run code that performs work (a job) and quits when the work is done.

Sending a request to a service starts a container

Your code starts a server

Three ways Cloud Run helps you avoid infrastructure toil

Unique HTTPS endpoint for every service
Fast request-based auto-scaling
Built-in traffic management

Unique HTTPS endpoint for every service

First, every Cloud Run service is provided with an HTTPS endpoint on a unique subdomain of the

*.run.app

domain.
Cloud Run manages TLS for you - you don't need to do anything with HTTPS in your container.

If you're familiar with Google Cloud, it's good to know you can also use the global external HTTPS load balancer to route requests to Cloud Run.

This is useful if you want to bring your own domain or TLS certificate, and if you want to route requests to the same domain to several services using more advanced routing.

Support for using internal load balancers is currently in preview. What that means is that you can give a Cloud Run service essentially an internal IP in the VPC network.

Fast request-based auto-scaling

Built-in traffic management

Third: Traffic management.

Every deployment of a new container image creates a new revision.

Revisions are immutable, Cloud Run manages them for you if you deploy a new container image, or if you change configuration that changes how Cloud Run starts or runs the container (examples include container arguments, the port number, or runtime configuration).

You can tell Cloud Run to route incoming traffic to the latest revision.

You can also roll back to a previous revision, or split traffic to multiple revisions at the same time, to perform a gradual rollout.

A gradual rollout is useful if you want to reduce the risk of deploying a new revision.

You can start with sending 1% of requests to a new revision, and increase that percentage while monitoring telemetry.

Cloud Run scales to zero containers

Pay-per-use pricing for Cloud Run services

Scale to zero is attractive for economic reasons since you're charged for the CPU and memory allocated to a container instance with a granularity of 100ms.

If you don't configure minimum instances, you're not charged if your service is not used.

There are two pricing models you can enable. Request-based is the default, and instance-based pricing is the alternative mode.

First, request-based. If a container instance is not processing requests,
the CPU is deallocated and you're not charged.
Additionally, you pay a small per-request fee.

Second, instance-based. You're charged for the entire lifetime of a container instance. There are two critical differences:

First: The CPU of a container instance is always allocated.
Second: There's no per-request fee.

Faster cold starts

A disposable container filesystem

Container instances on Cloud Run are disposable. If a container is not handling requests, Cloud Run eventually shuts it down.

Every container has an in-memory, writable filesystem overlay, which is not persisted if the container shuts down.

Cloud Run independently decides when to stop sending requests to an instance and shut it down, for example when scaling in.

To receive a warning when Cloud Run is about to shut down a container instance, your application can trap the SIGTERM signal. This enables your code to flush local buffers and persist local data to an external data store.

To persist files permanently, you can integrate with Cloud Storage, mount a network filesystem such as Filestore (managed NFS), or store data in a key value store or a database.

When to use Cloud Run services

Websites and web applications
APIs and microservices
Streaming data processing

Serverless at Google

Demo
Serverless at Google
Cloud Run

Services
Jobs
Integrations

Autoscaler Demo

Use Cloud Run jobs to run code to completion

Array jobs are a faster way to process jobs

When to use Cloud Run jobs

Script or tool
Array job
Scheduled job

Demo!

👷‍♀️	👷‍♂️	👷‍♀️	👷‍♂️	👷‍♀️	👷‍♀️	👷‍♂️	👷‍♀️	👷‍♀️	👷‍♂️

            retrieving traffic split ...

That's a wrap!

This deck is deployed on Cloud Run:

$ gcloud run deploy --image gcr.io/serverless-is-more/run-squared