Overview
An e-commerce platform had built its order processing, inventory, and notification systems entirely on AWS Lambda. As transaction volumes grew, the architecture created operational friction — cold starts affected user-facing checkout, per-invocation costs were unpredictable, and the team struggled to reproduce issues locally.
Why GKE
The decision to move to GKE (rather than EKS or another provider) was driven by:
- Existing Google Workspace tooling and GCS data warehouse
- GKE Autopilot for reduced node management overhead
- Committed Use Discounts available for baseline compute
Migration Approach
Phase 1: Containerisation (Weeks 1–3)
Each Lambda function was containerised with:
- Consistent Dockerfile patterns (multi-stage, minimal base images)
- Health check and readiness probe endpoints added to all services
- Local development environment mirroring production behaviour
Phase 2: KEDA for Serverless Scaling (Week 3–4)
KEDA (Kubernetes Event-Driven Autoscaling) replicated Lambda’s scale-to-zero model:
- Pub/Sub triggers for async workloads (order processing, notifications)
- HTTP triggers via KEDA HTTP Add-on for synchronous API services
- Scale-to-zero configured for non-critical batch jobs during off-peak hours
Phase 3: Traffic Migration (Weeks 5–6)
- Weighted traffic split via API Gateway during cutover
- Lambda functions kept live in parallel for 2 weeks post-migration
- Rollback plan tested twice before production cutover
Results
Cold start latency was eliminated entirely — Kubernetes pods maintain warm instances between requests. The 47% cost reduction came from GKE Committed Use Discounts and elimination of per-invocation Lambda pricing at scale.