Platform migration · 2023
Moving CNET's CMS and content API from Docker Swarm to GKE
CNET's content management system and content API ran on a legacy Docker Swarm fleet. I led their migration to Google Kubernetes Engine—owning the cost model, replica sizing, in-cluster Varnish cache tier, and phased evening cutovers with zero rollbacks.
Context
The CMS and the API that served content to the sites were a PHP application that had run on Docker Swarm since 2017, first in a data center and then on Google Cloud. By 2023 it took about 160 containers, behind a cache tier that ran on its own VMs. Its sister site ZDNET already ran the same application on GKE, which gave the cost model a real comparison. My own first Kubernetes and Helm work was in 2022, when I launched another brand, Metacritic, with its own configuration and pipelines, before that brand was sold (the carve-out).
The plan
- Cost model. I compared the Swarm spend with a comparable site already on GKE. That projected roughly half the run-rate, a modeled estimate rather than a measured result.
- Sizing. I set the replica counts and specs for each tier instead of carrying the Swarm fleet over. The Kubernetes sizing used about a seventh as many containers.
- Cache strategy. I designed the caching strategy, deployed an in-cluster Varnish tier in front of the application, and wrote the Terraform DNS and load-balancer changes to route traffic through it—right-sizing the tier the following year.
- Cutover plan. I planned a phased, off-peak cutover: the CMS on one evening, followed by the API across subsequent evenings. Before each step I load-tested the new deployment and ran code-quality checks on the changes going out.
Afterwards
I shut down the Swarm fleet after the cutover. Later, during the team's move off Jenkins to GitHub Actions builds and GitOps deploys in 2025, I removed the legacy Jenkins and Helm deploy pipeline.
My part: I owned the epic and its child tickets: the cost model, replica sizing, the cache and load-balancer design, the cutover plan and the Swarm removal. Teammates on the platform team wrote the Kubernetes manifests.
What I carry forward
Pair every cost projection with a way to measure it. A modeled saving justified this migration; setting up a cluster cost view before the cutover turns that projection into a measured result.