01
The challenge
The platform had grown faster than its infrastructure. Deployments were manual and succeeded about 70% of the time, environments were inconsistent, scaling policies were ad hoc, and monthly AWS spend was rising 40% month on month. The engineering team was blocked by infrastructure rather than enabled by it.
02
Solution architecture
Layers top to bottom. Controls apply at every layer.
03
Approach
- 01Assess current spend, workload shapes and failure modes before designing anything.
- 02Standardise on EKS with a single, reproducible cluster definition in Terraform.
- 03Move delivery to GitOps with Argo CD so every environment is declared, reviewed and reconciled.
- 04Right-size with resource requests, limits and autoscaling driven by measured usage, not guesses.
- 05Migrate workloads incrementally behind existing load balancers so users never noticed.
04
How the delivery ran
- Week 1–2: assessment, cost baseline, target architecture agreed in writing.
- Week 3–5: EKS platform, Terraform modules and Argo CD bootstrapped in the client's accounts and repositories.
- Week 6–7: workload migration service by service, each with a rollback path.
- Week 8: validation against the agreed requirements, runbooks, recorded hand-over. 30 days of support followed.
05
What was delivered
- EKS platform and Terraform module library in the client's repositories
- Argo CD GitOps repository structure and environment promotion flow
- Autoscaling, quota and cost-control configuration
- Runbooks for deploy, rollback, upgrade and incident response
06
Results
| Dimension | Before | After |
|---|---|---|
| Cloud spend | Rising 40% month on month | 60% lower, stable |
| Deployment success | ~70%, manual | 95%, automated |
| Deployment time | 45 minutes with intervention | 5 minutes, hands-off |
| Unplanned downtime | Recurring | None in the 6 months after go-live |
| Ownership | Tribal knowledge | Declared in Git, documented, operated by the team |
Facing a similar decision? A 30-minute architecture review is the fastest way to find out whether the same approach fits.
Book an architecture reviewMore case studies
Other engagements
Government · Tourism · Azure
A secure Azure platform for a national tourism digital ecosystem, delivered as code.
A high-traffic tourism ecosystem built on Sitecore, .NET and Optimizely needed standardised, observable and resilient infrastructure across development, UAT and production. I owned cloud architecture, security, networking, CI/CD and production application delivery as Cloud Solution Architect and DevOps Engineer.
Food & Wellness · E-commerce · Azure
The Azure platform behind a high-volume digital meal-plan experience, run as code.
PractiCal sells personalised meal plans across the UAE through a Next.js storefront, Laravel/PHP backend services and Azure serverless workloads. I owned the cloud and application platform end to end: infrastructure, edge security, CI/CD and production operations across development, staging and production.
Education · Enterprise · Azure
A secure Azure platform for a large-scale university digital experience on .NET and Umbraco.
A university digital platform serving prospective students, current students, faculty and other stakeholders: programme discovery, admissions, applications and student services on an ASP.NET and Umbraco CMS stack. I owned Azure infrastructure, application delivery, security and production operations.
FinTech · AWS
Zero-trust AWS controls that took a FinTech to SOC 2 Type II in 8 weeks with no audit findings.
Enterprise deals depended on SOC 2 Type II, and the existing estate had shared secrets in code, permissive IAM and no audit trail. I designed and implemented the identity, network, secrets and audit controls, and the external audit closed with zero findings.
B2B Software · Kubernetes
Observability and SLOs that cut detection time from 90 minutes to 5 and freed a fifth of engineering time.
A six-person team ran production with no visibility: incidents took hours to detect and 40% of engineering time went to firefighting. I built the observability stack, defined SLOs and burn-rate alerting, and wrote the runbooks. Detection fell to 5 minutes and the team got 20% of its time back.