Building an Enterprise Grade Self-Serviceable Internal Developer Platform (IDP): Part 1
- Kanchana Wickremasinghe
- Vice President & General Manager Choreo BU, WSO2
The CNCF stack behind a modern IDP
For years, we’ve lamented how the DevOps movement has been defined by 'you build it, you run it'. In theory, this empowered developers with end-to-end ownership. However, practical implementations often resulted in a staggering increase in cognitive load. Today’s software engineers are often expected to act as part-time cloud architects, security experts, and Kubernetes wranglers just to ship a simple feature.
Enter platform engineering and the internal developer platform (IDP).
As highlighted by the community at platformengineering.com, an IDP is designed to abstract away infrastructure complexities, providing developers with self-service "golden paths." But what actually powers these platforms under the hood?
You don't build an IDP from scratch. You build it using the open source building blocks provided mostly by the Cloud Native Computing Foundation (CNCF). In part 1 of this series, we are going to decode the modern CNCF stack that powers today's most resilient IDPs, and explore how to integrate them into a platform that is easy to adopt, maintain, and evolve.
The CNCF: The Lego store of platform engineering
The CNCF Landscape is vast and can feel overwhelming; it presents hundreds of projects spanning databases, networking, security, and CI/CD. However, when architecting a modern IDP, the industry has largely standardized around a specific set of "superstar" CNCF projects.
What then does a blueprint of a modern cloud native IDP look like? While not a silver bullet, the following components help define a solid foundation:
1. The universal control plane: Kubernetes
Kubernetes is no longer just a container orchestrator; it has evolved into the universal control plane for the entire tech stack. In a modern IDP, Kubernetes is the engine that reconciles the desired state of your applications, infrastructure, and policies. It is the foundation upon which every other tool in your IDP is deployed.
Kelsey Hightower’s famous phrase, "Kubernetes is a platform for building platforms," defines it as a foundational, extensible framework for building custom infrastructure rather than a finished end-user product.
2. The developer interface: Backstage
Developers shouldn't have to interact with the raw Kubernetes CLI (kubectl). Backstage, an incubating CNCF project originally created by Spotify, has become the de facto standard for the developer interface. It acts as a centralized software catalog, documentation hub, and self-service portal, allowing developers to scaffold new microservices with the click of a button.
3. The delivery pipeline (GitOps): ArgoCD or Flux
GitOps is the heartbeat of a modern platform. Tools like ArgoCD and Flux ensure that the state of your infrastructure and applications is strictly defined in Git. When a developer merges code, these tools automatically detect the change and sync it to the Kubernetes cluster. No manual deployments, no configuration drift.
4. The infrastructure orchestrator: Crossplane
What if a developer needs a Postgres database or an S3 bucket alongside their application? Instead of opening an IT ticket or writing complex Terraform scripts, platforms use Crossplane. It extends the Kubernetes API, allowing developers to provision external cloud resources using the same YAML or platform abstractions they use for their applications.
5. The watchtowers: Prometheus, OpenTelemetry, and Envoy
An IDP must provide "observability by default."
- Prometheus handles metrics monitoring and alerting.
- OpenTelemetry provides a standardized framework for collecting distributed traces and logs.
- Envoy (often used via API gateways) manages ingress/egress traffic, enforcing networking policies and capturing telemetry right at the network edge.
The "3 a.m. IKEA" problem
Having all these incredible CNCF tools is great, but there is a catch. As platform advocates often joke, building your own IDP from raw CNCF components is a lot like assembling IKEA furniture at 3 a.m. Kavishka Fernando, Head of OpenChoreo DevRel at WSO2, explores this challenge in detail in his article on Medium.
You spend months wiring ArgoCD to Backstage, writing custom operators to integrate Crossplane, and debugging Helm charts instead of delivering business value. The platform team becomes a bottleneck for the very platform meant to eliminate bottlenecks.
To succeed, you need a unifying framework, a layer that connects these disparate tools into a cohesive, secure, and developer-friendly experience.
Bringing it together: The OpenChoreo approach
This is where next-generation, open-source IDP frameworks like OpenChoreo come into play.
Instead of forcing your platform team to manually stitch together Backstage, GitOps, and API gateways, OpenChoreo provides a fully functional, Kubernetes-native IDP out of the box. It takes the power of the CNCF stack and wraps it in what is known as Cell-Based Architecture (CBA) , a specification authored by Paul Fremantle (Co-Founder and Founding CTO, WSO2) and Asanka Abeysinghe (CTO, WSO2).

Figure 1: High-level architecture for OpenChoreo (Image: Credits OpenChoreo.dev website)
Here’s how OpenChoreo decodes the platform engineering challenge.
- Developer-Friendly Abstractions: Instead of making developers write complex Kubernetes manifests or Crossplane configurations, OpenChoreo introduces higher-level abstractions like Projects, Components, and Endpoints. A developer simply says, "Deploy this component and expose this endpoint," and the platform handles the underlying K8s plumbing.
- Built-in Developer Portal: It comes pre-integrated with a Backstage-powered portal and software catalog, making API discovery and service scaffolding instant.
- Zero-Trust and Observability by Default: Under the hood, OpenChoreo configures gateways and network policies so that every "Cell" (boundary) is secured via mTLS. Furthermore, logging, metrics, and distributed tracing are automatically wired up for every deployed component without the developer adding a single line of instrumentation code.
By leveraging an implementation like OpenChoreo, organizations can adopt the absolute best of the CNCF landscape (GitOps, K8s, dynamic infrastructure, and advanced networking) without drowning in integration debt. It separates the concerns perfectly: platform engineers define the standards and guardrails and developers stay focused on writing code.
Up next in Part 2: Networking, security, and API management
Understanding the CNCF foundation is only the first step. In part 2 of Platform Engineering Decoded, we will dive deeper into zero trust in your IDP, focusing on networking and security with OpenChoreo and Cilium.
Stay tuned!
References:
1. platformengineering.com * Cloud Native Computing Foundation (CNCF)
2. OpenChoreo - The Open-Source IDP