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?

The previous class, Service Models, gave the vocabulary (IaaS, PaaS, CaaS, DBaaS). This class turns it into concrete platforms, prices and a migration path for the store: gateway, account, order, Postgres.

Slides

Click the slides and use ← → to move through them; F goes full screen and P opens the presenter view, with the notes. Open the slides in a new tab

1. The Spectrum of Managed Infrastructure

Cloud providers have progressively abstracted away infrastructure concerns. The tradeoff is always the same: the more the platform manages, the less control you have and the less operational burden you carry. The diagram reads from the most managed option on the left to the most control (and most work) on the right:

flowchart LR
    subgraph dx ["Developer-experience path"]
        railway["Railway / Render<br/>(git push → URL)"] -->|"more control, more ops"| fly["Fly.io<br/>(Dockerfile, regions)"]
        fly -->|"more control, more ops"| lightsail["Lightsail<br/>(simple VM or containers)"]
    end
    subgraph aws ["AWS-native path"]
        express["ECS Express Mode<br/>(image → HTTPS URL)"] -->|"more control, more ops"| ecs["ECS Fargate<br/>(task definitions, no nodes)"]
        ecs -->|"more control, more ops"| eks["EKS<br/>(full Kubernetes)"]
        eks -->|"more control, more ops"| vm["EC2 VMs<br/>(you run everything)"]
    end

Section 5 estimates the monthly cost of each one for the same workload.

2. Decision Roadmap by Team Size

flowchart TD
    A{"Must it run on AWS?<br/>(credits, compliance)"}
    A -->|No| B{"Users spread over<br/>several continents?"}
    B -->|No| C["Railway / Render<br/>(git push → URL)"]
    B -->|Yes| D["Fly.io<br/>(multi-region machines)"]
    A -->|Yes| E{"One VM or a few<br/>containers is enough?"}
    E -->|Yes| F["Lightsail<br/>(fixed monthly price)"]
    E -->|No| G["ECS Express Mode<br/>(Fargate + ALB)"]

flowchart TD
    A{"Dedicated ops /<br/>platform engineer?"}
    B["ECS Fargate + ALB + RDS<br/>(serverless containers, no nodes)"]
    C["EKS (managed node groups)<br/>or 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 a node size (power) and a number of nodes (scale), get a public HTTPS endpoint. No VPCs, security groups, or IAM policies to configure, and a fixed monthly price per node⁴.

$ 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}'

The image must come from a public registry (e.g., Docker Hub) or be pushed to the service's own registry with aws lightsail push-container-image; Lightsail then refers to it as :my-api.<label>.<version>.

Amazon ECS Express Mode (successor to App Runner)

ECS Express Mode (launched November 2025³) keeps App Runner's "image in, HTTPS URL out" simplicity, but everything it creates is an ordinary ECS resource in your own account. With one call you provide a container image and two IAM roles; ECS provisions a Fargate service, an Application Load Balancer with HTTPS, auto scaling, security groups and a default URL². There is no extra charge for Express Mode — you pay for the Fargate tasks, the load balancer and the rest of the underlying resources.

aws ecs create-express-gateway-service \
    --service-name order-service \
    --execution-role-arn arn:aws:iam::123456789012:role/ecsTaskExecutionRole \
    --infrastructure-role-arn arn:aws:iam::123456789012:role/ecsInfrastructureRoleForExpressServices \
    --primary-container '{
        "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/order:1.0",
        "containerPort": 8080,
        "environment": [{"name": "SPRING_PROFILES_ACTIVE", "value": "prod"}]
    }' \
    --health-check-path "/actuator/health" \
    --scaling-target '{"minTaskCount":1,"maxTaskCount":4}'

• Image only. Unlike App Runner, Express Mode does not build from source: your CI must build and push the image to ECR — exactly what the Jenkins pipeline of Hands-on 4 does.
• Shared load balancer. Several Express services (up to 25) can share one ALB, with rule-based routing keeping them isolated³ — useful for the store, which has several small services.
• No dead end. Because the ALB, target groups and task definitions are visible in your account, "graduating" to full ECS Fargate means editing those resources, not migrating.

Railway

Railway provides the simplest developer experience in the ecosystem: connect a GitHub repo, Railway detects the language and framework, builds and deploys automatically. Billing is usage-based (per vCPU and GB of memory actually used, per second), on top of a small monthly plan fee that counts as usage credit⁶.

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
• Private networking between services of the same project (<service>.railway.internal), so only the gateway needs a public domain
• Dashboard with logs, metrics, and environment variable management

Fly.io

Fly.io runs containers as lightweight VMs (Machines) on servers in regions around the world, close to your users. A fly.toml config file defines the application; fly deploy builds and deploys it⁷.

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. A user in São Paulo reaches gru in a few milliseconds, against more than 100 ms of round trip to a US East region. Adding regions is one command — fly scale count 3 --region gru,iad,lhr — and Fly's Anycast routing sends each user to the nearest Machine. Apps in the same organisation talk over a private network (<app>.internal).

Weak suit: Stateful services are more complex than on AWS. The classic Fly Postgres is an app that you operate yourself (backups, failover, upgrades); the newer Managed Postgres removes that work but starts at a higher fixed price than the compute of a small app⁷. There is no free tier for new organisations, only a short trial.

4. Kubernetes Alternatives for Orchestration

If you want Kubernetes features but not EKS cost or complexity, these distributions are worth knowing. All of them expose the same Kubernetes API, so the manifests from Hands-on 5 run unchanged:

Minikube — Runs upstream Kubernetes in a VM or container on your laptop, single node by default, with add-ons (ingress, dashboard, metrics-server). It is the environment of Hands-on 5 and the MiniKube exercise — built for learning and local development, not for production.

K3s — Lightweight, CNCF-certified Kubernetes (single binary under 100 MB) originally from Rancher, now SUSE⁸. It implements the same API as upstream Kubernetes, uses SQLite instead of etcd by default on a single server (embedded etcd for HA), and bundles Traefik as ingress. Ideal for on-premises deployments, edge devices, and small production clusters on one or a few VMs.

K0s — "Zero-friction" Kubernetes from Mirantis. A single binary with no host dependencies beyond the kernel; it bundles and manages its own control-plane components (etcd, or kine with SQLite/MySQL/Postgres). Common choice for on-premises production where a vanilla, minimal distribution is preferred.

Kind (Kubernetes in Docker) — Runs each Kubernetes node as a Docker container. Created to test Kubernetes itself, it is now the standard choice for integration tests in CI and for validating manifests before pushing to a real cluster.

5. Cost Comparison

How much does it cost to run the store's three microservices (gateway, account, order) plus one small Postgres database on each platform? The table and the chart below are generated from one cost model: a list of unit prices and, for each platform, a low and a high configuration built from those prices. Change a price in the code and both update together.

Reading the estimate: where the money goes

Look at the assumes columns rather than the totals. At this scale the bill is dominated by fixed costs that exist even with zero traffic:

The compute for three small Spring Boot services is often the smallest line. This is why a platform with a fixed control-plane fee loses at three services and wins at fifty: the fixed cost is spread across more workloads. It is also why "one EKS cluster per environment" (dev, staging, prod) triples the fixed part of the bill.

6. Example: the store at each stage

The same four components, deployed on the three platforms of the migration path below:

The application code does not change across the three columns: the 12-factor style (configuration in environment variables, stateless services, state in Postgres) is what makes each migration a deployment exercise rather than a rewrite.

7. Migration Path

flowchart TD
    start(["Idea / Prototype"])
    r["Railway / Fly.io<br/>(Day 1 — ship fast)"]
    ex["ECS Express Mode<br/>(Month 3 — AWS-native, stateless)"]
    ecs["ECS Fargate, full control<br/>(Year 1 — production)"]
    eks["AWS EKS<br/>(Year 2+ — scale, team grows)"]

    start --> r
    r -->|"Need AWS services<br/>or compliance"| ex
    ex -->|"Need sidecars, private<br/>services, fine control"| ecs
    ecs -->|"Multi-team, 50+ services,<br/>GitOps required"| eks

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

Note that the step from Express Mode to "full" ECS Fargate is not a migration at all: Express Mode is ECS, so you start editing the task definitions, load balancer rules and networking it created.

Key takeaways

• Kubernetes is not the default: pick the platform by team size, service count and operational maturity.
• There are two paths: developer experience (Railway/Render → Fly.io → Lightsail) and AWS-native (ECS Express Mode → ECS Fargate → EKS → raw EC2), each trading simplicity for control.
• At small scale, fixed costs (EKS control plane ~\(73, ALB ~\)30, NAT ~$33) dominate the bill; state every estimate with its region, date and sizing.
• Small teams: Railway, Render, Fly.io, Lightsail or ECS Express Mode. Medium teams: ECS Fargate. Large teams: EKS with Karpenter/Auto Mode, ArgoCD, the Load Balancer Controller and External Secrets.
• K3s, K0s, Kind and Minikube give the Kubernetes API without EKS — and hand you the control plane's operations.
• Migrate on concrete pain, keep the application portable, and never assume a managed product will exist forever (App Runner).

Connections

• Service Models — the IaaS / PaaS / CaaS vocabulary used here.
• Containerization — the images every platform in this class deploys.
• Hands-on 4 — DevOps — the pipeline that builds and pushes the images.
• Hands-on 5 — Orchestration and the MiniKube exercise — the Kubernetes API that EKS, K3s and Kind all expose.
• Reliability — what you lose when the whole store runs on a single VM.
• Project: AWS, EKS and Costs & PaaS.