How we used the strangler-fig pattern to move a stateful Spring Boot monolith onto EKS over 9 months, with progressive traffic shifting via Istio and zero "big-bang" risk.
The client's flagship HR platform was a single Spring Boot WAR — 2.3M lines, 47 service domains tangled into one deployable, running on a fleet of bare-metal Tomcat servers. Every release required a Saturday-night maintenance window, manual DB migrations, and a rollback runbook that nobody trusted.
The pain wasn't infrastructure cost — it was velocity:
A "rewrite to microservices" RFP had been floated and rejected three times — too expensive, too risky, too long. The client wanted modernization without a rewrite. We agreed.
Instead of decomposing the monolith upfront, we kept it intact, containerized it as-is, and put a service mesh in front. Then we carved off domains one at a time — each new microservice sitting beside the monolith, both routable via Istio.
Multi-stage Dockerfile for the WAR, externalized config via ConfigMaps/Secrets, JVM tuning for K8s.
Weeks 1–6EKS clusters via Terraform, Istio mesh, ArgoCD GitOps, baseline CI in GitHub Actions, observability stack.
Weeks 6–14Identified the "Notifications" bounded context, extracted into a Go service, routed 5% traffic via Istio.
Weeks 14–22Carved 4 more domains using the same playbook. Monolith shrunk from 47 to 32 domains, deploy slot freed.
Weeks 22–36Istio sits at the ingress and routes each URL prefix either to the legacy monolith pod or to the new microservice. Header-based routing lets us canary new domains to 1–5% of traffic before promoting.
Internet ──► ALB ──► Istio Ingress Gateway │ ┌──────────────────┼──────────────────┐ ▼ ▼ /notifications/* /* (everything else) │ │ ┌──────▼──────┐ ┌──────▼──────┐ │ notifications │ │ monolith │ │ (Go svc) │ │ (Spring Boot)│ └──────┬──────┘ └──────┬──────┘ │ │ ▼ ▼ Postgres (shared) Postgres (shared)
| Metric | Before | After | Δ |
|---|---|---|---|
| Deploy frequency | 1× / quarter | 12× / day | +1080× |
| Build time (full suite) | 3.5 hours | 67 minutes | −68% |
| Lead time for change | 87 days | 2.4 days | −97% |
| Onboarding to first commit | 9 days | 4 hours | −95% |
| Compute spend (monthly) | $98K | $54K | −45% |
| Failed-deploy rate | 22% | 1.8% | −92% |
No rewrites, no big-bang cutovers. Just incremental progress your team can ship and trust.
Start a conversation