A presentation at DevFest Dublin 2019 in in Dublin, Ireland by Katie McLaughlin
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!
There are many different ways to run your code these days. And the tradeoffs are different when you’re working with existing systems as opposed to designing an entirely new system.
Google Cloud Platform offers solid support for the full spectrum of compute models, whether you are using managed Google Cloud offerings or open-source technologies.
Come learn how to navigate the trade-offs and decide which models are the best fit for your systems as well as how the models map to Google Cloud services.
for free. You
can too.