Multi-tenant Internal Platform
The final case is an internal developer platform: a platform team serving many product teams on shared Kubernetes infrastructure. The product here is not an application but the platform itself — and its success is measured by adoption, not features.
It pulls together tenancy, quotas, RBAC, policy, GitOps, and golden paths into a system whose hardest problems are as much organizational as technical.
Platform as a Product
The defining mindset is treating the platform as a product with internal customers. Product teams want to ship, not to learn Kubernetes; the platform's job is to make the right way the easy way. Success is teams adopting it because it is genuinely easier than going around it — a platform engineers route around has failed, however elegant. This framing drives every decision toward developer experience and self-service.
Tenancy Model
The tenancy decision is foundational: namespace-per-team on shared clusters (soft tenancy) versus cluster-per-team (hard isolation). Most internal platforms use soft tenancy — namespaces with ResourceQuotas, LimitRanges, scoped RBAC, and NetworkPolicies (Topic 52) — because the teams are cooperating and the operational cost of many clusters is high. Sensitive or noisy workloads may get dedicated node pools or clusters. The model is chosen for the trust level and cost, then enforced consistently.
Golden Paths and Guardrails
Two mechanisms make a platform usable and safe. Golden paths are paved, opinionated workflows — templates, scaffolding (Backstage-style), and CI/CD wiring — so a team can go from repo to running service without bespoke Kubernetes knowledge. Guardrails are the policies that keep self-service safe: admission policy (Topic 36) enforcing image sources and required labels, quotas, and RBAC. The art is balance: guardrails strict enough to be safe, loose enough that teams don't route around them.
| Mechanism | Purpose |
|---|---|
| Golden paths | Paved workflows: templates, scaffolding, CI/CD wiring |
| Quotas / LimitRange | Fair resource sharing across teams |
| RBAC per namespace | Each team manages only its own space |
| Admission policy | Enforce image sources, labels, security baseline |
Self-Service and the Org — Alternatives
The line between self-service and platform-managed defines the platform's shape: teams self-serve deployments, config, and scaling within guardrails, while the platform team owns clusters, upgrades, shared services, and the golden paths. GitOps is usually the interface — teams change their app's repo, the platform reconciles. What I'd do differently / alternatives: the common failure is building a heavyweight platform nobody adopts; starting smaller, with one golden path teams actually want, beats a grand abstraction. The alternative of buying an internal-PaaS product (or using a managed platform) is real and worth weighing against building — many teams over-build what they could have bought.
Build (IDP on Kubernetes) — tailored golden paths and full control — significant platform-team investment, risk of low adoption.
Buy / managed PaaS — faster, less to operate, less tailored — worth weighing seriously before building.
- Building a heavyweight platform teams don't adopt because going around it is easier.
- Choosing hard per-team clusters when soft namespace tenancy would meet the trust level at lower cost.
- Guardrails so strict that teams route around the platform entirely.
- No golden paths, so every team reinvents Kubernetes onboarding from scratch.
- Over-building a bespoke platform that a managed product or PaaS could have provided.
- Treat the platform as a product; measure success by adoption, not feature count.
- Default to soft namespace tenancy with quotas/RBAC/NetworkPolicy; escalate only where trust requires.
- Provide golden paths so teams go repo-to-running without deep Kubernetes knowledge.
- Set guardrails (admission policy, quotas) strict enough to be safe, loose enough to keep adoption.
- Start small with one path teams want; weigh buying/managed against building before investing big.
Knowledge Check
How is the success of an internal developer platform best measured?
- Adoption — teams using it because it is genuinely easier than going around it
- The sheer number of features and self-service knobs it ships
- The total number of production clusters it provisions and runs
- How much deep Kubernetes and YAML knowledge it requires of every single user
What are golden paths in a platform?
- Paved, opinionated workflows (scaffolding, wired CI/CD) taking teams repo-to-running
- The fastest, lowest-latency network routes the CNI picks between Pods running on the same node
- Dedicated, fully isolated clusters handed out only to the most senior engineering teams in the org
- A built-in type of cluster-scoped RBAC role you bind to a tenant's service account
What is the common failure mode of internal platforms?
- Building something heavyweight that teams don't adopt because going around it is easier
- Using namespace-per-team soft tenancy instead of dedicated clusters
- Providing too few clusters for the teams that need isolation
- Enforcing any admission-policy, RBAC, or resource-quota guardrails at all on tenants
You got correct