Serverless Expeditions — selected guide
Cloud Functions vs. Cloud Run
Fourteen episodes on service choice, architecture, scaling, state, security, operations, and delivery
Serverless design and operations through concrete examples: choosing a runtime, ordering events, managing relational state, undoing failed workflows, protecting secrets, and deploying changes safely. The selection also includes two AI-agent examples covering tools and database access.
In this collection Browse 14 summaries 1 of 14
Martin and Grant compare two ways to run a fictional wildlife-camera system: a function that reacts to uploaded images, and a containerized API that serves animal sightings to web and mobile apps. Their October 2020 comparison explains the choices available then, rather than today's product boundary.
Key points
- An event handler fits the image pipeline shown: A finalized Cloud Storage upload invokes a function, which calls the Vision API, filters detected labels, and writes selected sightings to Firestore 01:04–06:22(opens in a new tab). The presenters favor a function because the 2020 platform connected that storage event with less setup.
- A container fits the API requirements shown: The team wants container packaging, a custom domain, and the ability to send only some requests to a new version. The presenters choose Cloud Run and configure an Express HTTP server themselves. Its endpoint looks up an animal in Firestore and returns a sighting or a not-found response 08:30–11:39(opens in a new tab).
- Traffic splitting limits exposure to a new version: The presenters deploy the demo API with unauthenticated access, then send 10% of requests to its newest revision and the rest to the previous version. This illustrates a canary release: trying new code on a fraction of traffic before exposing everyone to it 12:45–18:02(opens in a new tab).
Full video: https://www.youtube.com/watch?v=zRjOSxTpC3A(opens in a new tab)