top of page

From the Floor: Platform Engineering Insights from QCon & KubeCon

What’s actually happening on the ground in platform engineering right now? At Syntasso, we spend a lot of time talking to teams, but there’s something uniquely valuable about stepping into the hallway track at events like QCon London and KubeCon EU. These conferences bring together practitioners, architects, and platform leaders from across industries, offering a real-time snapshot of where the ecosystem is heading.


After attending both events, we noticed a clear pattern. The same themes, challenges, and opportunities are emerging, but they are viewed through slightly different lenses.


Watch the entire webinar on YouTube!

AI Is No Longer Hype: It’s Reshaping the SDLC

AI dominated both QCon and KubeCon, but this time it felt materially different. This wasn’t experimentation or early curiosity. It was real adoption.


Organisations are now embedding AI across the software delivery lifecycle, using it not just to generate code but to operate platforms and reshape how teams work. There were concrete case studies from highly regulated enterprises showing measurable impact, not just prototypes or proofs of concept.


One of the most striking shifts is that coding itself is no longer the primary bottleneck. Instead, the constraints are moving up the stack. Architecture, platform capabilities, and product decision-making are becoming the limiting factors.


This raises an important question for our industry. If AI can generate code on demand, what role do architects and platform product managers play? We’re already seeing early answers emerge, with architects increasingly acting as orchestrators: designing systems of systems, coordinating workflows across platforms, and even managing fleets of AI agents.


Platforms Are Now the Bottleneck

As AI accelerates development, a new tension is emerging. Teams can now generate applications faster than ever before, but they are running into friction when those applications meet the realities of infrastructure, pipelines, and governance.


Several real-world examples reinforced this. At Spotify, for instance, engineers found that while AI made it easier to update and evolve application code, the real constraint became the platform itself—particularly when changes required updates to infrastructure or delivery pipelines.


This is a pattern we’re seeing repeatedly. Application changes are becoming cheap and fast, but platform changes remain complex. That imbalance is now one of the biggest challenges in modern software delivery.


It also reinforces a simple but critical idea: if your platform is already a bottleneck, AI will amplify that problem. Faster development doesn’t remove constraints. It exposes them.


Platforms must support the provisioning of AI capabilities, and also consumption by AI capabilities
Platforms must support the provisioning of AI capabilities, and also consumption by AI capabilities

AI Strategy Is Platform Strategy

Another consistent theme across both conferences was that AI adoption cannot be treated as a standalone initiative. It is fundamentally a platform concern.


Organisations are grappling with questions around control, governance, and consistency. Many teams are enthusiastic about AI, but they want it delivered on their terms. That means visibility, security, and compliance are non-negotiable.


There is also a growing concern about “shadow AI”, where teams independently adopt tools and models without central oversight. This mirrors the earlier rise of shadow IT, but with potentially greater risks.


Leading organisations are responding by treating AI capabilities as part of the platform itself. That includes providing access to models, enforcing guardrails, and ensuring that everything is auditable and aligned with business requirements. In many cases, this is being approached as an API-first problem, where AI systems interact with platforms through well-defined, governed interfaces.


The key shift here is conceptual. AI is not something separate from the platform. It is just another capability that the platform must provide—and govern—effectively.


From Tools to Platform Capabilities

At KubeCon in particular, the conversation has evolved beyond tooling. While tools like Terraform, Backstage, and Crossplane remain important, the focus is no longer on selecting the right individual components.


Instead, teams are asking how to combine these tools into meaningful capabilities that developers can actually use. The discussion is moving from assembling technology to delivering outcomes.


This is where many organisations encounter difficulty. It’s relatively straightforward to assemble a collection of tools, but much harder to create a cohesive platform experience. The missing piece is often the orchestration layer or the “glue” that connects tools together and turns them into a usable product.


That orchestration layer is rarely visible, but it is essential. Without it, platforms become fragmented, inconsistent, and difficult to evolve.


The Rise of Day 2 Thinking

Another strong signal from both events was the growing awareness of Day 2 challenges. Many teams have successfully built platforms, but far fewer have figured out how to operate them effectively over time.


The real work begins after the initial launch. Teams need to manage upgrades, roll out changes across environments, and enable contributions from across the organisation. They also need to maintain consistency without introducing central bottlenecks.


As was discussed repeatedly, Day 2 isn’t just a phase; it’s the majority of the lifecycle.


This is where the trade-offs between building and buying become more apparent, and where platform engineering maturity is truly tested.


Platform as a Product Is Finally Landing

One of the most encouraging developments is that platform as a product is no longer an abstract concept. It is becoming a practical reality for many teams.


There is a growing recognition that platforms have customers, and those customers are developers, testers, and architects within the organisation. If the platform does not solve real problems for those users, it will not be adopted.


We heard multiple examples of teams struggling with adoption, only to realise that the issue was not technical. It was a mismatch between what the platform offered and what users actually needed.


The teams that are succeeding are those that focus on delivering value early and often. They invest in understanding user needs, improving discoverability, and creating feedback loops that reinforce adoption. Over time, this creates a virtuous cycle in which developers actively seek out the platform rather than avoid it.


Composability and APIs Are Becoming Foundational

Across both conferences, certain architectural patterns are becoming more prominent. API-first design is now widely accepted as a foundation for platform engineering. By abstracting away implementation details, APIs make it easier to evolve systems over time while maintaining consistency.


Closely related to this is the idea of composability. Rather than defining rigid “golden paths,” teams are increasingly building smaller, reusable components, sometimes described as “golden building blocks”. that can be combined in different ways to meet different needs.


This approach aligns naturally with platform capabilities. It enables flexibility without sacrificing standardisation, and it provides a strong foundation for both human and AI-driven interactions with the platform.


A New Direction: Platform Capabilities as a Marketplace

Looking ahead, one of the most interesting ideas emerging from the community is the concept of treating platform capabilities as a marketplace.


This approach encourages internal contribution, allowing teams across the organisation to build and share capabilities. It also creates a more scalable model for platform development, where responsibility is distributed rather than centralised.


At Syntasso, we’ve been exploring this idea through a set of design principles for platform capabilities, inspired by the Twelve-Factor App. The goal is to define a clear interface between how capabilities are built and how they are consumed within a platform.


Abby presents the 8 Factors of Platform Capabilities
Abby presents the 8 Factors of Platform Capabilities

This work on platform producer factors is now being taken forward within the CNCF community, which highlights just how relevant these challenges have become across the industry.


Final Thoughts

Across both QCon and KubeCon, the direction of travel is clear. AI is accelerating software development at an unprecedented pace, but platforms must evolve to keep up. The focus is shifting from tools to capabilities, from Day 1 to Day 2, and from building platforms to operating them as products.


If there is one takeaway, it is this: The faster AI moves, the more important platform engineering becomes.


For organisations that get this right, the opportunity is enormous. For those who don’t, the constraints will only become more visible over time.


If you’re exploring how to build scalable platform capabilities, orchestrate complex environments, or prepare your platform for AI-driven development, we’d love to talk.

Comments


bottom of page