Cloud Native Platforms

A cloud native platform gives application teams a consistent way to obtain and use the capabilities their software needs. Those capabilities may include compute, storage, databases, delivery pipelines, identity, secrets, and telemetry. The platform connects them through interfaces designed for its users.

The platform is not one product. It is an integrated collection of capabilities. It may use Kubernetes, cloud services, open source projects, and internal systems. What makes the collection a platform is the coherent experience it presents.

Why a platform exists

Cloud services give teams many building blocks. That choice can also push infrastructure work onto every application team. Each team may need to learn provisioning, delivery, security, and observability systems before it can ship a service.

A platform team handles common integration work once. It exposes supported paths that application teams can use repeatedly. This can reduce duplicated work and cognitive load. It can also place security and operational controls into shared templates and services.

The platform sits between users and capability providers:

application teams
       |
       | portals, APIs, CLIs, templates, documentation
       v
cloud native platform
       |
       | integrated contracts and automation
       v
cloud services, clusters, delivery tools, data systems

The platform does not need to own every provider. A managed database may remain a cloud service. The platform can provide a standard request, approved configuration, credentials, documentation, and support model around it.

Treat the platform as a product

Application teams are platform users. Their needs determine which capabilities matter and how those capabilities should be presented. A platform roadmap should therefore start with user problems, not a tool inventory.