Skip to main content

Choosing "Small Enough" Cloud

What This Concept Is​

"Small enough" cloud means the simplest real platform that teaches you production deployment without punishing your wallet or your calendar. For a capstone defended by one engineer, that is almost never the full AWS/Azure/GCP service menu. It is a narrower slice chosen on purpose and defended on paper.

The question is not "which cloud?" It is "which layer of abstraction on which cloud gets me to a real, reviewable deploy in the fewest weekends?" That layer determines your Terraform surface, your pipeline complexity, your monthly bill, and how many services you can debug when the first outage arrives at 11 p.m.

Three serious options for a capstone:

  • Managed PaaS (Fly.io, Render, Railway, Heroku, Azure App Service, Google Cloud Run with a thin IaC wrapper). You push code or a container; the platform owns runtime, TLS, autoscaling, base OS patches, and metrics.
  • Container platform with exposed knobs (ECS Fargate, Cloud Run with full Terraform, AWS App Runner, Azure Container Apps). You build the image; the platform runs it; you still pick VPC, IAM, autoscaling, logging destinations.
  • Classic IaaS + managed data (EC2/VM + RDS/Cloud SQL, or a Linode/Hetzner box + managed Postgres). You own the OS and the reverse proxy, but lean on the cloud for stateful data services.

This module is not against any of them; it is against picking a platform you cannot afford, debug alone, or explain in a 15-minute defense.

Why It Matters Here (In the Capstone)​

Every capstone decision downstream -- Terraform scope, pipeline shape, rollback time, monthly cost, reviewer legibility -- is constrained by this first choice. Pick the wrong platform and the next 12 concepts get harder for no learning benefit. The capstone is evaluated on evidence of a deployed system, not on matching a trendy reference architecture diagram you screenshotted from a conference talk.

There is also a time asymmetry working against you. A platform that requires a week of VPC and IAM setup before the first deploy steals a week you needed for features, migrations, and rollback rehearsal. The same week on Cloud Run or Fly.io gives you a deployed service with OIDC already working, leaving time to go deeper where the capstone narrative actually rewards depth.

Concrete Example(s)​

A capstone that is a Go API + Postgres + a static frontend can land on any of the three options. Here is how the picking rubric plays out across cost, control, and complexity:

OptionEst. cost/mo (1 env)ControlComplexityGood fit when
Fly.io + Fly Postgres$5-15LowLowYou want to spend time on the product, not on IAM
Cloud Run + Cloud SQL$20-60MediumMediumYou want managed containers and realistic cloud IAM evidence
ECS Fargate + RDS + ALB + VPC$80-150HighHighThe capstone narrative is cloud engineering; you have a free-tier credit

A deploy command from each world, for calibration:

# Fly.io: one file, one command.
fly deploy --config fly.toml

# Cloud Run + Terraform.
terraform apply -auto-approve \
  -var image=gcr.io/my-proj/api:$(git rev-parse HEAD)

# ECS Fargate: service update after image push.
aws ecs update-service \
  --cluster capstone --service api \
  --task-definition capstone-api:42 --force-new-deployment

Pick the row that matches the story you want to defend, not the one that sounds most impressive on paper.

Common Confusion / Misconceptions​

  • "I should pick the big three because they look better on my portfolio." A reviewer who has shipped anything non-trivial sees through an EKS cluster running one pod with no autoscaling, no network policy, and no metrics. A tight Cloud Run or Fly deploy with real OIDC, real IaC, and a real rollback rehearsal is stronger evidence than a half-configured Kubernetes setup.
  • "Serverless is always cheapest." Only at low, bursty traffic. Pin a Cloud Run service to min-instances=1 and it costs roughly as much as a small VM. Run a Lambda hot loop and DynamoDB writes add up quickly. Use the vendor's own pricing calculator, not a blog post, to estimate.
  • "Pick the cloud my future employer uses." Your future employer runs the same Terraform, the same OIDC, the same containers. Cloud literacy transfers. Platform-specific trivia does not rescue a capstone with no rollback rehearsal and no runbook.
  • "Free tier means free." Every cloud has egress, storage, and NAT gateway charges that the free tier does not cover. Budget them up front or set a hard billing alert before you run apply.

How To Use It (In Your Capstone)​

Apply the picking rubric in writing:

  1. List three candidate platforms, at least one from each of the three categories above.
  2. Estimate monthly cost for one env at your expected traffic using the vendor's pricing calculator (not a blog post, not a Reddit thread).
  3. Score each on control (1-3) and complexity (1-3), where complexity is "how many moving parts I personally maintain."
  4. Multiply complexity by your remaining capstone weeks; if the product is larger than half your budget, downgrade.
  5. Check the "boring default" test: widely used, older than two years, used by one company you can name that ships real traffic.
  6. Write a one-paragraph decision with an explicit escape hatch ("if this platform becomes unaffordable I would move to ___ in ~___ hours").
  7. Commit the decision into library/raw/decisions/001-platform.md before any IaC or pipeline work begins.

The "Boring Default" Move​

When the rubric is close, pick the boringest option and keep moving. "Boring" here means:

  • widely used enough that search results cover your error messages
  • older than two years as a product
  • used by at least one company you can name that ships real traffic
  • documented in the vendor's official docs, not just blog posts

Exotic choices (a brand-new PaaS, an unreleased serverless framework, a regional cloud you have never touched) are legitimate for hobby projects. They are not for a capstone whose grade depends on a reviewer being able to run terraform apply and see it work.

Escape Hatch Rule​

Every platform choice should have a written escape hatch: "if this platform becomes unaffordable, unreliable, or acquired-and-shut-down, I would move to ___ in roughly ___ hours." Without the escape hatch, you are locked in without knowing it. The hatch should be plausible, not heroic -- "move to Fly.io with Docker image and a day's config work" is real; "refactor to Kubernetes over a weekend" is not.

One Defense-Ready Paragraph​

When a reviewer asks "why this platform?", you should be able to deliver something like:

I picked Cloud Run because my topology is API + managed Postgres + static frontend, and Cloud Run gives me per-request billing, zero infra to patch, and native OIDC from GitHub Actions for a monthly cost of ~$35 at my expected load. I considered AWS ECS Fargate but rejected it on complexity (VPC, ALB, IAM) for a solo operator, and Fly.io on resume-legibility (less recognizable to reviewers). If Cloud Run became unaffordable I would move to Fly.io with roughly a day's work.

Three platforms, one decision, one escape hatch, all in five sentences. If you cannot produce that paragraph, you have not finished this concept.

See also (integrative)​

Check Yourself​

  1. What is your monthly cost at expected load, and which pricing calculator did you use?
  2. Can you list every runtime service you now own (not the cloud's responsibility)?
  3. Can you redeploy this capstone if the vendor has an outage lasting two hours?
  4. What is your escape hatch, in one sentence, and in roughly how many hours?
  5. Which of the "big three" have you rejected, and on what specific criterion?
  6. If your platform raises prices 2x tomorrow, does the capstone still fit your monthly cap?

Mini Drill or Application (Capstone-scoped)​

  1. 20-minute ADR. Draft library/raw/decisions/001-platform.md with one-sentence scope, three candidate platforms, the 3x3 rubric table, the decision, two explicit "we accept that" tradeoffs, and the escape hatch.
  2. Price probe. Use each candidate vendor's own calculator to price one env at 10 req/s avg and 100 req/s peak, with one 10 GB database. Record the three numbers. If any is within 2x, cost is not the deciding factor; pick on complexity.
  3. Defense paragraph. Write the five-sentence answer you will give when a reviewer asks "why this platform?" -- three platforms, one decision, one escape hatch. If you cannot produce that paragraph without notes, the concept is not yet internalized.

Source Backbone​

Capstone deployment applies cloud, delivery, and operations material. These books are the source backbone for the delivery decisions.