weastel

Writing / scaling-ec2-to-kubernetes

Scaling stories — journey from EC2 to Kubernetes

Originally part of Newton School’s DevOps series on Medium.

After becoming champion of the Alola Region, Ash Ketchum had an idea: teach the basics of Pokémon training so every trainer could chase their dream of becoming Champion. With Brock Harrison, he founded Oak School — an ed-tech platform for Pokémon fundamentals.

Ash and Brock brought on Misty Williams as tech founder.

Misty and her sister Daisy built a monolithic app — backend and frontend in one codebase. Monolith first made sense: ship fast, lots of features, endless todos. They iterated quickly. Then it was time to launch in the Alola region and show Oak School to the world.

Two EC2 boxes and an RDS

Misty spun up two EC2 instances and an RDS database, deploying backend and frontend manually. She registered oakschool.co for the UI and api.oakschool.co for the API, each pointed at its instance.

(Architecture diagrams were in the original Medium post.)

Viral growth and vertical scaling

Oak School went viral within three months. Daily active users went from 10 → 1,000; 100 instructors ran courses. The site slowed down — students and instructors complained.

Misty scaled the backend vertically: 8 GiB → 32 GiB RAM, 4 → 16 vCPUs. That held until traffic climbed toward 5,000 users.

Horizontal scaling and the load balancer

Research pointed to horizontal scale: multiple API instances behind a load balancer, same code, shared database. Add capacity by adding instances; Amazon’s load balancer spreads traffic so no single box carries everything.

That fixed elasticity — but you can’t SSH and deploy by hand across a fleet and expect consistency.

Docker and “works on my machine”

Containers package code with dependencies. Docker gave the same artifact on every instance and killed the classic “works on my machine” gap.

Deploy pain remained: pushing images to N machines still hurt.

Jenkins and continuous delivery

Jenkins automated build and deploy: build a Docker image, roll it to the right EC2 hosts. A continuous delivery (CD) pipeline tied scaling to repeatable releases.

(Pipeline diagram in the original post.)

Team update: 2 → 30 people — frontend, backend, ML, data science, DevOps, and more.

Microservices at the edges

Roadmap items — virtual Pokémon battles, combat analysis, and similar — couldn’t all live in one monolith. Some workloads needed GPUs for simulation; cost and ownership differed by feature. Misty kept the monolith but added helper microservices the core could call for specialized work.

More services on more machines meant someone had to keep desired state honest when networks or instances failed.

Kubernetes

Kubernetes — Google’s orchestrator — took a declarative desired state (deployments as code) and reconciled reality: scale up or down, replace failed pods, smooth rollouts. It addressed deployment, scaling, and day-two ops in one place.

TL;DR: Everyone sleeps peacefully — Misty included, with her Togepi.


That was the overview for our DevOps series. Follow-on posts dug into Kubernetes internals and running cloud-native apps in production.


Originally published on Medium — Newton School (Jan 4, 2023).

← All posts