AI
The Multi-Provider API Lock-In Problem
Every infrastructure provider ships its own management API. AWS, Azure, and specialized compute vendors each expose a different interface for provisioning the same resource. Platform engineers must learn each one, train their teams on each one, and maintain compatibility across all of them. Adding a third provider brings a third flavor of YAML and a third set of operator patterns. The result is platform-level fragmentation: no two teams implement the same service the same way.
KRM as the Shared API Layer
Mirza’s argument: providers already model services as Kubernetes resources, so use the Kubernetes API for more than workload orchestration. Use it to model the management APIs of external services as Kubernetes resources. The Kubernetes resource model gives AI tools and human operators a structured, consistent schema instead of a patchwork of vendor-specific formats. Platform engineers use kubectl and the CRD knowledge they already have. The management API for an S3 bucket becomes a CRD. Provisioning it becomes a kubectl apply.
KCP Workspaces as Lightweight Control Planes
Platform Mesh uses KCP as its backbone. KCP provisions lightweight control planes in under a second. Each control plane is a KCP workspace: an isolated store for resources and their orchestration. External APIs enter via API sync agents or multicluster runtime. Kubines goes further, projecting a resource from a control plane into a real cluster. Deployments in that cluster can then reference secrets or CRDs from the control plane directly, without pods or Deployments running in the control plane itself.
Provider-Agnostic Claims and the Resource Broker
The PVC pattern is the model. A PersistentVolumeClaim says “give me storage.” A StorageClass and CSI driver handle provisioning. Platform Mesh extends this to any Kubernetes-backed service. A claim describes what you want. Providers register as backends. The resource broker sits between them, routing claims and handling provisioning, deprovisioning, and migration. Providers write a YAML file describing their API. The format is intentionally unopinionated. No new standard is imposed; standards should emerge from the community.
Provider Migration Without Object Deletion
In the demo, a certificate claim starts backed by an internal CA. Changing the domain to demo.corp.com triggers the resource broker. The consumer-side UID stays the same throughout. No object was deleted or recreated. On the provider side, the internal CA certificate is removed and the external CA provisions a new one. The broker’s staging area holds both objects during the transition, hidden from the consumer view. This architecture only works because KCP control planes are cheap enough to run per migration operation.
Notable Quotes
we are building yet another platform. Mirza Kopic · ▶ 01:04
extend to 10, 20 providers, 30, it’s MJ / Mangirdas Judeikis · ▶ 14:27
cheap control planes at your disposal. MJ / Mangirdas Judeikis · ▶ 20:05
Key Takeaways
- The PersistentVolumeClaim pattern can extend to any service, letting engineers write provider-agnostic claims in KRM.
- KCP creates control planes in under a second, making staging areas for provider migrations cheap enough to run per-tenant.
- The resource broker migrates live resources between providers without deleting objects, preserving UID stability for consumers.
About the Speakers
Mirza Kopic is Principal Engineer and Lead Architect at SAP. He has worked across analytics, machine learning, and Kubernetes-based platform projects in various engineering and leadership roles.
Mangirdas Judeikis is an independent software engineer and founder of Synpse.com and Faros.sh. He brings over a decade of Kubernetes experience, contributes actively to SIGs, and maintains kcp.io, a CNCF Sandbox project.