Case studies

Eight pieces of infrastructure work from Janaki Technology and eSewa: what was wrong, what I built, and what changed for the team.

FinOps: 50% cost cut
Terraform on AWS
Secure CI/CD
Autoscaling with KEDA
Rancher cluster management
Logging and health checks
Kafka and Redpanda
Mobile builds

Cutting a client’s AWS bill in half

50%

lower monthly AWS spend

Where: Janaki Technology, for a managed-services client
Stack: AWS Cost Explorer, Compute Optimizer, Savings Plans, AWS Budgets, S3 lifecycle rules, Terraform

The problem

The client’s AWS bill had grown month after month with no clear owner. Instances were sized for peaks that never came, test environments ran all night and weekend, and old volumes, snapshots and IP addresses kept costing money long after anyone used them.

What I did

Tagged resources by team and environment so every dollar could be traced to an owner, then broke the bill down in Cost Explorer.
Rightsized over-provisioned EC2 and database instances using Compute Optimizer and real utilization data, and moved suitable workloads to newer, cheaper instance types.
Covered the steady baseline with Savings Plans, and moved interruptible non-production work to Spot.
Scheduled dev and staging environments to shut down outside working hours.
Removed unattached EBS volumes, stale snapshots, idle load balancers and unused Elastic IPs, and added S3 lifecycle rules to move old data to cheaper storage.
Captured the changes in Terraform and set AWS Budgets alerts so costs stay down.

How the review ran

Tag and measure Find waste Rightsize and schedule Commit with Savings Plans Monitor with budgets

Result

Monthly AWS spend fell by 50% with no loss of performance or availability, and the client now gets an alert before costs drift up again.

AWS infrastructure built with Terraform

Stack: Terraform, Terragrunt, AWS VPC, EKS, EC2, Application Load Balancer, security groups
My role: Designed the modules and ran the rollout

The problem

Servers, load balancers and network rules were created by hand in the AWS console. Environments slowly drifted apart, changes left no record, and rebuilding anything meant remembering how it was done the first time.

What I built

Reusable Terraform modules for the VPC and subnets, EKS clusters and node groups, and EC2 instances behind an Application Load Balancer with health checks.
Terragrunt to keep one configuration per environment calling the same modules, so dev, staging and production differ only in their variables.
Shared remote state with locking, so two people can never apply over each other.
A review step: every change is run as a plan and checked before it is applied.

How a change flows

Edit module terraform plan Peer review terraform apply Environment updated

Result

Infrastructure deployments became repeatable, with fewer errors and no more drift between environments. A new environment is now a configuration file, not a week of clicking.

Secure CI/CD for microservices

Stack: Jenkins, GitLab CI, Docker, Trivy, SonarQube, OWASP Dependency-Check, Git Flow
Services: Java, Laravel, Python and JavaScript

The problem

Each team shipped its service a little differently, deployments were slow, and security checks happened late or not at all. For a payments company, a vulnerable library reaching production is not an option.

What I built

A standard pipeline shape for all four language stacks in Jenkins and GitLab CI: build, test, scan, package, deploy.
SonarQube for code quality, OWASP Dependency-Check for vulnerable libraries and Trivy for container images, set to stop the pipeline on serious findings.
Git Flow branching so feature, release and hotfix work merge predictably.

How a commit flows

Commit Build and test SonarQube Dependency-Check Docker image + Trivy Deploy to Kubernetes

Result

Faster, consistent deployments across every service, with vulnerabilities caught before release instead of after.

Event-driven autoscaling for 30+ workloads

Stack: Kubernetes, AWS EKS, on-prem clusters, KEDA, Rancher, Docker
Scale: 30+ containerized workloads

The problem

Payment traffic is spiky: festivals, salary days and promotions bring sudden peaks. Fixed replica counts meant either paying for idle capacity or slowing down when it mattered most.

What I built

Set up the Kubernetes clusters on AWS EKS and on-prem, and containerized the services onto them.
KEDA scalers that add or remove pods based on real signals such as queue depth and load, not just CPU.
Node group management so the cluster itself grows and shrinks with the pods.
Rancher as a single GUI across the EKS and on-prem clusters, so the team can see workloads, manage access and check cluster health without the command line.
Rolling updates so new versions go out with minimal downtime.

Result

Services stay responsive through peak loads and scale back down afterwards, keeping resource use efficient.

One dashboard for every Kubernetes cluster with Rancher

Stack: Rancher, Kubernetes, AWS EKS, on-prem clusters, RBAC
Users: DevOps, developers and QA teams

The problem

With clusters on both AWS EKS and on-prem, everything ran through kubectl and separate kubeconfig files. Developers had to ask DevOps for simple tasks like reading pod logs or restarting a service, and access rules were set up differently on each cluster.

What I built

Deployed Rancher and imported the EKS and on-prem clusters into one web dashboard.
Organized namespaces into Rancher projects and set role-based access, so each team sees and changes only its own services.
Gave developers self-service in the browser: view logs, open a shell, restart or scale their own workloads.
Used the dashboard for a single view of node health, workloads and cluster events across every environment.

How access is set up

Import cluster Group namespaces into projects Assign team roles Teams self-serve in the browser

Result

Routine requests to the DevOps team dropped, access control became consistent across all clusters, and anyone with the right role can check what is running without learning kubectl.

Central logging and live API health checks

Stack: Elasticsearch, Logstash, Kibana, Filebeat, Metricbeat, Heartbeat, Grafana, Loki, Promtail

The problem

When something broke, engineers logged into servers one by one to read logs. Finding the cause took longer than fixing it, and some outages were noticed by users first.

What I built

An ELK stack collecting application logs with Filebeat and Logstash, and server metrics with Metricbeat, all searchable in Kibana.
Heartbeat checks on key APIs, so the team knows a service is down before customers do.
Grafana with Loki and Promtail for Kubernetes pod logs, next to the cluster dashboards.

How a log travels

Service or pod Filebeat / Promtail Logstash / Loki Kibana / Grafana

Result

Incident resolution time dropped, and the team gained a single view of what every service is doing.

Kafka clusters with visual monitoring

Stack: Apache Kafka, Redpanda Console

The problem

Services needed reliable messaging between them, but Kafka is hard to see into from the command line, so developers couldn’t easily check whether messages were flowing.

What I built

Deployed and configured Kafka clusters for service-to-service events.
Added Redpanda Console so anyone can browse topics, inspect messages and watch consumer lag in a browser.

Result

Developers debug messaging problems themselves, without waiting on the DevOps team.

Automated mobile app builds

Stack: Jenkins, Android build tooling

The problem

Building the Android app for testers and release was a manual job on a developer’s machine, which slowed releases and made builds hard to reproduce.

What I built

A Jenkins pipeline that builds the APK from source on demand.
Automatic publishing of the finished APK so QA and release managers download it directly.

Result

Mobile release time dropped significantly, and every build comes from the same clean environment.

Want the details behind any of these?

Email me Back to portfolio