Service

Kubernetes Consulting

Strategy, architecture and platform design for Kubernetes done properly.

Engagement

Beginning atUS $1,200 / day

Begin an engagement ← All services

Most Kubernetes difficulties originate in architecture and operating practice rather than in Kubernetes itself. We help you design cluster topologies, platform conventions and operational practices that your own engineers can run in production.

What you get

  • Cluster architecture for production: networking, storage, identity, multi-tenancy
  • Platform engineering: golden paths, internal developer platforms, GitOps
  • Cost, scaling and capacity strategy across regions and providers
  • Security baselines, supply-chain hardening, policy enforcement
  • Migration planning from legacy or hyperscaler-managed clusters

Ideal for

Teams running, planning, or rescuing Kubernetes in production.

The engagement

What Kubernetes consulting actually covers.

Kubernetes is not difficult to install. It is difficult to own. An organisation that has stood up a cluster has not yet decided how many clusters it will run, how tenants are separated, where state lives, who is permitted to deploy, what happens when a node is lost at three in the morning, or how the version it is on becomes the version it will be on next year. Those decisions are the substance of a Kubernetes consulting engagement, and nearly all of them are expensive to revisit once workloads are running.

We are engineers who operate a Kubernetes platform of our own. Bahriya is a public cloud built on the Bahriya Kubernetes Engine, and the same people who carry its pager do the consulting. The advice on this page is therefore advice we have to live with, which is a different discipline from advice that is delivered and departs.

An engagement produces written architecture, not a slide deck. The deliverables are the cluster topology, the decisions behind it recorded as architecture decision records, the platform conventions your teams will work inside, and a plan your engineers can execute. Where it is faster for us to implement alongside them, we do.

Starting points

Four situations that bring organisations to a Kubernetes consultancy.

The first production cluster

A proof of concept has succeeded and the organisation now has to run the result under a real availability commitment. The work is to settle the decisions that are fixed for the life of a cluster before they are fixed by accident: the network model and its address space, the storage class and what a stateful workload is permitted to assume, the identity provider, and whether one cluster or several is the correct answer for the way the business is organised.

A cluster that runs but has no owner

The engineer who built it has left, the version is two releases behind, and nobody is confident enough to upgrade it. The work here begins as an assessment: what is actually deployed, what it depends on, what would happen if a control-plane node were lost today, and which of the accumulated deviations from upstream are load-bearing. The output is a remediation sequence ordered by risk, not by ease.

A migration, in either direction

From a hyperscaler's managed Kubernetes to on-premise, usually for data residency; or from on-premise into a managed service, usually for cost. Both are the same exercise: enumerate what the current control plane does on your behalf, decide where each of those responsibilities lands afterwards, and sequence the move so that the estate keeps serving traffic. Most migration failures are failures to enumerate.

A platform that outgrew its conventions

Six teams deploy in six different ways, each defensible when it was introduced. The cost is not aesthetic: it is that no single engineer can now reason about a production incident. The work is platform engineering — a golden path that is genuinely easier to follow than to avoid, GitOps as the single route to production, and a set of conventions with an owner.

Method

How a Kubernetes consulting engagement runs.

  1. Phase 01 · Typically five days

    Assessment

    We read the estate rather than ask about it: the clusters, the manifests and charts that populate them, the pipelines that apply them, and the monitoring that watches them. The output is a written assessment of the architecture as it is, a list of findings ordered by the loss each would cause, and an estimate of the effort to close them. It is deliberately readable by a CTO and by an engineer, because both have to act on it.

  2. Phase 02

    Architecture and decisions

    Cluster topology, tenancy model, network and storage design, identity and access, the security baseline, and the backup and recovery position. Each significant decision is recorded as an architecture decision record naming the options considered, the choice, and the reason. That record is what allows a future engineer to revisit the decision knowingly rather than reverse it by accident.

  3. Phase 03

    Platform conventions

    The golden path from a developer's commit to a running workload: repository layout, chart or manifest conventions, the GitOps mechanism, environment promotion, secret handling, and the policy set that enforces the baseline without requiring a review meeting. A convention that is not enforced automatically is a preference, and preferences decay.

  4. Phase 04

    Implementation alongside your engineers

    We build the first instance of each pattern with your team rather than for them, because a pattern nobody on staff has implemented is a pattern nobody on staff can extend. Where the work requires software that does not exist — an operator, a controller, a chart library — it moves to Kubernetes development and is quoted against scope.

  5. Phase 05

    Handover, and what follows

    Runbooks for the failure modes the design admits, a review of the monitoring against them, and a named engineer who remains reachable. Organisations that want that reachability to be contractual move to a Kubernetes support contract; organisations that would rather not operate the platform at all move to managed Kubernetes on premise.

Region

Kubernetes consultants in the same jurisdiction as the cluster.

We are based in Dubai and work across the United Arab Emirates, Saudi Arabia, Bahrain, Qatar, Kuwait and Oman. For most estates that is a convenience. For a regulated one it is a requirement: a consultant who reads your configuration has read your architecture, and several regional regulators treat that as a disclosure with a jurisdiction attached.

The practical difference is smaller and more immediate. An incident review at 09:00 Gulf Standard Time is a conversation rather than a document exchanged across eight hours of time difference, and an on-site week is a short flight rather than a line item.

Scope

What we decline.

  • Staff augmentation by the seat. We do not place engineers into a client's reporting line to be directed as capacity. The day rate buys a principal engineer's judgement, which is not a thing that can be supervised.
  • Kubernetes where it is not warranted. A team of four running three services does not need it, and an assessment that concludes so is a successful assessment. We will say this before the engagement rather than after it.
  • Work we cannot finish. We are a small firm and we accept engagements against our actual capacity. A declined engagement is cheaper for both parties than a subcontracted one.

Questions

Common questions about Kubernetes consulting.

What does a Kubernetes consulting engagement cost?
Consulting is billed at US$1,200 per day, and the rate does not change with the seniority of the person assigned, because the person assigned is a principal engineer in every case. A first assessment is normally five days. Longer engagements are quoted as a number of days against an agreed scope, not as a fixed-price project with a change-order mechanism attached.
How short an engagement will you take?
One day, for a second opinion on a design or a review of a decision already taken. Work of that length is most useful when a specific question is in front of you — whether to run one cluster or several, whether a service mesh is warranted, whether an architecture will survive the regulator. A general health assessment needs five days to be worth anything.
Do we have to use the Bahriya Kubernetes Engine?
No. Kubernetes consulting is distribution-neutral, and most of it is spent on estates running EKS, AKS, GKE, OpenShift, Rancher or plain kubeadm. BKE is recommended where an on-premise distribution is being selected and the sovereignty requirement is real, and not otherwise.
Will you work with our existing team, or replace them?
We work with them. The purpose of a consulting engagement is that your engineers can operate the result after we leave, which means they have to be in the room while it is designed. Where a team is short-handed rather than short of knowledge, a support contract or a managed service is the more honest answer than consulting days.
Do you work on site, or remotely?
Both. Assessment and design work benefits from being on site for the first week, because the informative conversations are the unscheduled ones. Implementation support is usually remote. We are resident in the UAE and travel across the GCC, so an on-site week does not carry an intercontinental cost.
Can you help us migrate off a hyperscaler?
Yes, and it is a frequent reason organisations in the region call. The work is a migration plan before it is a migration: an inventory of what the managed control plane was doing on your behalf, a decision on where each of those responsibilities lands, and a sequence that keeps the estate serving traffic throughout. The reverse direction, from on-premise to a managed service, is the same exercise run backwards.
What do you need from us before starting?
Read access to the clusters, the repositories that deploy to them, and the monitoring. An architecture that is described rather than observed is an architecture as someone intended it, not as it is, and the gap between the two is usually where the problem is.

The rest of the practice

Consulting is one of five ways to engage us.

The same engineers deliver all five. Most engagements begin as one of them and become another once the estate is understood.

Enterprise Architecture as a Service

A senior architect on call, paid for by the day.

Read the engagement model →

Kubernetes Development

Custom operators, charts, controllers and the long maintenance tail.

Read the engagement model →

Kubernetes Support

A Kubernetes support contract with named engineers and a defined response time.

Read the engagement model →

Managed Kubernetes on Premise

A fully managed Kubernetes practice running inside your own data centre, on BKE.

Read the engagement model →

Small teams. Plain contracts. Real architects.

Talk to us Back to services