Kubernetes consulting
Kubernetes is excellent at running production systems and equally excellent at generating work. I help teams get the first without the second, and occasionally conclude they don’t need it at all.
Sound familiar?
- Every service deploys a little differently, so every incident starts with working out how this one was shipped.
- Clusters sized for a launch that never stopped being the plan, reserving far more than they use.
- Rollouts that are all-or-nothing, with no canary and no quick way back.
- Observability that varies by team: some services are glass boxes, others are guesswork.
- Platform tooling that has quietly become a bigger workload than the application.
How I approach it
I treat a cluster as an operating model, not a pile of manifests. The questions that matter are how a service gets to production, how traffic shifts when it changes, how you find out it is unhealthy, and who owns it when it is.
Sometimes the honest answer is less Kubernetes. In one engagement the cluster reserved about 17 vCPUs to do roughly one core of work, and moving to Cloud Run removed a platform’s worth of moving parts. If that is your situation too, I will say so.
What you get
- 01
Platform assessment
Cluster configuration, resource requests, deployment workflows, and observability coverage, reviewed against measured usage, with what to fix first.
- 02
Deployment standards
Shared Helm charts and CI/CD templates, so a new service inherits a known path to production.
- 03
Traffic management
Istio or ingress configuration for canary releases and controlled rollouts.
- 04
Observability
Metrics, logs, and traces wired to the signals that matter, with SLOs where they earn their keep.
- 05
Right-sizing or migration
Requests, limits, and autoscaling that match real load, or a planned move to a simpler runtime when the cluster isn’t paying its way.
What I work with
Where I’ve done this
- Case study · Enterprise PlatformOperationalizing an enterprise Kubernetes platformAn evolving microservices platform turned into a repeatable production operating model: Helm, Istio canary deployments, Dynatrace, and Splunk.
- Case study · EdTechSimplifying an over-built Kubernetes platform onto Cloud RunA cluster reserving about 17 vCPUs for about one core of work, retired for Cloud Run. ≈38% lower modelled monthly run-rate, at list prices from measured usage.
How an engagement runs
- Discovery call. We talk through your environment, what is hurting, and whether I am the right person to help.
- Assessment. I review the systems involved and write down what I find, with recommendations in priority order.
- Plan. We agree what changes first, what it should achieve, and how we will know it worked.
- Implementation. Hands-on work alongside your team, through code and review rather than console clicks.
- Handover. Documentation and walkthroughs so your engineers own the result, with ongoing support if you want it.
Questions
Do you work with EKS, GKE, and OpenShift?
Yes. The case studies here cover Kubernetes on AWS and on GKE. Deployment standards, resource sizing, and observability work the same way across distributions.
Will you recommend moving off Kubernetes?
Only if the numbers say so. Kubernetes earns its complexity with many services, varied workloads, and a team to run it. When a cluster is mostly idle capacity and platform tooling, a managed runtime can be simpler and cheaper.
Can you help our team run it rather than run it for us?
Yes. Standards, templates, and handover are part of the work, so your engineers can carry it on. Ongoing support is there if you would rather not.