Beyond the Booth at KubeCon: What We Learned About Platform Engineering, AI, and Scale
- Daniel Bryant
- Dec 16, 2025
- 6 min read
KubeCon + CloudNativeCon North America in Atlanta made one thing clear: platform engineering is entering a new phase.
At Syntasso, we left the event with a strong sense that the conversation had shifted. Teams are no longer asking whether they need an internal platform. They are asking what happens next: how to scale it, operate it, evolve it, and keep it valuable over time.
In our recent webinar, Beyond the Booth at KubeCon, Abby Bangser, Cat Morris, and Daniel Bryant reflected on what we saw in Atlanta, from the rise of real AI workloads on Kubernetes to growing interest in platform product management and day-two operations. Here are the biggest takeaways.
1. AI is accelerating platform engineering maturity
For a while, AI in the cloud native world often felt more like a promise than a practice. At this year’s KubeCon, that changed.
What stood out was the number of real-world production stories showing how organisations are running AI workloads on modern platforms. Rather than replacing platform engineering, AI is increasing the need for it. Teams need reliable infrastructure, stronger governance, better observability, and more scalable operating models to safely and efficiently support AI.
This was a recurring theme across analyst conversations and conference talks alike: AI may be capturing budgets and mindshare, but it is also forcing organisations to invest more deeply in platform engineering capabilities.
In other words, AI is not separate from platform engineering. It is becoming another critical platform capability, alongside databases, CI/CD, queues, and other shared services.
2. Platform engineering has moved from “why” to “how”
One of the clearest shifts from previous events was the maturity of the conversations.
At earlier KubeCons, many attendees were still asking foundational questions like:
What is an internal platform?
Why do we need one?
How is platform engineering different from DevOps?
In Atlanta, the questions were far more advanced:
How do we handle day-two operations?
How do we upgrade services at scale?
How do we manage drift?
How do we let more teams contribute safely?
How do we keep the platform from becoming a bottleneck?
That shift matters. It signals that platform engineering is no longer emerging for many organisations. It is real, deployed, and now facing the challenges that come with adoption and success.
3. Platform as a product is becoming mainstream
At Syntasso, we have been advocating for a platform as a product for years. At KubeCon, it was encouraging to see that message resonate more strongly than ever.
The core idea is simple: an internal platform should not be treated as just a pile of tools. It should be managed as a product designed to serve its users.
That means understanding who your customers are, what problems they actually face, and what value the platform is meant to deliver. For most organisations, those users include developers, QA teams, architects, and SREs. A successful platform helps users move faster while staying safe, efficient, and scalable.
In our O’Reilly report, we describe four pillars of platform value:
Speed: How quickly can teams move from idea to running software?
Safety: How does the platform support governance, compliance, and operational confidence?
Efficiency: How do you deliver value without creating unsustainable cost or operational overhead?
Scalability: How does the platform grow across teams and use cases without requiring linear growth in platform engineering headcount?
One of the strongest signals at the booth was that more platform teams are actively looking for product management techniques to help answer these questions. That is a positive sign. It means teams are recognising that technical excellence alone is not enough. Adoption, usability, and measurable value matter too.
4. The next challenge is scale and “multiplayer mode”
A recurring theme in Atlanta was that many platform teams are now overwhelmed by their own momentum. Their platforms are being used. More teams want capabilities. More stakeholders have requests. More contributors want to get involved. And the platform team cannot do it all alone.
This is where we think “multiplayer mode” becomes essential.
Rather than scaling the platform by endlessly adding more central platform engineers, organisations need ways to scale contributions. That means creating a model where different internal teams can produce capabilities for the platform, and others can consume them safely and consistently.
A useful analogy is a marketplace. The platform team is not handcrafting every single capability forever. Instead, it enables a broader ecosystem of producers and consumers inside the organisation.
This shift becomes especially important in large organisations, where teams may be offering database services, AI services, infrastructure components, or application building blocks to other teams. Without a contribution model, the central platform team becomes a bottleneck. With one, the platform becomes an engine for collaboration and scale.
5. Platform engineering is a sociotechnical discipline
Another major theme from the event was that platform work increasingly sits at the intersection of technology, operations, and organisational design.
Platform engineers often serve as bridges between technical and non-technical groups. They need to understand not only Kubernetes, GitOps, policy, observability, and delivery pipelines, but also the needs of finance, compliance, governance, and business teams.
This is one reason platform teams are feeling the strain. The problem is no longer just building automation. It translates among many different stakeholders and turns that complexity into coherent, usable services.
That is also why a product mindset matters so much. It gives teams a framework for deciding what to prioritise, how to measure success, and how to align technical choices with business value.
6. Observability is no longer optional
If there was one technical topic that consistently came up in conversations, it was observability.
As platforms grow more complex and as AI introduces new operational demands, teams need better visibility across the stack. That includes applications, controllers, infrastructure, and shared services.
People are increasingly unwilling to accept dependencies they cannot understand. If a team is paged in the middle of the night, “we’re not sure why” is no longer an acceptable answer.
OpenTelemetry in particular stood out as a key part of the direction of travel. Teams are looking not only at how to collect telemetry, but how to do it cost-effectively and meaningfully. The challenge is not just gathering more data. It is collecting the right data, organising it well, and making it actionable.
Observability is no longer just an operational concern. It is foundational to trust, adoption, and the long-term success of internal platforms.
7. Day-two operations are the new frontier
One of the biggest engineering challenges we heard repeatedly was what happens after a platform has been adopted.
Templates and self-service creation flows are useful, but they are not enough. Many teams now find themselves with large numbers of deployed resources, services, and platform components that need to be updated, governed, and brought back under management.
That raises difficult questions:
How do we handle drift?
How do we upgrade shared capabilities without disruption?
How do we move from one-time templating to ongoing lifecycle management?
How do we make sure platform consumers continue to benefit from improvements over time?
This is where ideas like declare-and-converge, GitOps, drift detection, automated remediation, and updatable service “chassis” start to matter more. The industry is moving from vending-machine thinking toward lifecycle thinking.
And that is a healthy sign. It means the discipline is maturing.
8. Community still matters, perhaps more than ever
For all the technical depth at KubeCon, one of the most important reminders was that the platform engineering journey is still just beginning for many teams.
During Abby’s keynote, a large portion of the audience identified themselves as first-time KubeCon attendees. That is a powerful signal that new people, new roles, and new perspectives are entering the space.
We also noticed a broader mix of attendees than in previous years. Product managers, for example, felt more at home at the event. That reflects the reality that platform engineering is not only for deeply specialised Kubernetes experts. It is becoming relevant across disciplines.
The good news is that there is already a huge amount of knowledge in the community: success stories, failure stories, hard-won lessons, and practical patterns. The challenge is helping people find and apply them.
That is why community participation matters. Sharing case studies, speaking at events, writing openly about what worked and what did not, and learning from others will continue to shape the next phase of platform engineering.
Final thoughts
KubeCon Atlanta reinforced something we at Syntasso care deeply about: platform engineering works best when it is treated as both a technical and a product discipline.
AI is raising the stakes. Scale is exposing bottlenecks. Observability is becoming essential. Day-two operations are moving to the centre of the conversation. And organisations are increasingly realising that internal platforms need more than tools. They need product thinking, contribution models, and strong fundamentals.
The journey is far from over. But the conversation is getting better. Teams are asking tougher questions now, and that is a good thing.
Comments