Conveying the Importance of Platform as a Product in the Cloud Native Ecosystem

Conveying the Importance of Platform as a Product in the Cloud Native Ecosystem

Speakers: Danielle Cook, CNCF Ambassador; Colin Griffin, Founder and CEO, Crumbware; Simon Fer, Architect and Engineer, Financial Services; Valentina Rodriguez, Principal Architect, Red Hat

Conference: KubeCon EU

YouTube: https://www.youtube.com/watch?v=KtW4HkonQHU

Overview

This KubeCon EU panel discussion, "Conveying the Importance of Platform as a Product in the Cloud Native Ecosystem," delves into a critical paradigm shift in modern software development: treating internal development platforms not as temporary projects, but as enduring products. Moderated by CNCF Ambassador Danielle Cook, the panel—comprising industry experts Colin Griffin, Simon Fer, and Valentina Rodriguez—explores the multifaceted implications of this approach, from strategic alignment with business objectives to the tactical implementation of self-service capabilities and robust governance.

The core premise of the talk is that an internal platform should be developed and managed with the same rigor, user-centricity, and iterative mindset as a commercial software product. This involves understanding user personas, delivering continuous value, measuring success through business outcomes, and fostering a culture of adoption. The discussion highlights how this product-oriented view can unlock significant organizational benefits, driving agility, accelerating feature delivery, reducing cognitive load on developers, and ensuring the platform remains relevant and valuable in an ever-evolving technological landscape, especially with the advent of new technologies like AI.

The importance of this topic cannot be overstated in the current cloud-native era. As organizations increasingly rely on complex distributed systems, the underlying platform becomes a strategic asset rather than a mere operational cost center. By adopting a "platform as a product" mindset, companies can transform their internal infrastructure into a competitive advantage, empowering development teams, streamlining operations, and directly contributing to top-line business growth and risk reduction. The panel provides actionable insights into how to initiate, manage, and mature such a platform, emphasizing the critical role of communication, measurement, and continuous improvement.

Background

▶ Watch: Introduction to Platform as a Product and Panelists (0:00)

The concept of "platform as a product" emerges from a fundamental re-evaluation of how internal development platforms are perceived and managed within organizations. Historically, infrastructure and development tools were often treated as isolated "projects": time-bound initiatives with defined scopes, fixed budgets, and traditional waterfall-style execution. As Simon Fer elaborated, such projects often result in artifacts being "thrown over the fence" to an operations team, leading to a disconnect between builders and operators and a lack of long-term ownership. This project-centric approach often prioritizes initial delivery over sustained value, adaptability, and continuous improvement.

Colin Griffin highlighted the evolution of platform engineering itself, noting it as the development of software engineering competencies within the infrastructure space. Traditionally, core IT or infrastructure teams focused on simply keeping systems alive. However, as businesses become more technical, there's a growing realization that infrastructure can be a "core engine" of the business, not just a support function. This shift necessitates a more strategic approach, where the platform actively contributes to business growth rather than merely enabling it passively.

The problem that "platform as a product" seeks to address stems from several challenges inherent in the traditional model:

• Difficulty in Justifying Investment: Platforms, especially internal ones, can be expensive. Without a clear articulation of their business value, securing and sustaining investment can be difficult. Engineers often need to develop internal "selling" skills, building a business case that translates technical needs into organizational benefits.
• Lack of Business Alignment: Platforms built without a product mindset can become disconnected from overarching business goals. They might optimize for technical metrics (like uptime) rather than business outcomes (like increased annual recurring revenue or faster market entry).
• User Dissatisfaction and Cognitive Load: If a platform isn't designed with its users (developers, data scientists, security teams) in mind, it can become cumbersome, increasing cognitive load and hindering productivity rather than accelerating it.
• Inadequate Security and Governance: Security and compliance are often bolted on or managed reactively in a project-driven model. A product approach integrates these aspects proactively, ensuring policy enforcement and guardrails are built into the platform's fabric.
• Stagnation and Inflexibility: A platform treated as a finished project struggles to adapt to changing organizational needs or the rapid pace of technological innovation. It needs to be iterative and continuously evolve.

The CNCF Platforms Working Group and the associated Platform Engineering Maturity Model, frequently referenced during the talk, provide a structured framework for organizations to navigate this journey. This model emphasizes aspects like adoption, investment, and measurement, guiding teams to build platforms that are not only functional but also strategically valuable and continuously improving.

Key Findings

▶ Watch: Key differences: Platform as a Project vs. Product (3:30)

The panel discussion yielded several crucial findings regarding the successful adoption and implementation of a "platform as a product" strategy within the cloud-native ecosystem:

1. Fundamental Shift from Project to Product: The most significant finding is the imperative to view internal platforms as products. Unlike time-bound projects with fixed outcomes, a product is iterative, continuously evolving based on user needs, and supported by consistent teams responsible for both building and operating it. This longevity and continuous funding model are essential for sustained value delivery.

1. Unwavering Business Goal Alignment: A platform's success hinges on its direct alignment with core business objectives, extending beyond mere technical efficiency. As Colin Griffin emphasized, the platform must "move the needle for the business," contributing to goals like increasing Annual Recurring Revenue (ARR) or outperforming competitors. This requires engineers to understand and articulate the platform's value in business terms, making it easier to secure and justify investment.

1. Persona-Centric Design and Engagement: Successful platforms are built by deeply understanding and actively engaging with all their users, not just developers. Valentina Rodriguez highlighted the importance of identifying diverse personas—including data scientists, security teams, business analysts, and project managers—and incorporating their needs into the platform's design. This inclusive approach fosters adoption and ensures the platform addresses a broad spectrum of organizational requirements, creating a "big cultural shift."

1. Self-Service as a Scaling and Empowerment Mechanism: Effective platforms empower users through self-service capabilities, reducing reliance on central platform teams and significantly lowering cognitive load. Valentina detailed how this enables developers to provision resources like ephemeral clusters for experimentation (e.g., AI applications) or configure namespaces with observability or service mesh features independently. By embedding operational knowledge, best practices, and organizational guardrails into templates and configuration as code (e.g., via GitOps), platform teams can scale their impact without scaling linearly in headcount.

1. Integrated Security and Governance: Security and governance are not optional add-ons but core, non-negotiable features of a platform as a product. Simon Fer underscored the necessity of a technical implementation of policy, citing examples like enforcing approval workflows for production releases through GitOps PRs. Colin Griffin added that the platform's design should facilitate secure interaction between teams, often without them explicitly realizing the underlying security mechanisms, thereby amplifying ROI.

1. Measuring Success Through Consuming Team Outcomes: Traditional metrics like uptime are insufficient. The panel stressed that platform success should be a rollup of the success metrics of its consuming teams. Colin Griffin suggested fostering a friendly competition by showing that teams adopting the platform increase their ROI (e.g., by 50%), thereby driving internal demand. The Platform Engineering Maturity Model provides a framework for defining and understanding these crucial metrics, emphasizing that "we are all unique and different" and need to define what makes our organization tick.

1. Agility and Iteration for Future Readiness: The "product mindset" inherently fosters agility and continuous iteration, making platforms ready for emerging technologies and changing workloads. Valentina Rodriguez highlighted how this approach is vital for supporting new domains like AI/ML, by understanding the unique personas (AI engineers, MLOps specialists, data scientists) and abstracting the underlying complexity (e.g., Kubernetes) so they can focus on their core tasks (model building and training). Simon Fer even posited that "we really can't do AI without the capabilities of cloud native," emphasizing the platform's foundational role.

Technical Deep Dive

▶ Watch: Aligning platform capabilities with business objectives (4:40)

The discussion around "platform as a product" is deeply rooted in technical implementation strategies that support its core principles. The panelists outlined several key technical components and approaches:

At its heart, Platform as a Product is defined as running an internal platform "the same way that we are running our product development," focusing on integrating frameworks and core systems to support business processes. This means moving beyond ad-hoc scripts and fragmented tools to a cohesive, engineered system.

A critical enabler for this product approach is self-service. Valentina Rodriguez emphasized that defining what self-service means for an organization is the first step. Technically, this translates to removing blockers and reducing cognitive load for developers. For instance, instead of waiting for an operations team, developers should be able to spin up ephemeral clusters quickly for experimentation—a crucial capability for exploring new areas like AI application development without consuming excessive resources on persistent development clusters. Similarly, configuring specialized environments, such as a namespace with observability or a service mesh, should be a self-service action, perhaps through a user interface or programmatic API provided by the platform.

To achieve this, the platform leverages principles of configuration as code and GitOps. Valentina explained that taking "operational knowledge," "best practices," and "organizational guardrails" and encapsulating them into templates allows for consistent and repeatable self-service. These templates, when combined with GitOps workflows, ensure that the desired current state of a cluster or application environment is always maintained. Simon Fer reinforced this by noting that GitOps can be used for technical means of gatekeeping, such as controlling "who can approve a PR that allows us to go and merge a branch that leads to production," thereby enforcing security and governance policies directly within the development workflow.

The panel also highlighted the importance of understanding and measuring existing processes. Value Stream Mapping was suggested by Valentina as a technique to identify bottlenecks and quantify waiting times, helping platform teams pinpoint where self-service capabilities would deliver the most impact.

For the platform to truly function as a product, it must have a well-designed user experience. Colin Griffin stressed the importance of implementing UI/UX processes within platform engineering. This ensures that the platform is intuitive, easy to use, and facilitates seamless interaction between different user personas (e.g., developers, security teams, data scientists) even if they're not directly aware of the underlying connections. A good UI/UX abstracts complexity, allowing users to focus on their core tasks.

When discussing the future, particularly the integration of AI workloads, the technical underpinnings of cloud native were deemed indispensable. Simon Fer controversially stated that "we really can't do AI without the capabilities of cloud native." This implies a reliance on scalable, elastic infrastructure provided by cloud-native technologies like Kubernetes for managing compute-intensive AI training and inference workloads. The platform's ability to abstract this complexity, allowing AI engineers and data scientists to focus on model building rather than Kubernetes intricacies, is a key technical contribution. The panel also alluded to Team Topologies principles, specifically moving towards "X as a service" models, to accelerate iteration and speed, which is critical for rapidly evolving fields like AI.

Finally, DORA metrics (Deployment Frequency, Lead Time for Changes, Mean Time to Restore, Change Failure Rate) were mentioned by Simon Fer as a starting point for measuring the effectiveness and efficiency of the platform. While not a complete solution, they provide initial quantitative insights into how the platform is enabling faster, more reliable software delivery.

Demo / Proof of Concept

▶ Watch: Making a business case for platform investment (5:20)

This session was presented as a panel discussion, a conversational format among industry experts. As such, it did not include a live demonstration or a technical proof of concept of a platform or its specific features. The insights shared were based on the speakers' extensive experience and observations within the cloud-native and platform engineering domains.

Defensive Implications

▶ Watch: Understanding business operations to drive platform growth (6:00)

Adopting a "platform as a product" mindset has profound defensive implications, fundamentally shifting security and governance from reactive measures to proactive, integral components of the development lifecycle. The panel highlighted several ways this approach strengthens an organization's security posture:

1. Security by Design and Policy Enforcement: Rather than bolting security on after development, the platform as a product embeds security from the outset. Simon Fer explicitly stated the need for a technical implementation of policy. This means that security rules, compliance requirements, and organizational guardrails are not just documentation but are enforced programmatically by the platform itself. For instance, GitOps workflows can be configured to require specific approvals for code merges that impact production environments, ensuring that only authorized and reviewed changes are deployed.

1. Built-in Guardrails and Best Practices: The platform operationalizes security best practices and organizational guardrails through templates and configuration as code. Valentina Rodriguez explained that this approach ensures consistency and reduces human error. When developers use self-service mechanisms to provision resources or configure namespaces, these actions inherently adhere to pre-defined secure configurations, including settings for observability or service mesh that can enhance security monitoring and network segmentation. This prevents common misconfigurations that often lead to vulnerabilities.

1. Controlled Access and Least Privilege: By understanding different personas (developers, data scientists, security teams, business users), the platform can be designed to provide appropriate, context-aware access controls. Colin Griffin emphasized that the platform needs to facilitate secure interaction between these diverse teams. This implies implementing robust Identity and Access Management (IAM), role-based access control (RBAC), and ensuring least privilege principles are applied consistently across all platform components and user interactions. The platform acts as a secure gateway, managing how various users connect and access information.

1. Reduced Cognitive Load for Security: A well-designed platform can abstract away security complexities from developers. By providing secure defaults and automated security checks, developers can focus on building features without needing to become security experts. This reduces the likelihood of security oversights due to cognitive overload.

1. Enhanced Auditability and Compliance: The use of configuration as code and GitOps inherently provides an audit trail of all changes to the platform and its deployed applications. This transparency, combined with effective DORA metrics and custom reporting frameworks, allows organizations to track platform usage, release frequency, and policy adherence. This data is invaluable for compliance audits and demonstrating that security controls are in place and effective.

1. Data Protection for New Workloads (AI): With the rise of AI, platforms play a critical role in protecting data. Colin Griffin explicitly mentioned the need to "protect our data" when discussing AI. The platform provides the secure environment and tools necessary for managing sensitive training data, ensuring model integrity, and controlling access to AI models and their outputs. This includes secure data storage, transit encryption, and access policies tailored for AI/ML workflows.

1. Proactive Risk Reduction: Ultimately, one of the core goals of treating a platform as a product is to "reduce risk," as highlighted by Danielle Cook in her concluding remarks. By integrating security, governance, and compliance into the product lifecycle, organizations can proactively identify and mitigate risks, leading to a more resilient and secure software delivery pipeline.

Key Takeaways

• Treat Your Internal Platform as a Product: Embrace an iterative, user-centric approach with continuous funding and consistent teams responsible for both building and operating the platform, moving beyond the limitations of time-bound projects.
• Align with Business Goals: Ensure the platform's development directly supports explicit business objectives (e.g., increased ARR, market competitiveness), translating technical benefits into measurable business value to secure investment and drive adoption.
• Design for All Personas: Identify and actively engage with all internal users—developers, data scientists, security teams, business analysts—incorporating their diverse needs and feedback into the platform's design from the outset.
• Embrace Self-Service and Automation: Implement robust self-service capabilities, leveraging templates and configuration as code (e.g., GitOps) to reduce cognitive load, empower development teams, and scale platform capabilities efficiently.
• Integrate Security and Governance Proactively: Embed security policies, organizational guardrails, and compliance mechanisms directly into the platform's technical implementation and workflows, rather than treating them as afterthoughts.
• Measure What Matters to Users: Define platform success metrics based on the success of its consuming teams (e.g., improved ROI, faster delivery), rather than just technical uptime, to demonstrate value and encourage adoption.
• Foster Agility for Future Technologies: A product mindset cultivates agility and continuous iteration, making the platform adaptable and ready to support emerging technologies like AI/ML by abstracting complexity and facilitating rapid experimentation.

About the Speaker(s)

The panel comprised experienced professionals deeply embedded in the cloud-native and platform engineering communities:

• Danielle Cook: A CNCF ambassador who has been instrumental in helping organizations adopt cloud-native technologies since approximately 2016. She served as the moderator for this insightful panel discussion, guiding the conversation and synthesizing key points.

• Colin Griffin: The Founder and CEO of Crumbware, a company focused on platform-centric software development. He is also a co-chair of the CNCF Platforms Working Group. Colin's background is rooted in application development, where he transitioned into platform engineering after frequently finding himself debugging infrastructure issues for application teams.

• Simon Fer: An architect and engineer working in financial services in London. With a background as an infrastructure engineer, Simon has witnessed and contributed to the evolution of the platform space with the adoption of cloud-native technologies.

• Valentina Rodriguez: A Principal Architect at Red Hat, based in New York. Valentina brings over 20 years of experience, initially as a developer, before transitioning to working on platforms at Red Hat. She is a recognized contributor to the KubeFlow project and an organizer for KCD (Kubernetes Community Days) events. Her passion lies in helping customers and organizations overcome blockers and challenges in platform adoption, focusing on the intersection of business and technology.