Kubernetes engineering services
Kubernetes is the right answer to a specific problem: many services, real scaling requirements and a team to operate it. We deploy it when that is true, and we will say so when it is not.
Where we use Kubernetes
Kubernetes is part of the stack on these 2 services. Each page covers how we work, what you get and what it costs to start.
Kubernetes in practice
Kubernetes solves a specific problem: many services, real scaling needs and a team able to operate it. When those three are true it is excellent — self-healing, declarative scaling, and one deployment model across every environment. When they are not, it is a large amount of complexity in exchange for benefits a container service would have provided.
We will tell you which situation you are in. Below roughly a handful of services with steady traffic, ECS, Cloud Run or App Service is cheaper to run and dramatically cheaper to understand. The decision that matters most is not how to configure Kubernetes but whether you should be running it at all.
What we build with Kubernetes
EKS, AKS or GKE clusters with ingress, secrets, autoscaling and network policy configured deliberately rather than by default.
Service-per-team deployments with resource limits, health checks and rollout strategy defined per workload.
Right-sizing requests, autoscaling policy and the security posture that most default clusters lack.
Is Kubernetes right for you?
Ask usA good fit when
- Many services that need independent scaling and deployment
- Teams with the capacity to operate a cluster, or a partner who does
- Workloads needing portability across clouds
- Organisations standardising deployment across many teams
Probably not when
- One application with predictable traffic
- Small teams with no operations capacity
- Products where the complexity would consume the budget that should build features
What we run alongside Kubernetes
The rest of the setup, and why each piece is there. We keep this list short on purpose — every dependency is something someone has to maintain.
- Managed control plane
- EKS, AKS or GKE. Running your own control plane is rarely a good use of anyone’s time.
- Helm
- Packaging and versioned releases, so environments differ only in a values file.
- ArgoCD
- GitOps delivery, so cluster state matches a reviewed repository.
- Ingress + cert-manager
- Routing and automatic TLS certificates.
- Prometheus + Grafana
- The monitoring stack the ecosystem assumes.
- Resource requests and limits
- Set deliberately — the difference between a stable cluster and random evictions.
Why Kubernetes
Let’s talkSelf-healing
Failed containers restart and unhealthy nodes drain without anyone being paged at three in the morning.
Scaling as configuration
Horizontal scaling is a declared policy rather than a manual response to a traffic spike.
Portable across clouds
The same manifests run on any managed Kubernetes, which keeps a migration technically feasible.
What we get called in to fix
Get a second opinionClusters with no resource limits
One workload consuming a node and evicting everything else on it.
Manual kubectl deployments
Cluster state that no repository describes, so nobody can say what is running.
Over-provisioned node pools
Nodes sized for a launch spike, running at low utilisation for a year.
No network policy
Every pod able to reach every other pod, which makes any single compromise far worse.
Kubernetes or the alternative
The comparisons we are actually asked to make, answered the way we would answer them on a call.
Container services for one to a few services. Kubernetes when orchestration across many workloads is genuinely the problem.
Managed, always, unless there is a compliance reason. The control plane is not where your differentiation is.
Helm for packaging and third-party charts. Kustomize for straightforward per-environment overlays.
Kubernetes works well with:
AWS
Azure
Docker
Google Cloud
Grafana
Prometheus
Python
Redis
Terraform
Angular
AnsibleGot an idea? Let’s make it real.
Tell us the short version
This could be the first step towards a new and successful collaboration. A one-line idea and a finished spec are both fine — tell us the problem, the deadline you’re working to and what’s in your way.
Keep looking
Frequently asked questions
Often not. Below roughly a handful of services with steady traffic, a managed container service is cheaper and simpler.
Either your team with our handover and runbooks, or us on an ongoing basis. We agree that before the build, not after.
Helm charts for packaging and ArgoCD for GitOps delivery, so the cluster state matches a reviewed repository.
Often not, and we would rather say so before the migration than after. It is an excellent answer to a problem many products do not have.
Whoever we agree at the start — your team with runbooks and training, or us. Leaving that undecided is how clusters get neglected.