Platform engineering has evolved from a buzzword into a critical discipline for organizations running modern infrastructure. Industry experts cut through the hype to address the real challenges platform teams face today - from managing the build-versus-buy tradeoff to supporting AI workloads alongside traditional applications.

Main insights

• Platform engineering is about taking a product kind of lens to system administration - intentionally designing for internal users rather than just operating tools
• Successful platforms build incrementally on existing infrastructure rather than attempting risky rip-and-replace migrations
• Golden paths balance developer autonomy with enterprise governance by providing standardized, opinionated workflows
• Kubernetes remains relevant for AI workloads because the ecosystem built on it rather than replacing it - but success requires deep infrastructure integration

The discussion featured Kelsey Hightower, renowned Kubernetes expert and former Google Cloud developer advocate, alongside Jad El-Zein, a principal technologist at Broadcom's VCF division with 16 years of VMware experience helping customers architect production platforms, and Taka Uenishi, Product Marketing Engineer in the VCF Division of Broadcom.

You can watch the full discussion here if you missed it: Beyond Kubernetes: Pragmatic Platform Engineering for 2026

What platform engineering actually means in practice

Platform engineering represents a fundamental shift in how organizations think about infrastructure. As Kelsey explained, "If you've ever written a bash script that just tried to make something a little easier to use, in my book that's a bit of platform engineering. But I think when you zoom out, it's about taking a product kind of lens to system administration."

This product mindset changes everything. Instead of simply operating tools and giving them to people to use, platform engineers create an intentional layer between vendor-provided capabilities and what their organization needs. The key difference lies in bringing domain expertise and organizational context that vendors cannot provide.

The challenge stems from a fundamental limitation: vendors can only produce 80% solutions. They build for thousands or millions of customers, which means they cannot be too opinionated about specific use cases. Platform engineers fill that critical 20% gap with defaults that meet security requirements, workflows that match organizational processes, and automation that eliminates toil.

The incremental approach to platform evolution

One of the most dangerous misconceptions in platform engineering is the idea that modernization requires ripping out existing infrastructure and starting fresh. Kelsey addressed this directly: "You're not going to rip and replace and build the replacement. You don't have enough time for that."

The better approach treats platform evolution like building a bridge. You cannot knock down the existing bridge while people still need to cross. Instead, you build the new one alongside it, create new exit ramps, communicate changes, and manage deprecation thoughtfully.

Kelsey recommended a practical exercise: "I want you just to write 1.0 on it. That way you can checkpoint all of your success, all the things you've done. And then if you were just to draw a timeline, what does 1.1 look like?" For some organizations, version 1.1 might mean finally getting SSL certificates everywhere. Version 1.2 could focus on centralized logging. Version 2.0 might introduce containers for new development while maintaining existing workloads.

This incremental roadmap approach acknowledges that buses, trains, and bikes can coexist in the same transportation system. Similarly, containers, virtual machines, and traditional infrastructure can run side by side when each serves its appropriate purpose.

Golden paths: Balancing freedom and governance

Platform teams constantly struggle with a fundamental tension: how do you give developers autonomy while maintaining enterprise governance? The answer lies in what the industry calls "golden paths" or "paved roads."

Jad explained the concept: "Rather than expecting your developers or consumers or practitioners to understand all the unique intricacies of a particular platform or set of tools or even the enterprise requirements and governance that are pushing some of these policies, the platform team instead builds these golden paths."

These standardized routes to production provide opinionated workflows that work for both the business and developers. The key is avoiding arbitrary restrictions. Golden paths must serve a purpose - abstracting complexity while providing developer autonomy where it matters, ultimately giving the business the capabilities and agility it needs.

The most effective golden paths leverage existing infrastructure abstractions. When you have world-class infrastructure that has been delivering critical workloads for decades, you build on that foundation rather than replacing it. This approach allows platform teams to take advantage of proven capabilities like resource scheduling, availability features, and security controls that already exist.

Why Kubernetes integration matters more than Kubernetes itself

A critical insight from the discussion challenges a common misconception: Kubernetes alone does not solve infrastructure problems. As Kelsey emphasized, "Kubernetes is only as good as the platform that it runs on top of."

When Kubernetes first emerged, getting it to run required significant integration work. You needed to connect DNS, networking, storage, and security - all of which Kubernetes treats as "fill in the blank" components. Most people have zero experience with raw Kubernetes off the shelf because it is extremely difficult to use without these integrations.

This is why deep platform integration matters. When you run Kubernetes on a mature infrastructure platform, you immediately benefit from existing capabilities:

• Resource scheduling and NUMA node optimization
• High availability and live migration
• Backup and disaster recovery
• Security controls and compliance features
• Networking and storage abstractions

Jad highlighted this advantage: "We're taking advantage of the availability, we're taking advantage of the resource scheduling, we're taking advantage of minute things like how a virtual CPU scheduled access to underlying NUMA nodes. All of that stuff still applies."

The control plane that exposes infrastructure through the Kubernetes API represents a game-changer. It allows you to declaratively describe what you want - whether that's a VM, a container, or a data service - and have the platform behave accordingly. You do not need to figure out configuration management tools or write extensive infrastructure-as-code. You describe the desired state, and the platform makes it happen.

AI workloads: Same principles, different scale

The emergence of AI and machine learning workloads has caused many organizations to question whether they need entirely new infrastructure approaches. The reality is more nuanced.

Kelsey cut through the hype: "Kubernetes didn't introduce any new concepts. Your IP addresses are the same. If you're using iSCSI, you will continue to use iSCSI. None of that changes. It's just how you use those things."

AI workloads do introduce new challenges - GPU scheduling, power consumption, expensive idle resources, and the need for stability during long-running training jobs. But these challenges do not require abandoning platform engineering fundamentals. They require applying those fundamentals to new workload characteristics.

The key is recognizing that AI workloads are just another type of workload. Models, pipelines, and inference services can all be managed declaratively, versioned in Git, monitored with observability tools, and automated through the same workflows you use for traditional applications.

Jad explained the approach: "Our role in all of this with a solution like Private AI Foundation which comes with VCF is to extend the same platform engineering and GitOps principles behind modern applications to AI workloads - make the AI workload a first class citizen of the IDP rather than a separate stack."

This means treating GPU-backed infrastructure, model runtimes, and AI services as curated, self-service capabilities delivered through Kubernetes, blueprints, and APIs. Instead of ad hoc environments managed through swivel-chair operations, you have unified services integrated into your existing platform.

The 20% that vendors cannot provide

Throughout the discussion, both speakers emphasized a fundamental truth: you are the critical 20% that makes platforms work for your organization. No vendor can deliver a 100% solution because they lack your domain expertise, organizational context, and specific requirements.

Kelsey made this point emphatically: "There is no thing you're going to ever buy that does everything you want it to do that also matches everything everybody else wants to do. It's just never going to happen. And so that's the value you bring."

This 20% includes:

• Defaults that meet your security requirements
• Workflows that match your organizational processes
• Integrations with your existing tools and systems
• Guardrails that balance governance with developer productivity
• Documentation and training tailored to your teams

The most successful platform engineers focus their energy on this 20% rather than trying to rebuild the 80% that vendors already provide. They leverage mature, stable infrastructure platforms and add the organizational-specific layer that makes those platforms truly valuable.

​

If you enjoyed this, find here more great insights and events from our Platform Engineering Community.

If you want to dive deeper, explore our instructor-led Platform Engineering Certified Professional course and connect with peers from large-scale enterprises who are driving platform engineering initiatives.

​

Key takeaways

• Start with incremental roadmaps, not rip-and-replace: Label your current state as version 1.0 and map small, progressive improvements like SSL everywhere or centralized logging before attempting major architectural changes. This approach maintains business continuity while steadily modernizing your platform.
• Build golden paths that serve a purpose: Create standardized workflows that abstract complexity and meet enterprise requirements while preserving developer autonomy where it matters. Avoid arbitrary restrictions - every guardrail must deliver clear value to both developers and the business.
• Leverage deep infrastructure integration: Kubernetes is only as valuable as the platform beneath it. Choose distributions that provide native integrations with networking, storage, security, and resource management rather than trying to build these integrations yourself.
• Apply platform engineering fundamentals to AI workloads: Treat AI models, pipelines, and inference services as first-class citizens of your internal developer platform using the same declarative management, GitOps workflows, and observability practices you use for traditional applications. AI does not require abandoning proven platform engineering principles - it requires applying them to new workload characteristics.