Internal Developer Platform (IDP) Part 2 - The 5 Planes of the Reference Architecture
IDP Reference Architecture
Each component in the IDP walking skeleton belongs to one of five planes of the IDP reference architecture introduced at PlatformCon 2023 by Mike Gatto and Stephan Schneider from McKinsey (Platform as Code: Simplifying developer platform design with reference architectures and Platform as code: Reference architectures to simplify developer platforms by Stephan Schneider, Navin Agarwal, and Thomas Delaet - McKinsey Digital). We’re using the term "observability plane" instead of "monitoring and logging plane".
The PlatformCon talk and McKinsey post cover the architecture; this project focuses on component choices. The project documentation relates the components chosen to the respective plane. Some of the components appear in two places, e.g. the terminal based simple portal is part of both the developer plane and the observability plane.
The 5 Planes
An overview of the five planes follows. For details, see the project documentation.
The developer control plane is how both the platform and application developers interact with the IDP. It contains all the tooling necessary for a consistent and reproducible development environment, reducing onboarding time. This project uses a Nix development environment. Terminal based tools are preferred. Typical components are kubectl, k9s, yq at pinned version. The IDE is left out on purpose as developers often have strong individual preferences and configuration. AI agents assisting the developers are also part of this plane.
The integration and delivery plane handles developer requests to the IDP, such as building and deploying applications. This project runs entirely on Kubernetes with a small footprint. Flux CD was chosen for GitOps and Tekton for CI/CD among others.
The resource plane is based on Kubernetes and all workloads and their resources will run on it. In production, this might not be an appropriate solution, e.g. for databases, or other managed services. For this project k3s/k3d was chosen, addressing the small footprint requirement.
The observability plane ("monitoring and logging plane") gives the platform and application teams insight into the IDP right from the start. Tools chosen are Victoria Metrics and Grafana, and the simplest dashboards for ingress (Traefik) and CI/CD (Tekton). This project includes a simple terminal UI (TUI) portal built with AI assistance.
The security plane handles identity, access, and secrets. It ensures the integrity, confidentiality, and availability of the platform and data by enforcing access controls and integrating security both at runtime and within the CI/CD pipeline. As of the time of this writing, neither identity nor secret handling solutions have been implemented in this project. Keycloak, Zitadel, and Sealed Secrets are possible candidates. Access control and software supply chain security will also be addressed.
This post covers the IDP reference architecture and its five planes. The next post covers the principles and pillars of platform engineering.
This post and the underlying code was written and developed in collaboration with several AIs.