300+ Kubernetes clusters in production across four clouds, without the noise.

Case 1 · Hydrolix · 2024 to present

10×

faster deployments

From kubectl edit to GitOps with ArgoCD

Problem

Every cluster was changed by hand with kubectl edit. Nothing was audited, a fix in one region could be silently reverted in another, and infrastructure code was tangled with the application manifests.

What I did

I proposed splitting them and moving to GitOps with ArgoCD. The team was at capacity, so we agreed I would work on it for about 30% of my time, outside on call. I built a proof of concept, showed it working and got it approved.

Outcome

Onboarding a customer dropped from about two hours to 15 to 20 minutes, every change has an audit trail, and it became the base for later automation such as self healing runbooks.

• ArgoCD
• Kubernetes
• Kustomize
• Pulumi
• GitHub Actions

Case 2 · Hydrolix · 2024 to present

Fleet scale

health gated rollouts

Progressive delivery platform

Problem

Upgrades across the whole fleet took weeks of manual coordination, with no safe way to batch, retry or roll back.

What I did

I co built a platform on Argo Workflows with regional targeting, automated health checks before and after each batch, a live view of the workflow and scheduled rollouts.

Outcome

Rollouts are gated on health and can be rolled back with one click. It became the standard way to upgrade the fleet.

• Go
• React
• Argo Workflows
• ArgoCD
• Prometheus

Case 3 · Hydrolix · 2024 to present

20 to 30

incidents a month eliminated

Automated OOM remediation

Problem

The same out of memory alerts paged the on call engineer every month, and the fix was always the same manual change.

What I did

I designed a system that reads the signals and proposes the right change through GitOps.

Outcome

More than 20 hours of toil and 20 to 30 incidents a month were removed from the rotation.

• Kubernetes
• Prometheus
• ArgoCD
• Go
• Pulumi

Case 4 · Hydrolix · 2024 to present

30+

environments newly monitored

A slow Grafana that exposed a monitoring gap

Problem

A customer's Grafana dashboards became very slow. Their queries looked normal and every dashboard was affected. Running df -h in the database pod showed the volume 95% full. It also showed a bigger gap: these customer facing Grafana instances were not part of our monitoring.

What I did

I resized the volume with the Postgres operator, then cordoned nodes one at a time and restarted the pods so it came back at the right size. After that I extended our ArgoCD setup with the app of apps pattern to cover the Grafana instances, added alerts for disk use and instance health, and wrote the RCA and a guide for adding Prometheus to their infrastructure code.

Outcome

Fixed within one on call shift. Prometheus now covers 30+ environments that had no monitoring, so this kind of issue alerts us before a customer notices.

• Grafana
• Prometheus
• PostgreSQL
• ArgoCD
• Kubernetes

Case 5 · Hydrolix · 2024 to present

Automated

bucket capacity extension

Black Friday capacity, automated afterwards

Problem

During a Black Friday, customer buckets and the database catalog reached their read and write limits. Engineers in every region were on call and extended capacity by hand all day to keep the catalog from bloating.

What I did

Afterwards I proposed a pipeline and infrastructure code changes to automate that extension, built a proof of concept and presented it.

Outcome

The team approved the migration, so a peak day no longer depends on manual work from engineers in every region.

• Infrastructure as code
• CI pipelines
• Capacity planning
• On call

Case 6 · Triggle Spain · 2023 to 2024

27%

lower AWS platform cost

AWS cost optimisation and the EKS upgrade

Problem

Resources were over provisioned, and clusters sat on an old version in paid extended support, billed at six times the standard rate.

What I did

I led a team of 3 through autoscaling policies, cleanup jobs and right sizing, then upgraded 4 clusters from 1.24 to 1.29 with Terraform and Velero backups.

Outcome

Platform cost fell by 27% and extended support cost by 82.5%, and the platform scales better.

• AWS
• EKS
• Terraform
• Velero
• CAST AI

Case 7 · Triggle Spain · 2023 to 2024

1 weekend

to restore production CI

Recovering production Jenkins after a failed upgrade

Problem

While testing the EKS upgrade on clusters labelled dev, I found out that the production Jenkins pipeline ran there. The upgrade broke Jenkins and deleted its volume, and production deployments stopped.

What I did

I spent the weekend restoring the volume from the Velero backup and recovering Jenkins. I also moved it onto the production management cluster, where it belonged.

Outcome

Production CI was back after the weekend. Since then I check what really runs on a cluster, whatever its label says, and take a fresh backup before any destructive change.

• Jenkins
• EKS
• Velero
• AWS
• Kubernetes