Forem: Paul Craig

Quickstart: Continuous deployment to Google Cloud Run using Github Actions

Paul Craig — Thu, 12 Nov 2020 23:09:00 +0000

Preamble

If you’re a hobbyist developer and you want to host your fun app for next-to-free, you should definitely use Google Cloud Run. Once you set it up, Cloud Run is a dream to work with, but getting started can mean a lot of trial and error.

In this post, I will go step-by-step through setting up GitHub Actions to automatically deploy your cool app to Cloud Run.

Let’s get started.

Prerequisites

1. Install `gcloud` and do a local deployment

My initial idea was to write a “how to get started with Cloud Run” post, but it turns out the official Quickstart is excellent.

If you’re just starting out, follow Google’s Quickstart. It covers:

Installing and initializing the Google Cloud SDK
Creating your first project on Google Cloud Platform (GCP)
Building and pushing a container
Deploying your container to Cloud Run

By the end of the tutorial, you will have installed the gcloud command-line interface (CLI) and used it to deploy your first container to Cloud Run. This article picks up after the Quickstart material: it’s intended for anyone looking to add a bit more automation to their deployments.

2. Create a GitHub repository

You will also need a GitHub repository — you know, for the GitHub Actions to work. If you’re more of a “see the code” learner, I created an example repo — pcraig3/hello-cr — as part of writing the article. Feel free to clone or fork it.

Service accounts

When you run gcloud commands locally, you’re probably using your root account (ie, tied to your email address) because that’s the default account you create when you sign up to GCP. For local development, that’s fine: your root account is a superuser with lots of permissions, so you can do whatever you need to.

However, you should really avoid using your root account on other platforms. If your account password is ever stolen, an evildoer can take over your entire G-Cloud setup and use it to host crappy websites, run up a huge tab, or steal your data.

Instead, you should create a "service account": a separate account with limited permissions intended for specialized tasks. If your service account is compromised, the aforementioned evildoer can take down your Cloud Run app, but they won’t be able to mess up too much else.

Creating a service account using the Console

I’m most familiar with creating service accounts by logging in and clicking around, so that’s what I’m going to do here. If you’re smarter than me, you might prefer the command line, but all the same stuff will apply.

Log in to Google’s backend console
Using the drop-down selector in the header, pick the project where your Cloud Run app lives. (Mine is called hello-cr, it’ll be in a few screenshots)

Open the left-hand navigation menu and select "IAM & Admin" > "Service Accounts"

Click "+ Create service account": it will be in the contextual header near the top of the screen
The first section is titled "Service account details". Enter a "Service account name" (it will also be used for the id). Adding a description is optional. Click "Create" when you are finished.

Next, assign permissions to your new service account. This part was pretty tricky to figure out, but after a lot of trial and error, I found this combination works.
Add the following permissions:
- Cloud Run Admin
- Cloud Run Service Agent
- Cloud Build Service Agent
- Viewer
Click "Continue"

The final section ("Grant users access to this service account") is not relevant to this tutorial, so you can skip it.

Hooray! Now that you’ve created your service account, let’s make sure that everything works as expected by trying a local deployment as your new service account.

Authenticating on the command line as a service account

Show all of your service accounts with

gcloud iam service-accounts list

The account you just created should be listed there.

In order to run commands as the service account, we will need to download a service account key. The service account key is a JSON file containing credentials for the account, so be careful with it (eg, don’t commit it to your repository 😬).

Get the service account key with

gcloud iam service-accounts keys create ./NAME-OF-KEY-FILE.json --iam-account EMAIL-ADDRESS

Replace EMAIL-ADDRESS with the email for your service account. Also, you probably want to rename the .json file to something less shouty. If you store it in your app directory, make sure to add it to your .gitignore file.

Now that you have the key file, you can authenticate yourself as this service account.

Authenticate yourself with

gcloud auth activate-service-account --key-file=NAME-OF-KEY-FILE.json

This way, you can run commands as the service account.

You can see which account you are logged into with

gcloud auth list

You can change back to your original account at any time with

gcloud config set account YOUR-EMAIL-ADDRESS

Deploying your app with your service account

You should be able to build and deploy your app using your service account. To do so, follow the steps outlined in the Cloud Run Quickstart.

Build your container image using Cloud Build, by running the following command from the directory containing the Dockerfile:

gcloud builds submit --tag gcr.io/PROJECT-ID/helloworld

where PROJECT-ID is your GCP project ID.

Once built, let’s deploy.

Deploy using the following command:

gcloud run deploy --image gcr.io/PROJECT-ID/helloworld --platform managed

Replace PROJECT-ID with your GCP project ID. You can view your project ID by running the command gcloud config get-value project.

Nice! If the deploy succeeded, you know this service account has the permissions it needs to automate future deployments.

Setting up a "deploy" GitHub Action

Phew, now we’re on the home stretch.

Github Actions automate various parts of your development workflow: you can run tests, do linting, or trigger notifications based on certain conditions. You can also set up rules to deploy your app when your main branch is updated, which is what we want to do.

GitHub maintains a Marketplace of third-party Actions that we can use to plug into third-party services. Luckily for us, the folks at GCP have built a GitHub Action we can use to log in and run CLI commands: https://github.com/marketplace/actions/setup-gcloud-environment

GitHub Actions’ syntax is .yml-based, so let’s see what our deploy workflow will look like.

In the root directory of your app, create a file at .github/workflows/deploy.yml.

# .github/workflows/deploy.yml
name: Deploy to Cloud Run
on:
  push:
    branches:
      - main
env:
  PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
  RUN_REGION: us-east1
  SA_KEY_JSON: ${{ secrets.GCP_SA_KEY_JSON }}
jobs:
  deploy:
    name: Deploy to Cloud Run
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

      # Setup gcloud CLI
      - uses: GoogleCloudPlatform/github-actions/setup-gcloud@master
        with:
          version: "290.0.1"
          service_account_key: ${{ secrets.GCP_SA_KEY_JSON }}
          project_id: ${{ secrets.GCP_PROJECT_ID }}

      # Build and push image to Google Container Registry
      - name: Build
        run: gcloud builds submit --tag gcr.io/$PROJECT_ID/$PROJECT_ID:$GITHUB_SHA

      - name: Deploy
        run: gcloud run deploy $PROJECT_ID --image gcr.io/$PROJECT_ID/$PROJECT_ID:$GITHUB_SHA --platform managed --region $RUN_REGION

The Build and Deploy commands are pretty similar to those we just ran above, although there are a couple of differences. Let’s take a closer look at the build command.

gcloud builds submit --tag gcr.io/$PROJECT_ID/$PROJECT_ID:$GITHUB_SHA

The dollar-sign syntax (eg, $PROJECT_ID) represents an environment variable. All of our env vars are set at the top of the file, except $GITHUB_SHA, which is a default environment variable referencing the current commit hash
gcr.io/$PROJECT_ID/$PROJECT_ID: My project name is also the same as my app name (hello-cr). If your "project" name is different from your app name, you will need to add a new variable.
:$GITHUB_SHA: Adding a colon and a string is a way of tagging containers so we can distinguish between versions. In this case, the git SHA is appended, so that we can identify the current version of the app by referencing our commit history.

Setting up app secrets

If Actions are enabled for your repo, pushing your new deploy.yml file will attempt a deployment but it will fail because we need to add the secrets for our service account. The secrets we need to add are referred to in the env: section near the top of the file.

env:
  PROJECT_ID: ${{ secrets.GCP_PROJECT_ID }}
  RUN_REGION: us-east1
  SA_KEY_JSON: ${{ secrets.GCP_SA_KEY_JSON }}

The RUN_REGION is hard-coded, but we have to create the other two secrets. Github’s documentation for creating secrets is actually really good: you can add them under "Settings" > "Secrets" > "New secret".

GCP_PROJECT_ID: The project ID is just a string
GCP_SA_KEY_JSON: For the service account key, copy the entire JSON file into the textarea. It seems a bit weird but it works just fine.

Secrets are encrypted as soon as they are created, and there’s no way to reveal the original values once saved, so if you are adding sensitive values in the future, make sure to add them as secrets rather than accidentally committing them to your repo.

Once you’ve created your secrets and committed your deploy.yml file, your next push to the main branch will trigger an automated deployment. It usually takes a few minutes to deploy a new version of your application (depending mostly on how long it takes to build your container).

`pcraig3/hello-cr` on GitHub

While writing this post, I created an example repository using Google’s Node.JS sample application and added my workflow file to it. It’s super simple, and might help you out if you need an tangible example of these concepts. Feel free to clone, fork, or raise an issue if you have any questions.

pcraig3 / hello-cr

demo autodeployments to Cloud Run

hello-cr

Demo URL: https://hello-cr-3bjudp7n7q-ue.a.run.app/
Blog post: Quickstart: Continuous deployment to Google Cloud Run using Github Actions

Overview

This repository is a reference implementation for using Github Actions to continuously deploy a Node.JS application.

The deployment configuration is described in .github/workflows/deploy.yml. Whenever the main branch is updated, it will:

log in to GCP as a service account
build and push a container, tagging it with the git SHA
deploy the container

The app itself is based on the sample application used in Google's "Build and Deploy" Quickstart for Cloud Run.

The repo is MIT-licensed, so you are free to use or modify it however you like.

View on GitHub

All done!

You did it! Get yerself light lager and a pizza. 🍕

Cloud Run vs App Engine: a head-to-head comparison using facts and science

Paul Craig — Thu, 12 Nov 2020 22:28:07 +0000

For low-traffic applications, Cloud Run is dramatically cheaper than App Engine.

Abstract

I was hosting a small web app as a side-project and looking to spend less money. I started out using Heroku, then moved to Google’s Cloud Platform. Using rigorous methods and markdown tables, I performed a science-inspired “how much does this cost?” comparison between App Engine and Cloud Run. This study finds that Cloud Run is usually the best option, although if you ~~have money to burn~~ are a “price insensitive consumer,” then App Engine is a bit zippier.

Introduction

Imagine you have a side-project-type web app and you’re looking to host it on Google’s Cloud Platform (GCP) but you don’t want to spend too much ca$h. Which GCP service do 4 out of 5 scientists recommend? Let’s find out.

Background

My incredible journey went basically thus: I built a small express app for upcoming Canadian holidays and wanted cheap but usable hosting. Initially, I was using Heroku’s $7/month Hobby Plan because at the end of the ~~day~~ month, it’s only $7. (ie, that’s like 3 coffees: ‘a coffee’ being the base unit of diminutive purchases.)

Heroku was really easy to get going with, to integrate with GitHub Actions, and to ssh into when I needed to fiddle with something. But around month five, it dawned on me that it was going to cost $7/month for the rest of my life, so I started looking for other options.

Pivoting to Google Cloud Platform (GCP)

GCP was the cloud vendor with the most bonus cash on sign-up, so I figured that was a pretty neutral and unbiased reason to pick it. However, as a hapless first-time user, there are a lot of “solutions” to choose from.

It seems like you’re not a real cloud vendor unless you can bury newcomers under an avalanche of vaguely differentiated products with abstract geometrical logos, so a straightforward question like “where do I host a basic express app?” didn’t have an obvious answer.

Cutting through the media bias with facts and logic, I was able to narrow it down by following the research methodology of googling “google cloud how do I host express app”.

The two options that popped up were:

Both services will run apps and I had an app to run. Seemed perfect: they anticipated me like how I anticipated Canadians are looking for information about holidays.

Methodology

By signing up, I was granted 300 (!!) GCP bucks, and as a long-time government employee I knew this meant I had to find a creative way to spend it before the end of the fiscal year. Are you thinking what I’m thinking? Let’s run a research study!

(This is where the science comes in.)

My research question was “Should I use App Engine or Cloud Run to host my fun but unprofitable app?”, and to investigate that I opted for the immersion method where I would assume the role of a developer trying to host an app on Google Cloud.

Setup

As a precursor, I needed to set up my app on both services simultaneously. For the initial setup, I used the Quickstart material provided by Google at no cost to embedded researchers like me. (Both Quicks-start are pretty easy to follow once you have the gcloud command-line tools installed.)

Overview: App Engine (AE)

Node.js Quickstart for App Engine

On AE, my express app runs as a node process, like booting it up with npm start locally. AE is a traditional hosting platform: it runs continuously and serves requests as they come in. At the end of the month, you pay for the amount of time it was running, which is typically “the entire month”.

Overview: Cloud Run

“Build and Deploy” Quickstart for Cloud Run

Cloud Run runs containers, so for each release you have to build a container and push it to GCP. Unlike App Engine, Cloud Run only runs when requests come in, so you don’t pay for time spent idling.

Containerized apps are more portable but not always something you focus on during development. It’s worth noting that the Cloud Run Quickstart provides 9 example Dockerfiles depending on your language of choice. (I used the Node.js one as a basis.)

Simulating traffic

At this point in the study, I had 2 instances of my app running:

In App Engine: https://hols-ae.nn.r.appspot.com/
In Cloud Run: https://hols-hzlcxvebra-ue.a.run.app/

Because real applications have real traffic, I set up a ping service to send requests to each site exactly once every 47 minutes for the rest of time, just like how a Real Human Being™️ would browse.

Having completed my setup, it was time to let the experiment run its course, so I passed the time doing highly academic things like rinsing noobs at dominion.games.

Duration

2 months.

Findings

There were 2 principal findings of the study.

For a low-traffic application, Cloud Run is dramatically cheaper than App Engine
App Engine seems to respond slightly faster

1. Ongoing costs — Cloud Run wins ✅

	Cloud Run	App Engine	Heroku Hobby Plan
Monthly cost	$0.09	$11.29	$7.00

Wow.

App Engine runs 24/7 for the entire month whereas Cloud Run only runs when serving requests, and the difference is startling.

Previously, I had been paying $7 a month for Heroku’s Hobby Plan.

App Engine would cost me about 50% more
Cloud Run costs 99% less, oh my goodness

So basically it’s a blowout win for Cloud Run here.

2. Request latency — App Engine (usually) wins ✅

I also used some online speed test tools to measure the response times of my 2 instances. The results weren’t totally consistent, but App Engine generally responded more quickly.

Pingdom Speed test

(Results of 3 runs from São Paulo)

	Cloud Run	App Engine
Run 1	632 ms	471 ms
Run 2	485 ms	568 ms
Run 3	562 ms	470 ms
Average	559 ms	503 ms

Here we see App Engine responding on average 56 ms faster than Cloud Run (although in 1 case, Cloud Run was faster). The huge caveat here is that these times vary widely between runs, sometimes tripling or quadrupling depending on Who The F*ck Knows.

WebPageTest

(Results of 3 runs using “3G” download speed.)

	Cloud Run	App Engine
Run 1	5.217 s	5.010 s
Run 2	5.310 s	4.922 s
Run 3	5.353 s	5.089 s
Average	5.293 s	5.007 s

Again, keep in mind that these numbers shift around between runs.

Why is App Engine faster?

This isn’t totally clear to me, but I can speculate.

The one measurable difference I noticed is that that the total request size from Cloud Run was larger because it doesn’t gzip files by default.

	Cloud Run	App Engine
Page size	125.8 KB	119.4 KB

The Pingdom Speed Test for Cloud Run recommended I Compress components with gzip, and looking through the requests, my combined .js assets are indeed about 6 KB larger.

Downloading bigger files makes your site slower, but I don’t think that’s the whole story.

The big difference between the two services is that Cloud Run doesn’t run your container unless it’s getting requests. When a request comes in, it does 3 things:

boots up the container
serves the request
shuts down the container

It seems likely that the extra time needed to boot up the container adds to the total request time, leading to an average slower response time from Cloud Run.

Of course, you also save a lot of money doing it this way, so the tradeoff here is whether you care more about optimizing your speed or your cost.

Findings

For me, the findings are decisive. If you’re a hobbyist developer and you want to host your fun app for next-to-free, you should definitely use Google Cloud Run.

However, if money is no object, then you can pay exponentially more per month for a marginal speed boost on App Engine.

Google Cloud Run: the best hosting platform for dynamic apps

Paul Craig — Thu, 12 Nov 2020 22:07:20 +0000

Hello and welcome to my TED Talk.

Today I will be talking about a problem that all of us can relate to as developers with ultra-cool side projects in GitHub that have 0 stars: how to host lots of half-baked tiny apps for as cheaply as possible.

As a public-sphere-oriented side project, I built a small web app to show Canadians their next holiday. It’s a zippy little express app with a bunch of server-rendered pages and an embedded DB, and it’s open-source so anyone can use it (even non-Canadians).

express is a popular JavaScript framework that’s fun to use and lets devs like us build simple applications quickly, which is one of the joyful things about programming. But as cool as it is when your app works on http://localhost:3000, the point of websites is really that other people can see them, so you gotta find somewhere to host them. But not every app is gonna make you a ton of cash or be an ad vehicle — sometimes you just want to host a cutesy little app without having to come up with a business plan.

So what’s the best option for hosting a basic web app while paying as little as possible? Well, if this was a mystery novel, I would introduce 12 shifty characters right around now, but the answer is you should use Cloud Run.

Cloud Run is easy to set up and it’s basically free for low-volume apps.

However, anyone who’s ever had a Grade 3 math teacher knows it’s important to show your work, so I’m going to go over some of the options I looked at and how they stack up against each other.

Free hosting

In roughly chronological order, I started with free hosting options and then moved on to paid options. In general, free hosting comes with limitations that you can either accept or pay your way out of, so what you end up looking for is a good balance of uptime vs cost.

Totally free static hosting

eg, Github Pages or Surge

Static hosting services are super reliable and super free (😻), but the major caveat here is that they restrict you to static sites (or in-browser JS, to split a hair). Does this work for you? Maybe, if you’re using a “compiles to static” framework like Gatsby or Next.js (both Very Fun™️ in their own right). But not if you have picked up a more traditional MVC framework, like Flask, Rails, Laravel, or, in my case, express.

If all you need is a totally static site — a bunch of HTML files — or you’re building a Single-Page App that offloads the logic onto a web browser, then you should probably just use a static hosting service and call it a day. (eg, My personal website is running on GitHub Pages).

However, if you’re writing server-side logic to listen for requests and build your pages, you might have leveled-up and out of this category.

Totally free dynamic app hosting

eg, Heroku or Glitch

Usually you have to pay for server uptime, but a few prominent companies have a category called “the free tier”. PaaS products like Heroku or Glitch offer this: they will host your app for free (!!) but — like Jurassic Park after Dennis Nedry leaves — will shut it down after [x] minutes without traffic. Once your app is down, the next request that comes in can take 20 or 30 seconds to load because it needs to spin up a whole server for the first request. For not-serious prototypes or little “Hello World!” tutorial apps, this is probably fine because your entire audience is your roommate and your mom. But once you want a site that will actually be usable, you come to two realizations:

this is untenable, and
more like “the free tear 😢” because it’s what happens to your eyes after staring at 20 seconds of a white page

Paid hosting

Maybe it’s time to bite the bullet and pay to host. Okay fine, I reason to myself, I am not bankrupt. Truth be told, I regularly pay money for things (eg, groceries and other necessities). But I’m also not Geoff Bezos, who makes more money in the time it takes for him to read this article than you or I will make in a year. So let’s see what’s on offer, but let’s also try to be cost-conscious.

Paid server hosting

eg, Upgrading Heroku/Glitch, using Digital Ocean, or GoDaddy

Traditional server hosting is a well-trod path here, with many commodity services competing to sell you uptime. Whether you want to upgrade your Heroku or Glitch plan, squeeze out a Digital Ocean droplet or poach yourself a big ol’ HostGator, the principle is pretty much the same. You pay a fixed rate for permanent server uptime and then your app runs all the time until either you die or you run out of money. If you’re looking for the cheap plans, they’re usually around $5-9 (USD!!) a month.

Sure, not like it’s the end of the world, but I can also buy Netflix for $10/month (CAD) and get like a million shows I’ll never watch. So it would be good if there were some cheaper options here, because $10/month quickly adds up to $9,360.00 (79 years being the average human lifespan).

Splitting the difference; axing our bills

The reason we’re getting such crap experiences with the free tier is that dynamic sites need a server to do some computation before they return pages. To use my Canadian holidays site as an example, I look up how many days until the next holiday, so I need to check the current date every time a request comes in.

Building a page itself is pretty quick, but booting up a hibernating server takes a while. For the fastest responses, we end up keeping the engine idling 24/7. This way, our server is always ready to respond to incoming requests, but at the cost of a lot of uptime we don’t need.

So how do we split the difference? If we could find a way to pay only for the time that we are serving web traffic (💡) then we can launch fleets of rarely-visited websites for next-to-free. Sounds simple enough, but how does it work in practice?

Paid “serverless” hosting

eg, AWS Lambda or Google Cloud Functions

Probably you’ve heard of serverless functions, aka Lambdas, aka Functions as a Service (FaaS): the idea is you run individual functions rather than a big fat web framework. “Server-less” makes more sense as two words in this context, because we need less of a server than all of one. What if, instead of our web server listening 24 hours a day for requests, we handled each request with a function that only runs when requests come in, and we pay only for the time it took to run those functions?

What we’re talking about here is function invocations, which, for small projects, end up being cheap as chips. At 10k requests a month, you’re looking at an estimate of ~21 cents. There’re a lot of options in this space: the Big Three (AWS, Azure, GCP) all offer FaaS services, as well as more upstart-y platforms like Vercel or Netlify.

But wait! Is this going to work with express or Rails or whatever? Erm, there are options I suppose (eg, serverless express). But out of the box, no.

To be clear, if this works for you, then this is a great option. For low-volume sites, you are looking at pennies a month. But if you already have a conventional web app, it probably means a big, fat rewrite: a thing I was definitely not interested in, and I would posit that you shouldn’t be either.

Containerized serverless (aka, the Holy Grail)

at long last, Cloud Run

If you read the title of this post or the earlier-mentioned ‘TL;DR’, you might have guessed this, but for super unobservant people, the moment you have been waiting for is here.

🥁🥁🥁

✨ Cloud Run ✨ is the gold at the end of this rainbow. Instead of paying for the time it takes to run function invocations, Cloud Run charges you for time spent running your app as a container — but the trick is that the container only runs when requests come in. Unlike traditional server-hosting, the time to boot up a container is dramatically less than it takes to spin up a server. You don’t have to provision a VM or download anything: containers bundle together everything they need at build time. Building a container can take a while (sometimes several minutes), but starting them up is pretty zippy.

It’s a really neat way to slice the Gordian knot here. As we’ve seen, the other options are:

be static
deal with downtime
pay a lot for uptime you don’t need
rewrite your whole damn app

With Cloud Run, get the best of both worlds: you get the pay-per-use model of serverless functions without overly constraining how you build your app. And since we’re talking about low-volume side projects presumably without much in the way of growth hacking, most of the time you’re not paying anything.

You know the phrase, “make money while you sleep”? Well, this is similar: only it’s more like “most of the time you’re asleep, you’re not paying for Cloud Run.” And Cloud Run has a free tier too, which means if you’re really unpopular, hosting is free!

Okay, I’m interested. What’s the catch?

Glad you asked! Basically, the catch is you need a Dockerfile. Unlike with FaaS platforms, you don’t have to carve up your app like an LA plastic surgeon, but you do need to be able to run it as a container, which isn’t always part of the “Hello World!” tutorial you started with.

The good news is that if you’re using a pretty established framework, examples abound. Google’s excellent “Build and Deploy” Quickstart tutorial includes sample Dockerfiles for 8 major programming languages. The JS one is 6 lines of code but I am a little more l33t than they expected so I got mine up to 15.

If you need an intro to Docker, check out this excellent guide by Robert Cooper.

Wrap up

If you’re still not convinced and you want to do more research, then that’s fine too. A good place to start is at the beginning of this article. Otherwise, you should give it a shot! Here are a few more resources to help you on your way.

Hit up Google’s “Build and Deploy” Quickstart for Cloud Run
Learn how much cheaper it is to use Cloud Run than App Engine
Deploy automatically to Cloud Run using Github Actions

Thanks for reading! Happy devving!

Forem: Paul Craig

Quickstart: Continuous deployment to Google Cloud Run using Github Actions

Preamble

Prerequisites

1. Install gcloud and do a local deployment

2. Create a GitHub repository

Service accounts

Creating a service account using the Console

Authenticating on the command line as a service account

Deploying your app with your service account

Setting up a "deploy" GitHub Action

Setting up app secrets

pcraig3/hello-cr on GitHub

pcraig3 / hello-cr

demo autodeployments to Cloud Run

hello-cr

Overview

All done!

Cloud Run vs App Engine: a head-to-head comparison using facts and science

Abstract

Introduction

Background

Pivoting to Google Cloud Platform (GCP)

Methodology

Setup

Overview: App Engine (AE)

Overview: Cloud Run

Simulating traffic

Duration

Findings

1. Ongoing costs — Cloud Run wins ✅

2. Request latency — App Engine (usually) wins ✅

Pingdom Speed test

WebPageTest

Why is App Engine faster?

Findings

Further reading

Google Cloud Run: the best hosting platform for dynamic apps

Free hosting

Totally free static hosting

eg, Github Pages or Surge

Totally free dynamic app hosting

eg, Heroku or Glitch

Paid hosting

Paid server hosting

eg, Upgrading Heroku/Glitch, using Digital Ocean, or GoDaddy

Splitting the difference; axing our bills

Paid “serverless” hosting

eg, AWS Lambda or Google Cloud Functions

Containerized serverless (aka, the Holy Grail)

at long last, Cloud Run

Okay, I’m interested. What’s the catch?

Wrap up

1. Install `gcloud` and do a local deployment

`pcraig3/hello-cr` on GitHub