Serverless Expeditions — selected guide
Infrastructure as code with Terraform and 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 10 of 14
Long deployment checklists are easy to follow inconsistently. This April 2021 introduction explains infrastructure as code: describing the resources a deployment needs in a machine-readable Terraform configuration, so teams can repeat the setup without manually recreating every step.
Key points
- Describe the result instead of every command: The comparison starts with a
gcloudcommand that fails when repeated because the bucket already exists. Terraform instead declares the desired result—a bucket exists—and checks whether changes are needed. The example does not explain how Terraform tracks managed resources, so it should not be read as showing automatic adoption of any existing bucket 01:03–03:13(opens in a new tab). - One configuration can describe intentional differences: HashiCorp Configuration Language (HCL) supports variables such as a project ID or a smaller database size for testing. Terraform also works out dependencies: a bucket needed by a service must exist first, while independent resources can be created in parallel 02:07–04:16(opens in a new tab).
- Build the application before deploying its infrastructure: In the workflow described, Terraform expects the container or compiled code to exist already. Teams can run it after their build process or include it as a step in Cloud Build, keeping the infrastructure configuration alongside application code in source control 03:13–05:22(opens in a new tab).
Full video: https://www.youtube.com/watch?v=Ce93fpQrKCk(opens in a new tab)