A photograph of Piotr Szwed surround by a circular blue and purple frame.

Inside Platform Engineering with Piotr Szwed

Matthew Allford
Matthew Allford

Platform Engineering means different things to different people, but after 25 years in infrastructure automation, Piotr Szwed has a clear view of where it’s heading. In this episode of Inside Platform Engineering, Piotr makes the case that the tools and patterns most teams rely on today are already becoming a liability, and that the shift to API-first, AI-native infrastructure isn’t a distant future. It’s happening now.

Watch the episode

You can watch the episode with Piotr below.

Inside Platform Engineering with Piotr Szwed

The shift from automation to autonomy

For most of its history, infrastructure automation has been about reducing human toil. Scripting repetitive tasks, templating deployments, and codifying what engineers do by hand. Piotr argues that this framing is now outdated and suggests the goal shouldn’t be to automate your platform team’s work; it should be to build systems that manage themselves. Self-healing, autoscaling, and continuously reconciling their own state without human intervention. This is the core idea behind the Kubernetes operator pattern, and it represents a significant mindset shift for teams that have always reached for automation scripts and manual processes when something needs to change. The difference may seem subtle, but it has profound implications for how you design, build, and staff a platform.

Is Terraform keeping up with Platform Teams’ needs?

Piotr was one of Terraform’s earliest power users, with his teams building over 20 custom providers in its early days. That history gives weight to his argument that Terraform is struggling to keep pace with the modern infrastructure landscape. The number of cloud services and APIs is growing faster than providers can track, and the reconciliation loop that teams bolt on through Jenkins jobs or cron-triggered pipelines is, in his view, one of the biggest anti-patterns in the industry. Teams doing this are essentially rebuilding the Kubernetes controller pattern in a much more fragile way, simulating something that Kubernetes provides for free, while adding the complexity of maintaining yet another layer of tooling around it.

His recommendation isn’t to throw everything out overnight, but to understand that operators support import and read-only modes, making a gradual, non-destructive migration far more achievable than most teams assume.

Reference architectures are making the path clearer

One of the practical barriers to adopting API-first, Kubernetes-centric platforms has been the lack of a clear blueprint. That’s changing. Piotr points to a growing set of well-resourced reference architectures, CNOE from Amazon and Cisco, ApeiroRA from SAP, and Google’s KCC with Kro, as evidence that the industry has reached a turning point. Importantly, these aren’t monolithic frameworks that need to be adopted wholesale. They’re designed more like Lego blocks, where teams can cherry-pick the components that fit their organization and swap out the pieces that don’t.

What they all share is more important than their differences: each is API-first and built on the Kubernetes operator pattern. That consistency across hyperscalers and vendors is itself a strong signal that the industry is converging around a direction. With major players now publishing and backing these blueprints, the “we don’t know where to start” barrier is lower than ever.

Where does this leave platform teams?

The conversation with Piotr covers a lot of ground, but the underlying message is consistent throughout. The move to API-first, autonomous systems isn’t just something Piotr is chasing as the newest, shiniest solution in our field, but he is instead focusing on building platforms that can keep pace with the speed at which cloud services, AI capabilities, and business requirements are evolving.

The good news, depending on how you look at it, is that the ecosystem is maturing quickly. Reference architectures are documented, communities are active, and migration paths exist that don’t require starting from scratch. For teams that see the value in what Piotr is putting forward, starting incrementally now is a much more comfortable place to be than waiting until the shift feels unavoidable and finding yourself staring down another major platform migration.

Happy Deployments!

Inside Platform Engineering is a series of conversations with Matt Allford and a guest, bringing their own experience and perspective from the world of Platform Engineering.

You can find more episodes on YouTube.

Matthew Allford

A technologist and content creator who combines 15+ years of deep technical experience with a passion for community education.

Related posts