Kubernetes
Cluster design, autoscaling, Helm charts, and multi-cloud deployment.
Right-sizing the cluster topology
Most teams over-provision node pools before they've measured anything. We start with a single general-purpose node pool plus one GPU or memory-optimized pool only if a specific workload needs it, and let the Horizontal Pod Autoscaler and Cluster Autoscaler earn their keep before adding topology complexity.
Autoscaling that responds to the right signal
CPU-based HPA is the default and it's frequently wrong for I/O-bound or queue-consuming services. For anything backed by a queue, scale on queue depth (KEDA works well here) instead of CPU — a service can be CPU-idle while falling badly behind on a backlog.
Helm charts and multi-cloud portability
We template environment-specific values (ingress class, storage class, resource limits) rather than forking charts per cloud, so the same chart deploys to EKS, GKE, or AKS with a different values file. The parts that don't port cleanly — load balancer annotations, storage classes, IAM-adjacent service accounts — get isolated into a small per-cloud overlay rather than scattered through the chart.
Working through something like this?
Get a scored blueprint in the Architecture Lab, or talk it through with the Architect Assistant first.