GoBubble migrates 21 workloads from GCP to Amazon EKS with zero downtime

GoBubble arrived from GCP with a startup’s budget and an AI platform’s compute appetite: GPU inference for the moderation models, a general-purpose service fleet around it, and a relational tier underneath. Pinning workloads to a single instance family — or a single CPU architecture — would have locked in whatever prices those SKUs happened to carry. The platform needed to be architecture-flexible from day one, so that cheaper silicon (Spot capacity, Arm64/Graviton families, newer generations) could be adopted by scheduling decision rather than re-engineering project.

VeUP made flexibility the default at every layer. Container images are built multi-arch and stored in Amazon ECR, so the same workload runs on x86 or Arm64 without a separate build path — which is what let the general-purpose fleet land on Graviton-based m8g instances for price-performance from day one. Scaling runs at both levels: the Horizontal Pod Autoscaler sizes the workloads and the Cluster Autoscaler grows and shrinks the node fleet beneath them, with IRSA scoping workload identity per service. The GPU inference fleet scales independently on its own g6 node groups, so cost optimization of the general-purpose plane never starves the models. Below the cluster, the data tier runs on Amazon RDS for PostgreSQL in Multi-AZ configuration on gp3 storage with explicitly provisioned IOPS — performance bought where it is needed, not everywhere. CloudWatch and Amazon Managed Grafana carry the custom cost, GPU, and latency metrics that keep the optimization measured rather than assumed.