Skip to content

CONCEPT Cited by 1 source

Self-service infrastructure

Self-service infrastructure is the platform-engineering property where product developers can provision and modify their own infrastructure resources — compute, capacity, config — through a declarative interface (CRDs, portal, IaC) without waiting for centralized platform-team approval or ticket queues.

The platform team defines policy (what's allowed, what the limits are, what security guardrails apply); developers exercise it on demand. The approval is encoded in the schema, not in a human.

Why it matters

  • Throughput. A centralized team becomes a serialization point; self-service removes it.
  • Ownership. Developers understand their own capacity needs better than any platform team; decentralized decision-making produces better sizing.
  • Cost attribution. If the requester is the payer, cost pressure reaches the workload owner who can act on it.
  • On-call toil. Every infrastructure ticket routed through a central team is an interrupt; self-service zeros those out.

Karpenter as a self-service unlock

Salesforce's 2026-01-12 post calls out self-service as a headline outcome of the Karpenter migration:

"Developers can now define their own node pool requirements without waiting for centralized approvals, resulting in faster onboarding and greater agility." (Source: sources/2026-01-12-aws-salesforce-karpenter-migration-1000-eks-clusters)

"The migration to Karpenter introduced true self-service infrastructure, allowing developers to define their capacity needs through straightforward node pool declarations."

The mechanism: NodePool is a declarative Kubernetes CRD a developer can author and apply in their own namespace. The platform team shapes what's allowed via admission policies (PDB validation, label conventions, allowed instance types) but doesn't gate individual requests.

This is a sharp contrast to the pre-migration world, where each new workload shape likely needed a new Auto Scaling group / node group defined by Salesforce's centralized Kubernetes platform team.

Two faces of self-service

Good self-service:

  • Declarative. Developer writes the spec; the platform realizes it.
  • Guardrailed. OPA / Kyverno / admission webhooks enforce limits at apply time — "you can request up to 1000 nodes of these instance families, over these subnets, with these labels" — not "submit a request and we'll review."
  • Observable. Developers see their usage, cost, limits.

Bad self-service:

  • Without guardrails — every dev can spin up p4d.24xlarge instances unbounded, nobody sees cost, FinOps catches fire.
  • Slow — *"self-service" but actually queued behind a CI pipeline that takes 40 minutes.
  • Partial — some operations are self-service, some need tickets; developer can never predict which path a request will take.

Seen in

Last updated · 200 distilled / 1,178 read