CNCF Platforms White Paper

The following article is a Gemini translation of the CNCF Platforms White Paper.

Original: https://tag-app-delivery.cncf.io/whitepapers/platforms/

Introduction

Inspired by the cross-functional cooperation promised by DevOps, ‘platform engineering’ has begun to emerge within enterprises as an explicit form of that cooperation. Platforms curate and provide foundational capabilities, frameworks, and experiences to facilitate and accelerate the work of internal customers such as application developers, data scientists, and information workers. Especially in the field of cloud computing, platforms are helping enterprises realize the long-promised values of the cloud, such as faster product release, portability across infrastructure, safer and more resilient products, and higher developer productivity.

This white paper is written to support enterprise leaders, enterprise architects, and platform team leaders in advocating, investigating, and planning internal platforms for cloud computing. We believe that platforms significantly impact an organization’s actual Value Streams, but in an indirect way. Therefore, executive alignment and support are essential for the long-term sustainability and success of platform teams. This document will enable such support by discussing what the value of platforms is, how to measure that value, and how to implement platform teams that maximize value.

Why Platforms?
What is a Platform?
Attributes of a Successful Platform
Attributes of a Successful Platform Team
Challenges in Platform Implementation
How to Measure Platform Success
Platform Capabilities

Why Platforms?

Today, in the world of cloud computing, platforms and platform engineering are popular topics. Before diving into definitions, technologies, and measurement methods for building platforms, it’s important to first explore what value platforms bring that generates this interest.

Process improvements over the last two to three decades have significantly enhanced the agility of software application and product teams. They have been flexibly provided with infrastructure services like compute, network, and storage, as well as developer services such as build, test, deployment, and observability. However, this autonomy and process improvement paradoxically led to the gradual shifting of responsibility for supporting services to product teams. As a result, product teams spent increasing amounts of time and cognitive energy on infrastructure issues, reducing the time spent producing tangible value for the organization.

The desire to allow delivery teams to focus on their core work and reduce redundant efforts across the organization has motivated enterprises to implement platforms for cloud-native computing. By investing in platforms, organizations can gain the following benefits:

Reduce cognitive load for product teams, accelerating product development and deployment.
Improve the reliability and resilience of products that depend on platform capabilities, by having experts configure and manage those capabilities.
Accelerate product development and deployment by enabling multiple teams within the enterprise to reuse and share platform tools and knowledge.
Reduce the risk of security, regulatory, and functional issues in products and services by bringing platform capabilities and their surrounding users, tools, and processes under governance.
Enable cost-effective and productive use of services by maintaining control over the user experience while delegating implementation to public cloud and managed service providers.

These benefits arise partly because a small number of platform teams serve a larger number of product teams, multiplying their impact; partly because platform teams consolidate common functional management, facilitating governance; and finally, because platform teams emphasize user interface and experience above all else.

Platform expert teams not only reduce the common tasks required of product teams but also optimize the platform capabilities used in those products. Furthermore, platform teams maintain widely used conventional patterns, knowledge, and toolsets across the enterprise, enabling developers to quickly contribute to other teams or products built on the same foundation. Shared platform patterns allow for embedding governance and control features within templates, patterns, and capabilities. Finally, platform teams manage providers and deliver a consistent experience, allowing for the efficient use of public cloud and service providers for foundational but undifferentiated functions like databases, identity access, infrastructure operations, and app lifecycle.

What is a Platform?

A platform for cloud-native computing is an integrated set of capabilities defined and presented according to the needs of its users. It is a cross-cutting layer that ensures a consistent experience when acquiring and integrating common capabilities and services for various applications and use cases. A good platform provides a consistent user experience for consuming and managing capabilities and services, such as web portals, project templates, and self-service APIs.

According to Atlassian[1], “Platform teams create capabilities that can be consumed by numerous stream-aligned [product] teams with minimal overhead. Platform teams minimize the resource and cognitive load on product teams and can create a cohesive experience across different user experiences or products.”

According to Martin Fowler and Evan Bottcher[2], “A digital platform is a foundation of self-service APIs, tools, services, knowledge, and support, arranged as a compelling internal product. Autonomous delivery teams can make use of this platform to deliver product features at a faster pace with reduced coordination.”

The specific set of capabilities and scenarios supported by a platform should be determined by the needs of stakeholders and users. It’s important to note that while a platform provides these essential capabilities, the platform team does not always have to implement them directly. Managed service providers or dedicated internal teams can maintain backend implementations, and the platform acts as the ‘thinnest reasonable layer’ that provides consistency across the provided implementations and meets organizational requirements. For example, a very simple “platform” might just be a wiki page with links to standard operating procedures for provisioning capabilities from providers[3].

Because these platforms are intended solely for internal users within an enterprise, we often refer to them as Internal Platforms.

Platforms are particularly important in cloud-native architectures because they more clearly separate supporting capabilities from application-specific logic than previous paradigms. In environments like the cloud, resources and capabilities are often managed independently and integrated with custom business components. These resources can include databases, object stores, message queues, observability collectors and dashboards, user directories, and authentication systems. Internal platforms provide these resources in a way that enterprise teams can easily integrate them into their applications and systems.

Platform maturity

At its most basic stage, an internal platform provides a consistent experience for acquiring and using individual services such as pipeline runners, database systems, or secret stores. As it matures, an internal platform offers compositions of these services as self-service templates for major scenarios like web application development or data analysis (MLOps).

The use cases an enterprise can achieve through a platform can evolve as follows:

Product developers can provision and immediately use capabilities such as compute, storage, databases, or identity as needed to run their systems.
Product developers can provision service spaces as needed and use them to run pipelines and jobs, store artifacts and configurations, and collect telemetry.
Third-party software administrators can provision essential dependencies like databases as needed and easily install and run their software.
Product developers can provision complete environments from templates that combine runtime and development-time services required for specific scenarios like web development or MLOps.
Product developers and managers can observe the functionality, performance, and cost of deployed services through automated instrumentation and standard dashboards.

Refer to the Platform Engineering Maturity Model created after this white paper was first published.

By providing a consistent and compliant experience for individual capabilities or their compositions, internal platforms ultimately enable users to deliver valuable products more easily and efficiently.

Attributes of a Platform

After defining what a platform is and why it should be built, let’s identify some key attributes that contribute to its success.

Platform as a product: A platform exists to meet user needs and, like any other software product, should be designed and evolved based on those needs. The platform should provide the capabilities necessary to support the most common use cases across product teams, prioritizing common capabilities over specific ones used by only a single team to maximize delivered value.
User experience: The platform should deliver capabilities through consistent interfaces and focus on the user experience. The platform should strive to meet users where they are (GUI, API, CLI, IDE, portals, etc.). For example, a product owner might use a web portal, a developer an IDE, and a tester a CLI to consume the same deployment capabilities.
Documentation and onboarding: Documentation is key to any successful software product. The platform should come with appropriate documentation and examples that meet user needs. It should also provide new project onboarding tools to help users consume platform services quickly and simply. These bundles are often referred to as the Golden Path.
Self-service: The platform must be self-serviceable. Users should be able to autonomously and automatically request and receive capabilities. This is a critical characteristic for platform teams to support and scale across multiple product teams.
Reduced cognitive load for users: A primary goal of a platform is to reduce the cognitive load on product teams. The platform should encapsulate implementation details and hide architectural complexities that may arise. Users should not be responsible for operating the services provided by the platform (e.g., they should not need to manage the database server itself).
Optional and composable: A platform is meant to increase efficiency, not hinder it. The platform should be composable, allowing product teams to use only a subset of the provided functionality. Furthermore, product teams should be able to manage their own capabilities outside the platform if necessary.
Secure by default: The platform should be secure by default, providing capabilities that ensure compliance and validation according to rules and standards defined by the organization.

Attributes of a Platform Team

Platform teams are responsible for the interfaces and experiences of platform capabilities, such as web portals, custom APIs, and Golden Path templates. On one hand, they collaborate with teams implementing infrastructure to define a consistent experience, and on the other hand, they work with product teams to gather feedback and ensure requirements are met.

The main tasks of a platform team include:

Investigating platform user requirements and planning the feature roadmap
Marketing, disseminating, and advocating the proposed value of the platform
Managing and developing interfaces for consuming/observing capabilities and services, including portals, APIs, documentation, templates, and CLI tools

Most importantly, platform teams must continuously learn user requirements to improve the interfaces they provide. Learning methods include interviews, hackathons, issue trackers, surveys, and direct observation through observability tools.

If inbound feedback and thoughtful design are one side of product delivery, the other side is outbound marketing and advocacy. If a platform is built to meet user needs, users will be eager to use it. Platform teams should promote user adoption through internal marketing activities such as announcements, demos, and regular feedback sessions.

Platform teams do not necessarily need to directly operate services such as compute or network. In fact, internal platforms should rely as much as possible on externally provided services and capabilities. Platform teams are primarily responsible for the interfaces (GUI, CLI, API) and user experience through which these services are delivered.

Challenges in Platform Implementation

While platforms promise significant value, they also come with the following challenges:

Platform teams must treat the platform as a product and develop it collaboratively with users.
Platform teams must carefully select priorities and initial partner application teams.
Platform teams must seek support from enterprise leadership and demonstrate their impact on value streams.

Most importantly, it’s crucial to treat the platform as a customer-facing product and recognize that its success depends on the success of its users and products. Platform teams that release features without feedback or rely on top-down mandates to force adoption are likely to face user resistance.

Enabling Platform Teams

Platform teams also face cognitive load due to their diverse responsibilities. It’s crucial to focus the team’s energy on experiences and capabilities unique to the business. Here’s how to reduce the burden on platform teams:

Build the thinnest viable platform layer on top of managed provider implementations.
Leverage open-source frameworks and toolkits to create documentation, templates, and compositions.
Ensure platform teams are adequately staffed for their domain and customer base.

How to Measure Platform Success

Platform teams should continuously collect user feedback and measure their activities. Measurement metrics include:

User satisfaction and productivity: Active users and retention rate, Net Promoter Score (NPS), and developer productivity metrics such as the SPACE framework[4].
Organizational efficiency: Latency from service request to fulfillment, build and deployment time for new services, and time for new users to submit their first code change.
Product and feature delivery: Tracking DORA metrics (deployment frequency, lead time for changes, time to restore service, change failure rate).

Ultimately, the success of an organization’s products and applications is the true measure of platform success.

Platform Capabilities

A cloud-native computing platform combines capabilities from various supporting providers. The platform acts as a bridge between capability providers and application developers, enforcing security, performance, and cost governance.

Capability domains to consider:

Web Portal: For product and capability observation/provisioning
APIs and CLIs: For automated provisioning
“Golden Path” templates and documentation: To support optimal usage
Build/Test/Deployment Automation
Development Environments: Hosted IDEs, etc.
Observability: Functionality, performance, and cost dashboards
Infrastructure Services: Runtimes, network, storage
Data Services: DB, cache, object storage
Messaging and Event Services
Identity and Secret Management
Security Services: Static/runtime analysis, policy enforcement
Artifact Repositories: Image and package storage

(The subsequent table lists examples of CNCF/CDF projects for each capability, including familiar projects such as Backstage, Kubernetes, Argo, Crossplane, and Prometheus.)