Kubernetes consulting and platform architecture

By checking whether its problems are your problems: a meaningful number of services with independent release cycles, workloads that genuinely benefit from fine-grained scheduling, or a stated requirement for consistent deployment across environments. If none of those describe you, a managed application platform will serve better at a fraction of the operating burden.

We ask this first, knowing that the answer no makes the engagement smaller.

Decided by blast radius and isolation rather than by convention. One large cluster is cheaper to operate and concentrates risk; many clusters isolate well and multiply operational work. Environment separation is usually the minimum justified split.

Preferably not, above a certain team size. A paved path that abstracts it means fewer people need to understand it, at the cost of building and maintaining that abstraction. Below that size the abstraction costs more than it saves.

Usually memory limits set too low, or liveness and readiness probes confused — a liveness probe that fails during slow startup restarts the pod repeatedly. Both are configuration rather than platform problems, and both are extremely common.

Resource requests set too high, typically copied between services rather than measured. Requests reserve capacity whether or not it is used, so an over-requested cluster is both expensive and underutilised — frequently alongside other workloads that are throttled because theirs are too low.

Usually not. A mesh provides real capabilities — mutual TLS, traffic shaping, detailed telemetry — at substantial operational complexity and some latency. Most estates adopting one could obtain the specific capability they wanted more cheaply, and it is worth naming that capability before deciding.

On a scheduled cadence with an owner. Versions are supported for a limited period and upgrades cannot be skipped indefinitely, so falling behind compounds until catch-up is a project. Pod disruption budgets and readiness probes are what make an upgrade routine rather than an outage.

No, and its defaults surprise teams. Pods can typically reach any other pod, service accounts mount automatically, and containers frequently run with more privilege than needed. Network policy, admission control and image provenance are the controls that close categories rather than instances.

Technically yes, and the portability is smaller than it appears. Identity, networking, storage and load balancing all differ, so the workload definitions port and the platform beneath them largely does not. Multi-provider is a legitimate choice for a stated reason, not a free benefit of adopting Kubernetes.

Almost always, if you have concluded you need Kubernetes at all. Operating the control plane yourself is work with very little differentiating value, and the managed offerings remove a meaningful share of the upgrade burden that causes estates to fall behind.

A team that owns it, with the capability to do so. Kubernetes without an owner degrades quietly — upgrades slip, policy drifts, cost grows — and the organisations that struggle most are the ones that adopted it without deciding who would run it.