Cloud Deployment Roadmap

Kubernetes is not the right answer for every team. It solves real problems at scale — but it introduces significant operational complexity and cost that can sink a small team or startup before they ship their first feature. This class maps the deployment landscape and provides a decision framework: given your team size, service count, and operational maturity, what is the right infrastructure choice right now, and how do you grow into the next tier?

1. The Spectrum of Managed Infrastructure

Cloud providers have progressively abstracted away infrastructure concerns. The tradeoff is always the same: less control, less operational burden.

flowchart LR
    vm["EC2 / VMs\n(full control,\nfull burden)"]
    ecs["ECS Fargate\n(containers,\nno nodes)"]
    eks["EKS / K8s\n(full orchestration,\nhigh ops)"]
    apprunner["App Runner\n(git → URL,\nzero config)"]
    paas["Railway / Fly.io\n(PaaS,\ndeveloper-first)"]
    lightsail["Lightsail\n(VPS-style,\nsimplest AWS)"]

    vm -->|"more managed →"| ecs
    ecs -->|"more managed →"| eks
    lightsail -->|"more managed →"| apprunner
    apprunner -->|"more managed →"| paas

2. Decision Roadmap by Team Size

flowchart TD
    A["Need custom domains + HTTPS?"]
    B["Railway / Render\n(free tier)"]
    C["Need a managed database?"]
    D["Fly.io"]
    E["AWS Lightsail Containers\nor AWS App Runner"]

    A -->|No| B
    A -->|Yes| C
    C -->|No| D
    C -->|Yes| E

flowchart TD
    A["Dedicated ops / platform engineer?"]
    B["ECS Fargate + ALB + RDS\n(serverless containers, no nodes)"]
    C["EKS (managed node groups)\nor ECS with more control"]

    A -->|No| B
    A -->|Yes| C

3. Platform Deep-Dives

AWS Lightsail Containers

Lightsail wraps containers in an abstraction that feels like Heroku: push an image, set environment variables, choose an instance size, get a public HTTPS endpoint. No VPCs, security groups, or IAM policies to configure.

$ aws lightsail create-container-service --service-name my-api \
    --power small --scale 1
$ aws lightsail create-container-service-deployment \
    --service-name my-api \
    --containers '{"my-api":{"image":"my-registry/my-api:latest","ports":{"8080":"HTTP"}}}' \
    --public-endpoint '{"containerName":"my-api","containerPort":8080}'

AWS App Runner

App Runner takes a container image (or a Git repository with a Dockerfile) and provisions a fully managed HTTPS endpoint that auto-scales from 0 to N instances with no server management.

version: 1.0
runtime: corretto17
build:
  commands:
    build:
      - mvn clean package -DskipTests
run:
  command: java -jar target/app.jar
  network:
    port: 8080
  env:
    - name: SPRING_PROFILES_ACTIVE
      value: prod

Railway

Railway provides the simplest developer experience in the ecosystem: connect a GitHub repo, Railway detects the language and framework, builds and deploys automatically.

What Railway provides out of the box:

• Automatic HTTPS with custom domains
• Built-in Postgres, Redis, and MongoDB as add-on services
• Deploy on push — no CI/CD pipeline needed initially
• Dashboard with logs, metrics, and environment variable management

Fly.io

Fly.io runs containers on edge nodes distributed worldwide, close to your users. A fly.toml config file defines the application; flyctl deploy handles building and deploying globally.

app = "my-order-service"
primary_region = "gru"  # São Paulo

[build]
  dockerfile = "Dockerfile"

[http_service]
  internal_port = 8080
  force_https = true

[env]
  SPRING_PROFILES_ACTIVE = "prod"

Strong suit: Fly.io places your containers in regions close to your users — deploying to gru (São Paulo) means ~15ms latency for most Brazilian users, and you can add iad (Virginia) or lhr (London) with a single flag to serve global traffic.

Weak suit: Stateful services are more complex than on AWS. Fly has Postgres support but it behaves differently from RDS — backup management, replication, and failover require more manual attention.

4. Kubernetes Alternatives for Orchestration

If you want Kubernetes features but not EKS cost or complexity, these distributions are worth knowing:

K3s — Lightweight Kubernetes (< 100 MB binary) by Rancher. Implements the same API as upstream Kubernetes. Ideal for on-premises deployments, edge devices, and development clusters. The Minikube environment used in this course is effectively a single-node K3s equivalent.

K0s — Zero-friction Kubernetes. A single binary with no external dependencies (no external etcd, no separate control plane binary). Common choice for CI/CD environments and on-premises production where K3s's Rancher tooling is unwanted.

Kind (Kubernetes in Docker) — Runs a full Kubernetes cluster inside Docker containers. The standard choice for local integration testing and validating Kubernetes manifests before pushing to a real cluster.

5. Cost Comparison

Monthly cost estimates for running three microservices (account, order, gateway) across deployment platforms. Costs vary significantly with traffic and instance size — these are representative baselines for moderate traffic.

6. Migration Path

flowchart TD
    start(["Idea / Prototype"])
    r["Railway / Fly.io\n(Day 1 — ship fast)"]
    app["AWS App Runner\n(Month 3 — AWS-native, stateless)"]
    ecs["AWS ECS Fargate\n(Year 1 — production, stateful)"]
    eks["AWS EKS\n(Year 2+ — scale, team grows)"]

    start --> r
    r -->|"Need AWS services\nor compliance"| app
    app -->|"Need stateful services,\nfine-grained control"| ecs
    ecs -->|"Multi-team, 50+ services,\nGitOps required"| eks

    style r fill:#4CAF50,color:#fff
    style app fill:#FF9800,color:#fff
    style ecs fill:#FF5722,color:#fff
    style eks fill:#F44336,color:#fff