Platform and DevOps engineering

Kubernetes, pipelines and the deployment safety nobody notices until it is missing

There is a category of problem that only appears after deployment, and it is invisible to a development team that has never carried a pager. A rollout that drops requests because pods are removed from service before they stop receiving traffic. A disruption budget expressed in a way that lets a node drain take the last replica. A scheduled job running on three replicas at once because nothing makes it a singleton. These are not advanced topics. They are the difference between a system that is up and a system that appears up.

What the work involves

  • Cluster and namespace design, or a candid assessment that you do not need Kubernetes at all
  • Deployment manifests with readiness gates, pre-stop hooks and minimum-ready periods as standard, not as an afterthought
  • Disruption budgets expressed so a node drain cannot take your last replica
  • Pipelines that build, guard and deploy, with the guards able to stop a release
  • Metrics, logs and traces wired in before launch
  • Runbooks written for whoever is on call, including the case where that is not us

Why we are credible at this

We run an RKE2 cluster carrying 106 deployments and 267 pods across 19 namespaces, with our own storage, ingress, certificate automation and virtualisation. The deployment safety rules we apply to client work are the ones we wrote down after breaking our own.

What moves the price

We quote after discovery and the number is fixed before anything starts. These are the things that move it, so you can see roughly where your project sits before you talk to us.

  • Whether you are starting fresh or inheriting infrastructure that has drifted from its configuration
  • Compliance and data-residency requirements, which constrain where things may run
  • How many environments need to exist and stay consistent with each other
  • Whether your team needs to operate it afterwards, which makes documentation and training part of the work

Proof we have done this

The cluster we run our own company onA production Kubernetes platform, operated by the people who deploy to itKnowing something is wrong before a customer tells usMetrics, logs and distributed traces, self-hosted and actually usedA distributed data layer, chosen deliberatelyDistributed SQL, wide-column, cache, object storage and vectors β€” each for a reason

Questions we get asked

Other App Development work

Custom web applicationsThe system your business actually runs on, built properlyAPI and integration developmentMaking two systems agree, including the one with no documentationMobile applicationsCross-platform where it makes sense, native where it does notAI and retrieval systemsAssistants that read your documents, and know what they are not allowed to read
All App Development

Tell us what you are trying to do

A short conversation is usually enough to tell whether we are the right people. If we are not, we will say so and point you somewhere better.

Start a conversationI already use KamoCRMHow we quote