Real infrastructure. Real decisions. Real results.
These are documented projects with architecture decisions, challenges encountered, and measurable outcomes — not just screenshots of dashboards.
Meet App — Node.js CI/CD Pipeline
End-to-end CI/CD on AWS EKS. 99.9% uptime. 80% reduction in manual deployment effort.
Read case studyScalable Microservices Architecture
Enterprise microservices on EKS with independent deployments and 99.9% uptime.
Read case studyMulti-Tier Retail Store Application
Full GitOps workflow on EKS Auto Mode with Grafana monitoring and automated CI/CD.
Read case studyMeet App — Node.js CI/CD Pipeline on AWS EKS
Problem
A Node.js video conferencing application needed a production-grade deployment pipeline. The existing process was entirely manual — developers were SSH-ing into servers to deploy, there was no automated testing, no security scanning, and no rollback mechanism. Every deployment was a risk.
Environment
- Application: Node.js web application (Meet — real-time video conferencing)
- Target platform: AWS EKS (Elastic Kubernetes Service)
- Infrastructure provisioned on Google Cloud (GCP free tier) for the CI server
- Source control: GitHub
Challenge
The core challenge was building a pipeline that was both secure and fully automated — from code commit all the way to a running pod on EKS. This meant integrating security scanning at multiple stages without slowing down the pipeline, and ensuring the Kubernetes cluster itself was provisioned reproducibly with Terraform rather than manually.
Solution
Designed and implemented a two-stage CI/CD pipeline:
CI Pipeline (Jenkins): On every push, Jenkins runs OWASP Dependency Check for known vulnerabilities, SonarQube for code quality analysis, Trivy for filesystem security scanning, Docker image build and push to registry.
CD Pipeline (Argo CD + GitOps): Argo CD watches the Kubernetes manifest repository. When the CI pipeline updates the image tag, Argo CD automatically syncs the new version to the EKS cluster — no manual kubectl apply, no SSH.
Infrastructure was provisioned with Terraform (custom VPC, EKS cluster, IAM roles, node groups) and configured with Ansible. Monitoring was set up with Prometheus and Grafana via Helm.
Result
- 99.9% uptime achieved post-deployment
- 80% reduction in manual deployment effort — zero SSH deployments
- Security vulnerabilities caught at build time, not in production
- Full rollback capability via Argo CD with one click
- Infrastructure fully reproducible — destroy and recreate in under 20 minutes
Lessons Learned
- Running the CI server on GCP while deploying to AWS EKS adds cross-cloud networking complexity — IAM role federation needs careful planning.
- SonarQube and OWASP scans add ~4 minutes to pipeline time. Worth it, but teams need to be prepared for the initial adjustment.
- GitOps works best when the manifest repo is strictly separate from the application repo — mixing them creates merge conflicts and unclear ownership.
Scalable Microservices Architecture on AWS EKS
Problem
An e-commerce platform was running as a monolith. Any change to one part of the system required a full redeployment of everything. Scaling was all-or-nothing — you couldn't scale just the product service during a sale without scaling the entire application. Deployments were slow and risky.
Environment
- Application: Java Spring Boot e-commerce backend (REST APIs, no UI)
- Services: Eureka Server, API Gateway, Inventory Service, Product Service, Coupon Service
- Platform: AWS EKS with Terraform-managed infrastructure
- Each service maintained in its own GitHub branch for independent deployment
Challenge
Decomposing a monolith into microservices introduces service discovery, inter-service communication, and independent deployment complexity. The challenge was designing a clean service boundary, implementing Eureka-based discovery, and ensuring each service could be deployed, scaled, and rolled back independently without affecting others.
Solution
Decomposed the application into 5 independent Spring Boot services, each in its own branch and Docker image. Eureka Server handles service registration and discovery. An API Gateway provides a single entry point for all client requests and routes to the appropriate service.
Infrastructure was provisioned with Terraform — custom VPC, EKS cluster, IAM roles, and node groups. Kubernetes manifests handle deployment, service exposure, and horizontal pod autoscaling. SonarQube was integrated into the CI pipeline for code quality gates before any image is pushed.
Result
- 99.9% uptime with decentralized service management
- 20% performance improvement through independent service scaling
- Each service deployable independently — a change to the coupon service doesn't touch inventory
- Infrastructure fully codified and reproducible with Terraform
- Code quality gates enforced — no deployment without passing SonarQube analysis
Lessons Learned
- Service discovery with Eureka works well but adds a startup dependency — services must wait for Eureka to be healthy before registering. Health check ordering in Kubernetes matters.
- Keeping each service in its own branch simplifies CI but requires discipline around shared library versioning.
- Horizontal Pod Autoscaler needs realistic load testing to tune min/max replicas correctly — default values are rarely right for production.
Multi-Tier Retail Store Application on AWS EKS
Problem
A retail e-commerce backend needed a production deployment on AWS that could handle variable traffic, scale automatically, and be operated without manual intervention. The team also needed full observability — knowing what was happening inside the cluster at all times, not just whether the service was up or down.
Environment
- Application: Containerized multi-tier retail store microservices
- Platform: AWS EKS with EKS Auto Mode for automatic node provisioning
- Deployment: GitOps via Argo CD watching a dedicated manifest repository
- Observability: Grafana dashboards with Prometheus metrics
Challenge
EKS Auto Mode simplifies node management but requires careful configuration of node classes and pod scheduling constraints. The main challenge was combining Auto Mode's automatic node provisioning with a GitOps workflow — ensuring that infrastructure changes and application changes both flowed through version-controlled, auditable pipelines rather than manual kubectl commands.
Solution
Deployed the application on EKS with Auto Mode enabled — nodes are provisioned and terminated automatically based on pod scheduling demand, eliminating manual node group management. Argo CD was configured to watch the manifest repository and sync any changes automatically, providing a full audit trail of every deployment.
Grafana dashboards were built on top of Prometheus metrics to provide real-time visibility into pod health, resource utilisation, request rates, and error rates. Alerts were configured for anomalous conditions before they became incidents.
Result
- Fully automated deployment pipeline — no manual kubectl apply in production
- EKS Auto Mode reduced node management overhead to near zero
- Grafana dashboards provided immediate visibility into application and infrastructure health
- Every deployment tracked in Git — full audit trail, instant rollback capability
- Scalable architecture ready to handle traffic spikes without manual intervention
Lessons Learned
- EKS Auto Mode is powerful but opinionated — it works best when you let it manage node lifecycle fully rather than mixing it with manually managed node groups.
- Grafana dashboard design matters as much as the metrics themselves. Dashboards that show too much data are as useless as dashboards that show too little.
- GitOps creates a natural forcing function for good practices — if it's not in Git, it doesn't exist. Teams adapt quickly once they see the rollback benefits.
Want infrastructure built this carefully for your business?
Let's talk about what you're running and how to make it more reliable.
Book a Free Consultation