Service consumers use Platform Mesh to discover, order, and manage service capabilities. They work with declarative resources in their own account workspaces instead of learning every provider’s runtime and operational interface.
Consumers include developers, data scientists, application owners, and any team that needs to use a capability — a database, a certificate, a Kubernetes cluster, an AI inference endpoint — without operating it themselves.
Consume services through a consistent Kubernetes Resource Model interface, with clear ownership boundaries between consumer intent and provider implementation.
The consumer owns the request — the desired-state resources in their account workspace and the application code that uses the resulting capability. They do not own the provider runtime or the underlying service implementation. The control plane mediates everything in between: the consumer writes spec, the provider writes status, and Platform Mesh delivers each side to the other across the account boundary.
Consumers can interact with their workspace through different surfaces, all of which work against the same Kubernetes Resource Model:
kubectl and standard Kubernetes tooling for command-line workflows.The choice of surface does not change the underlying API or the ownership boundary.
kubectl, GitOps, IaC, or the portal for this workflow?Start with Explore the example MSP for a guided walkthrough of the consumer experience. Then read Interaction patterns to understand how providers and consumers connect, Account model for how consumer accounts are structured, and API sharing for how provider APIs become available in the consumer workspace.