A one-line configuration change can take down every route
All ingress shares a controller, nothing validates resources before they reach the cluster, and the blast radius of a typo is the whole platform.
Solutions · SaaS platforms
SaaS & internet platforms
Multi-tenant isolation, unpredictable growth, and a cloud bill that scales faster than revenue.
What makes this sector awkward
Growth is unpredictable, tenants must be genuinely isolated, and the platform cost is a first-order line in the business model rather than an infrastructure detail. The engineering team is small and every hour spent operating the platform is an hour not spent on the product.
Kubernetes with enforced tenant boundaries, an edge and firewall tier whose failover has been measured, autoscaling that responds to real signals, and cost attribution per team.
Four situations we see constantly
If two or three of these describe your environment, the audit is worth the money. If all four do, it is overdue.
Tenant isolation is a convention
Namespaces and a review process. It holds while everyone follows the process, which is not the same as holding.
Nobody can say what a namespace costs per month
The cloud bill is analysed per account, not per team. Feature decisions are made without knowing what they cost to run.
The firewall pair has never failed over
The control plane everybody depends on is an HA pair that has been in service for years without a failover test.
Four phases, each useful on its own
Sequenced so that stopping after any phase leaves you better off rather than stranded mid-migration.
- 01
Make the platform observable by team
Attribute cost and capacity per namespace and per service, at a granularity that can inform a product decision.
You end up withCost per namespace per month, and the noisy-neighbour workloads named.
- 02
Constrain the blast radius
Add admission validation so a bad resource does not reach the cluster, and separate controllers where isolation actually matters.
You end up withA tested recovery from a deliberately broken route, and a documented answer to what a bad change can reach.
- 03
Turn isolation into enforcement
Move tenant boundaries into policy, network policy and resource quota, so they hold when someone makes a mistake.
You end up withIsolation that survives a misconfiguration rather than depending on review.
- 04
Test the parts everybody forgot
Fail over the firewall pair, the load balancer and the ingress tier. Time each one under real traffic.
You end up withMeasured failover for every shared tier, with the previously untested ones now on a drill schedule.
The capability behind it
Each discipline has its own page with the technology stack, the acceptance criteria and an explicit scope boundary.
Managed Kubernetes & Container Platform Services
A cluster you can upgrade without holding your breath, whose etcd backup you have actually restored, and which you could rebuild from code in under an hour.
upstream kubeadm 1.31–1.34 · Kubespray · RKE2 · K3sNetwork Cluster Engineering — Firewall, Switch & Router High Availability
Firewall pairs that actually fail over on purpose, switch stacks and MLAG pairs that neither loop nor blackhole when a member dies, and routers whose routing convergence you have measured instead of assumed.
Arista EOS · Cumulus Linux · SONiC · Cisco NX-OS (vPC)Observability & Logging Cluster Engineering
Metrics, logs and traces that survive a node loss, alert on things that matter, and cost less than the infrastructure they watch.
Prometheus 2.5x · Thanos · Grafana Mimir · VictoriaMetricsLoad Balancing, Ingress & Traffic Engineering
Traffic enters your infrastructure once, and it enters through a design you can explain, test with real numbers, and renew certificates without anyone waking up.
LVS / IPVS (DR, TUN, NAT) · DPVS · Katran (eBPF/XDP) · Nginx streamHow this looks in practice
Research institute · North America
Forty machines, one Git repository, no one logging in by hand
12 min · per-node bring-up, measured on all 40
Read the engagement → B2B SaaS · North AmericaA cluster nobody dared upgrade, rebuilt so upgrades became routine
49 min · measured control-plane upgrade, zero dropped requests
Read the engagement → Logistics technology · EUThree major versions crossed, one workload restarted on purpose
3 · major hops completed in planned windows
Read the engagement →Every case in this library is a representative engagement, written from our delivery patterns and marked as such. We do not present unnamed work as a named customer.
What we measure in this sector
These are the numbers we put in the delivery report. If we cannot measure it, we do not promise it.
- Zero-downtime control-plane and platform upgrades
- Firewall and load-balancer failover tested and timed, not assumed
- Cost per namespace per month, attributable to a team
- Ingress blast radius documented and constrained by admission policy
What we don't do
Every vendor says yes to everything. Here is where our answer is no, or where someone else needs to be in the room. If this list looks wrong for your situation, tell us — we would rather argue about scope before the contract than after.
- Out of scope
Application architecture, feature development and code review
We build and operate the platform. Application design decisions stay with your team, though we will happily argue about them over the platform boundary.
- Out of scope
SOC 2 audit execution
We implement the technical controls and produce evidence. The audit and the report belong to a licensed auditor.
- Requires partner
Cloud cost negotiation with your provider
We can analyse and reduce consumption. Committed-use negotiation depends on your commercial relationship and your provider.
- Included
Cluster lifecycle, isolation enforcement, cost instrumentation and on-call
Including the drill schedule for tiers that had never been tested.
SaaS platforms specifics
We are already on managed Kubernetes. What is left for you to do?
The parts the platform does not cover: tenant boundaries that are enforced rather than agreed, cost attribution per team, blast-radius control on shared ingress, and failover testing for the tiers everyone assumed were fine.
Can you reduce our cloud spend?
Often, and usually not by moving providers. Right-sizing, storage tiering, and finding the workloads that are paying for capacity they never use. We will quantify it before recommending a migration.
Do you take over on-call entirely?
On the Mission-Critical tier we take 24×7 response for the cluster layers we own, with a named engineer and a contractual response target. Your application remains yours — we will be explicit about where that line sits.
The engineering transfers, the constraints do not
Financial services & fintech Regulated, audited, and unforgiving of downtime. Every change needs evidence. Healthcare & life sciences Imaging volumes grow faster than budgets, and patient data has strict handling rules. Media & entertainment Render and transcode farms starved by storage, with peaks that double overnight. AI startups & ML teams Expensive accelerators, unstable multi-node training, and no proof of where the time goes. Research & higher education Slurm on one side, Kubernetes on the other, and a budget committee in the middle. Manufacturing & edge fleets Dozens of small sites, intermittent connectivity, and nobody on site who can debug a node.
Want this looked at against your saas platforms environment?
Thirty minutes, no slides. Bring the awkward constraint — that is usually the interesting part.