Where should I run my code?

Where should I run my code? Katie McLaughlin Developer Advocate, Google Cloud

So, “where should I run my code?” I hear you ask. Well,

It depends.

Thank you for coming to my talk! :D

Okay, fine.

Saying “it depends” here is a bit of a cop out, and I still have 28 minutes of speaking time So Instead, I offer the following.

I am a sysadmin, but I”m not your sysadmin.

I can’t tell you what will work for your system. If I did tell you a solution, you may not like it, you may not understand it which means you won’t be able to maintain it. Which is far worse.

So instead I’m going to give you information to help you make an informed decision.

By the end of this talk, you should have an understanding of a few of the major options out there, and hopefully have an idea about which one is right choice.

But what is the right choice

The right choice is what is right for you

As I said, I’m not your sysadmin, beyond this presentation I’m not going to be able to help you. I won’t be there oncall to help fix your systems, I can only give advice now.

The choice has to be right for you.

Today we’re going to cover four areas of Google Cloud: Cloud Functions, App engine, Cloud Run, and Compute engine.

Cloud Functions Managed code execution

A serverless environment to build and connect cloud services

Event driven - connect Cloud services via Cloud Pub/Sub, Cloud Storage, HTTP requests & more

Serverless Fully managed execution environment Pay only for what you use Autoscales with usage

What do you have to worry about? Events Function Definitions

What is managed for you? Everything else.

Good fit? Constraints?

Good fit Serverless Using Cloud Pub/Sub, Cloud Storage Don’t want to think about runtime environment Data transformations (ETL) HTTP glue Constraints Function level granularity Must interact via events Specific language runtimes: Node.js, Python, Go.

Don’t have to even think about servers Pay only for what you use Simple developer experience (deploy functions not apps)

App Engine Managed Runtimes

App Engine goal: let developers focus on app code No servers to manage, scale up fast, scale down to zero No patches/updates Versioning Traffic splitting

Open-source, idiomatic experience Use any extension, binary, or framework Supported Runtimes Python, Java, Node.js, PHP, Ruby, Go Use Google Cloud APIs directly

What do you have to worry about?

Code HTTP Requests Versions

What is managed for you? Everything else.

Good fit? Constraints?

Good fit HTTP/S request-response Stateless serving applications Scaling to high traffic

Constraints Standard Runtimes for Python, Java, Node, PHP, Ruby, Go HTTP/S only

Flexible runtimes Inherit Docker constraints Not best for very low traffic sites

Developers focus on code Optimized for web serving workloads Especially great for variable load

App Engine currently serves more than 100B requests per day

@glasnt Cloud Run Managed containers 03

Now generally available!

Input: container image with code listening on $PORT for HTTP

SSL termination HTTP requests to running containers 1-80 concurrent requests, configurable Scale to zero Pay only for actual CPU & memory used

Code in a container image Building the image Listening on a $PORT * container contract: it lists the details of ports, the envvars you get, the container instance sandbox, etc. If you need to be doing more low level things, you may hit limitations here.

What is managed for you? Everything else.

Good fit? Constraints?

Good fit Stateless HTTP request-response workloads Scale: way up, down to zero, bursty Specific runtime requirements

Constraints Must use containers Decide on build process (Cloud Build, etc)

Why Cloud Run?

Serverless developer experience Decide on operations model at deployment time Change with a re-deploy Runs anything that can run in a container and listens to HTTP. Open: run same containers on your machines

Compute Engine Virtual Machines

@glasnt What is Compute Engine? Virtual machines and networking Per Virtual Machine: ● up to 160 vCPUs ● up to 3,844 GB RAM ● up to 64 TB of disk ● optional GPUs, TPUs Each specification independently configurable

What do you have to worry about? Virtual machines and networking

Start quickly, ~20 seconds to user code running Pre-built images, or create your own Debian, CentOS, CoreOS, Ubuntu, RHEL, SUSE also Windows Server Datacenter!

What do you have to worry about? Your software Operating system / disk images CPU, RAM, Disk Networking - Firewall, Load balancers, VPNs

What is managed for you? Everything else.

Good fit Existing systems (lift and shift) 1:1 container:VM mapping Specific OS / kernel required License requirements Running databases

Constraints Scaling speed floor ~20s per VM, 1000s in ~60s Decide how to handle software updates

Consistency - ask for 10 VMs, you get 10 good VMs Custom VMs - choose RAM and CPU, GPUs Live disk resize - also any size disk on any machine Billing - Sustained use discounts, preemptible VMs, per minute billing Live migrations - your VMs stay up longer Architecture - good fit for most existing systems

Google Cloud services run on it, too: Cloud SQL GKE Cloud Dataflow Cloud Dataproc Cloud Build and more…

Oh but wait a moment there, Katie. All this talk of different workload platforms, and you work at google…

Why oh why haven’t you mentioned kubernetes yet?!

Oh, but I have.

KNative is an open source project for creating building blocks on top of serverless

and knative directly powers cloud run.

and since Cloud run is managed, you can use all the power of kubernetes without having to directly administer it.

We’ve already talked about what’s a particularly good fit for each of the services. So you may be set. Your current needs might be a great fit for a specific one. Great!

It’s possible though, that you’re still not sure which of these fit for you

You could think of it in terms of two vectors of complexity.

If you aren’t sure and what a solid template to work from, and you just want to run a function, Cloud Functions If you need a bit more wiggle room, but you still want that sort of framework, App Engine

If you’re already used to containers, Cloud Run If you want more than just containers, Compute Engine.

But of course it’s more complex than that

But what is the right choice is going to depend on what choices you are able to make.

At the most complex end of the spectrum, you have the choice of ANYTHING in Compute engine. From the packages you have to the hardware you run on. As you go back, you have choices made for you. You don’t get to choose your hardware on any other service, but you still have the choice of language on Cloud Run Functions and App Engine, you have a limited choice, because it’s managed for you.

We can, however, think of this a different way.

Instead of “what am I limited by”, think about it this way:

What do I have to worry about.

If the choice is made for you, you can focus on other parts of the stack

Some of the “Choices” from earlier are just that. Choices. In a few cases once you make the choice, it’s managed for you.

You chose a certain type of hardware, we got you. You don’t have to do any physical server maintenance.

The language you chose for your Cloud Function? We’ll handle updates there. But you have little choice on which language.

The more choices, the more worry.

And again, the right choice is what is right for you.

And what you want to do.

Do one thing. Do many things. Do anything, do everything.

But, of course it’s not just that easy.

You could have more than one choice.

You could use them together!

You could have app engine which sends out longer running tasks to cloud functions

Or you could have some functionality on compute engine, complemented with other workloads

You could have, say: An Cloud Run website that takes uploaded images, sends them off into a queue with Cloud Pub/Sub, which then processes them in the vision API, and stores the results in Cloud SQL, which your app then shows the results of

Or you could have a function that uses the translation API based on BigQuery data

The possibilities are endless.

…or move up or down abstraction levels

You might find your container just needs to be triggered on a schedule, and so you move your functionality into Cloud functions

You might want more flexibility than what App Engine provides, so you migrate to a container You may find that you need more “ooph” in your function, and move to compute engine with custom hardware selections.

The right choice is what is right for you.

Hopefully you’ve gained some more clarity on what that just might be but if not, come have a chat, I might just be able to help.

Thank you!