Lakmal Warusawithana

Building a Vendor-Neutral Developer Platform​

For years, the cloud native community has debated which technologies win.

• Which ingress controller?
• Which service mesh?
• Which observability stack?
• Which CI/CD engine?
• Which AI framework?

History has shown that these debates rarely have permanent answers.

A decade ago, Mesos looked unstoppable. Service meshes exploded with innovation. New observability platforms emerge every year. Today, AI infrastructure is evolving even faster than Kubernetes itself.

Yet many Internal Developer Platforms (IDPs) are still designed around a single assumption:

The platform team knows the right technology choices, and everyone else should use them.

That assumption creates one of the biggest long-term risks in platform engineering: vendor lock-in. The real job of a platform is not to force technology decisions. It is to provide a stable developer experience while allowing the underlying technology stack to evolve.

Developers should depend on platform capabilities, not platform implementations.

And that's why platforms alone don't win.

Ecosystems do.

Kubernetes Didn't Win Because It Included Everything​

Kubernetes itself succeeded because it became an ecosystem, not because it solved every problem. Kubernetes does not include a built-in CNI, ingress controller, storage engine, observability stack, or CI/CD system. Instead, it defines stable abstractions:

• Pods
• Services
• Deployments
• Ingress
• Custom Resource Definitions (CRDs)

Innovation happens behind those abstractions.

Organizations can replace Flannel with Cilium, NGINX with Envoy, Prometheus with another metrics backend, or ArgoCD with Flux without fundamentally changing how developers interact with Kubernetes.

The ecosystem evolves while the user experience remains stable. This separation between interface and implementation is perhaps Kubernetes' greatest architectural achievement. Developer platforms should learn from that model.

The Hidden Problem with Many Internal Developer Platforms​

Many IDPs simplify Kubernetes by hiding its complexity. That's valuable. But often they replace one form of complexity with another. Instead of exposing Kubernetes primitives, they tightly couple the platform to a specific collection of technologies:

• One ingress solution
• One workflow engine
• One observability vendor
• One security model
• One AI framework

Initially, this feels simpler. But over time, platform teams discover that changing one of these technologies requires changing the platform itself. The platform becomes the bottleneck. Ironically, the platform designed to accelerate innovation starts slowing it down.

Platform Teams Need Freedom Too​

We often talk about improving the developer experience. But platform engineers are users too. Their requirements evolve constantly:

• Replace one networking stack with another.
• Introduce a new observability backend.
• Add cost management capabilities.
• Integrate new security scanners.
• Adopt emerging AI tooling.
• Support organization-specific workflows.

A platform that cannot evolve forces teams to choose between stability and innovation. A platform built around an ecosystem allows both.

Designing for an Ecosystem​

At OpenChoreo, we started with a simple architectural principle:

Kubernetes remains the system of record.

Instead of building a monolithic platform, OpenChoreo provides higher-level abstractions for developers while allowing platform capabilities to be composed from interchangeable modules.

This led to several key design decisions.

Multi-Plane Architecture​

Rather than placing everything into a single control plane, OpenChoreo separates responsibilities across multiple planes:

• Control Plane
• Data Plane
• Workflow Plane
• Observability Plane

Each plane can evolve independently while presenting a unified experience to developers.

High-Level Platform Abstractions​

Developers should think about applications, APIs, components, environments, and resources—not networking plugins or ingress controllers. The platform translates those higher-level concepts into Kubernetes-native implementations. As underlying technologies change, developer workflows remain unchanged.

Extensible APIs​

Every platform capability should be accessible through stable APIs. Whether consumed by portals, CLIs, GitOps pipelines, automation systems, or AI agents, the same abstractions apply. This avoids creating separate operational models for humans and machines.

Ecosystem Modules​

Modern platforms cannot anticipate every future requirement. Instead of embedding every capability into the core platform, OpenChoreo allows functionality to be delivered through ecosystem modules.

Examples include:

• Networking modules
• Observability modules
• Security modules
• FinOps integrations
• Workflow extensions
• Infrastructure providers
• Built-in agents
• Reusable skills

This allows organizations to adopt new technologies without redesigning the platform itself.

AI Makes Ecosystems Even More Important​

The rise of AI agents introduces a new challenge. Agents need access to platform capabilities just as human developers do. They need to deploy applications. They need to inspect observability data. They need to trigger workflows. They need to understand policies and guardrails. If these capabilities are tightly coupled to vendor-specific implementations, every AI integration becomes custom work. Instead, OpenChoreo treats AI as another ecosystem participant. The same platform abstractions exposed to humans are also exposed to agents through MCP servers, reusable skills, APIs, and workflows. The goal is not to build a separate AI platform. The goal is to make AI a first-class consumer of the same ecosystem.

The Future of Platform Engineering​

Platform engineering is often described as building products for developers. That's true. But products eventually become ecosystems.

The most successful cloud native projects didn't win because they had the best individual features.

• Linux
• Kubernetes
• Prometheus
• Backstage

They won because they created environments where innovation could happen without replacing the foundation. Internal Developer Platforms should aim for the same outcome. The platform should provide consistency. The ecosystem should provide innovation. Developers should experience stability. Platform teams should retain freedom. Organizations should never have to choose between adopting new technology and preserving their developer experience.

Because in the long run, platforms don't win.

Ecosystems do.​