How platform engineering is dying and what that means for platform engineers [Q&A]

As enterprises race to boost developer productivity, the era of building internal platforms entirely in-house is fading. Instead organizations are turning to purpose-built platform solutions that provide scalability, governance, and developer experience out of the box.

We talked to Lakmal Warusawithana, VP and distinguished engineer at WSO2, to find out why this change is taking place and how the role of platform engineers is evolving to suit.

BN: What are the top two or three hidden costs or downsides that typically push an enterprise away from their custom internal platform?

LW: The biggest hidden cost is time. Most organizations underestimate how long it takes to stitch together Kubernetes, CI/CD, security, observability, and governance into something that’s reliable and developer-friendly. By the time the first version of a home-grown platform is usable, business priorities or technology standards may already have shifted.

The second cost is money and it’s substantial. True platform-engineering talent is rare and expensive. To build a secure, scalable, and fully integrated internal developer platform, you need highly qualified platform engineers with deep expertise across cloud infrastructure, networking, security, and developer experience. Retaining such talent can easily turn a DIY platform into a multi-million-dollar effort long before it delivers meaningful business value.

The third is maintenance debt. A DIY platform isn’t a single product, it's a collection of many independent tools and frameworks, each with its own release cadence, bug fixes, and security updates. Keeping that ecosystem healthy means constantly upgrading every component while ensuring the integrations between them don’t break. Even a minor version change in one tool can ripple through the entire stack. Over time, this becomes one of the hardest and most expensive engineering challenges to sustain.

BN: What is the single most critical factor an enterprise should evaluate when deciding whether to buy a purpose-built platform or continue to build a custom one?

LW: The key question is: Is the platform building your business, or does it only support your business?

If your core mission is something other than developing platform technology, e.g. financial services, healthcare, or retail, you should not be investing years of R&D into plumbing. Instead, leverage a purpose-built or open-source internal developer platform that already provides scalability, governance, and security out of the box.

Only organizations whose product is the platform itself can justify a full DIY. Everyone else gains more by customizing and integrating proven foundations rather than rebuilding them.

BN: As the platform engineer's role shifts, which skills do engineers need to prioritize to ensure they remain relevant?

LW: The platform engineer’s role is evolving from builders of infrastructure to curators of platforms. Instead of assembling every piece of a platform from scratch, their focus is now on configuring, extending, and governing purpose-built or open-source internal developer platforms to fit the organization’s needs.

This requires a different kind of technical depth. Platform engineers must understand how to shape and operate platforms as products, defining the right developer workflows, abstractions, and policies that balance speed with control. Their expertise moves higher up the stack, focusing on how the platform enables development rather than how each tool underneath is wired.

They also need to adopt a product mindset, treating the platform as a continuously evolving product that serves internal developers. That means learning to manage roadmaps, measure adoption, collect feedback, and continuously refine the developer experience.

Key technical priorities now include:

• Automation and governance, ensuring compliance, security, and consistency at scale.
• Observability and cost optimization, giving visibility into platform performance and efficiency.
• Developer experience design, simplifying onboarding, deployment, and day-to-day workflows.

Equally important are collaboration and communication. Future platform engineers must partner not only with developers, security, and operations teams, but also with architects, product leaders, and CXOs, aligning platform strategy with business objectives. They are becoming the connective tissue between technology and leadership, acting as internal advocates for productivity, governance, and continuous improvement.

BN: Which feedback mechanisms can platform engineers use to gauge whether the platform is genuinely improving the day-to-day experience of their internal developers?

LW: The most successful platform teams measure impact from data, dialogue, and business outcomes.

On the data side, they rely on developer-experience metrics that quantify velocity and reliability, things like lead time for changes, deployment frequency, mean time to recovery (MTTR), and change-failure rate. These metrics, popularized through DORA research, reveal whether the platform is truly helping teams deliver faster, safer, and more often.

But metrics alone aren’t enough. Modern platforms now use AI-driven analytics to automatically detect friction points, correlate performance across teams, and even suggest optimizations. For example, AI can surface patterns such as recurring pipeline delays, inefficient environment usage, or failing deployments, helping engineers target improvements before developers even raise them.

At the same time, self-service capabilities have become an essential feedback source. When developers can autonomously provision environments, deploy applications, and access observability data, their interaction with the platform becomes measurable. Platform engineers can track self-service usage, bottlenecks, and error trends to understand how effectively developers are moving without operational blockers.

A mature platform also delivers business insights alongside technical ones. By connecting engineering activity with product or revenue outcomes, for example, how faster deployments translate to quicker feature launches or reduced customer churn, CXOs and business stakeholders gain a direct view of how engineering investments drive business performance. This feedback helps the entire organization make better, faster decisions.

Finally, continuous human feedback still matters. Regular developer surveys, internal community forums, and ‘platform retrospectives’ allow teams to share qualitative insights that metrics may miss. Combining those insights with executive-level reporting ensures platform evolution remains tightly aligned with both developer satisfaction and business goals.

BN: Looking ahead, which technology trends do you believe will have the most disruptive impact on how internal developer platforms are built, curated, and utilized?

LW: We’re entering an era where platforms are becoming intelligent, composable, and business-aware. Several major trends are driving that shift.

First is the rise of AI-native automation. AI is moving beyond chatbots and code completion into the heart of platform operations. We’ll see intelligent agents automatically diagnose failed builds, perform AI-driven root cause analysis (RCA) during incidents, tune scaling policies, detect anomalies, and even propose architectural improvements. Instead of waiting for engineers to piece together clues across logs and traces, AI systems will correlate telemetry, surface the likely root cause, and even suggest automated remediation steps. AI will help platform engineers make proactive, data-driven decisions, effectively turning today’s reactive platforms into self-optimizing, self-healing systems that continuously learn and improve over time.

Second is the growth of open-source internal developer platforms. Projects like OpenChoreo are giving organizations a flexible, community-driven foundation that can be adapted to their own governance, compliance, and developer-experience needs. These open frameworks will accelerate innovation, reduce vendor lock-in, and encourage collaboration across the ecosystem, much like Kubernetes did for container orchestration.

Third, self-service and composability are redefining how developers interact with platforms. The future platform won’t be a single monolithic portal; it’ll be a collection of composable services and APIs that developers can assemble as needed. Self-service provisioning, policy-driven automation, and context-aware templates will allow teams to move faster without waiting on central operations.

Finally, platforms are evolving into sources of business intelligence, not just engineering automation. The next generation of IDPs will provide real-time insights that connect engineering performance to business outcomes, showing how developer velocity, release quality, or infrastructure cost directly influence customer experience and revenue. These insights will make the platform a strategic asset for both engineering and the executive teams.

Image credit: Syda Productions/Dreamstime.com