Paradox's EKS Migration
summary
Paradox moves from static EC2 to a containerized Amazon EKS platform over about 15 months, starting with a 6‑month cluster build, a 3‑month canary, then full rollout; a four‑to‑five person ops team scales to handle 10× load while costs rise only 2×. Reliability jumps from 99.95% to 99.999%. Key choices: Amazon EKS with Helm charts for uniform deploys, Linkerd for mTLS and Keda for queue‑driven autoscaling, later adding Cast AI for multi‑node types and spot optimization and Argo to replace Jenkins.
AI-written summary · about
chapters (10)
- 0:00Introduction to Paradox
- 1:32Problems with static infrastructure
- 5:52Amazon's role in EKS migration
- 6:52Containerizing applications for EKS
- 9:17Solving resource waste and scaling
- 10:43Project timeline and deployment
- 12:28Reliability and cost improvements
- 13:25Phase two optimizations
- 15:32Moving from Jenkins to Argo
- 17:17Q&A session
related talks
49mHardware to AWS, EC2 to EKS: Two Years, Two Epic Migrations
36mMigrating from kOps to EKS with Minimal Developer Involvement
43mReplatform to Amazon EKS
46mMigrating from VMs to K8s
09mHow migrating from ECS to EKS supercharged our infrastructure
11mAmazon EKS Roadmap
29mAmazon Elastic Container Service for Kubernetes (EKS): A case study - M. Re Ferre' and G. Carabelli
17mKeynote: Kubernetes: Lessons from the Trenches