As your organization scales, so does the demand for faster feature delivery. But without proper support, engineering teams often end up bogged down by infrastructure work, slowing development and increasing cognitive load. That’s where Internal Developer Platforms (IDP) come in.
This article walks through how to structure an IDP, categorized by key components, with examples of tools you can use.
Let’s jump right into it!
What should a successful Internal Developer Platform deliver?
A well-designed IDP should accelerate software delivery by abstracting away repetitive, low-value infrastructure tasks, freeing developers to focus on what matters: writing code. In contrast to “just” CI/CD pipelines and other automation that runs in the background, IDPs aim to provide visibility and self-service to software engineers.
Through the IDP, software engineers should be able to discover which infrastructure, deployments, components, repositories and other assets relevant to their work exist – and be enabled to use them through self-service. The idea of visibility and self-service is central to internal developer platforms.
Platform engineering teams are responsible for building and maintaining the IDP. Tasks previously taken on by DevOps, operations and application teams are now partially moving to the platform engineering team: selecting tools, building pipelines, integrating services and infrastructure and providing the IDP as a layer of abstraction and visibility on top.
To enable this shift, you need the right platform engineering team, resources and tools for your IDP.
Screenshots form “How to Make the Business Case for an Internal Developer Platform“
Taken from the talk “How to Make the Business Case for an Internal Developer Platform”, the slides above illustrate which capabilities are moved from application teams to platform engineering teams.
The key point here is that the platform engineering team provides these capabilities as a service to all application teams. This removes the duplication of effort often present in engineering organisations where every application team takes care of their own local deployment tooling, developer tooling like code scanning tools or even testing frameworks and CI/CD pipelines.
Moving this to a dedicated platform engineering team also means that it becomes much easier to enforce organisation-wide standards and policies, especially for secret management and quality assurance.
Building Internal Developer Platforms Guide
Learn how to design and build an IDP that accelerates software delivery and reduces complexity.
Categorization of tools and components
Many articles simply list various platform engineering tools without offering any categorization. As a result, you’re left with a scattered collection of tools, and the burden of figuring out how (or if) they fit into your platform engineering tech stack.
To bring clarity and structure, we categorize these tools using a “reference architecture” popularized by platformengineering.org. This framework breaks down the ecosystem into five core components, known as “planes”:
- Developer Control Plane: All components through which developers interact with the platform. Typically includes GUIs / portals, source control, cloud development environments (CDEs), as well as configuration standards that developers maintain themselves (typically in their source code repository), such as ansible playbooks, helm charts, devfile.yaml etc.
- Integration & Delivery Plane: This is where all the automation happens. CI/CD pipeline tools, infrastructure automation, as well as other automation tools (e.g. platform orchestrators) are typically shown as part of this plane.
- Monitoring & Logging Plane: As the name suggests, this is where all observability tools are located.
- Security Plane: Secrets management, policy tools and other security tools.
- Resource Plane: Compute and storage.
Not all internal developer platforms necessarily have all five planes, and it doesn’t always make sense to divide an IDP into those five planes, e.g. when some of them are covered in the same tool or platform.
Visually it looks like this:
Next, we show you an example of how to design an IDP and the tools you could consider.
Example: Building an Internal Developer Platform
Here’s a breakdown of tools you could use to build an IDP. Important note: There are many tools available (Commercial and open source tools). Those referenced in this article are only examples.
Developer Control Plane
#1 Developer Portal
Why it’s important: Internal developer portals serve as the unified interface and allow developers, teams, and engineering managers to discover services, track ownership, enforce standards, and improve software. We wrote about Developer Portals in detail in this blog post 5 Internal Developer Portals (…and what software engineers say about them). The platform engineering team ensures that the portal stays up to date, integrates seamlessly with existing tools, and evolves based on developer feedback.
Tools to consider:
- Engine Forms: Engine forms are lightweight, json-schema-based forms which can serve as simple user interfaces to e.g. trigger a deployment, provide information about pipeline status, etc. Engine forms are useful for fast prototyping and as simple user interfaces for individual use cases, however they are not intended as a full portal solution. For an IDP, a dedicated portal makes sense, to which Cloudomation Engine can expose data and services, which developers then consume via the portal.
- Backstage: Backstage is a popular open-source framework for building developer portals. It’s not a plug-and-play solution; it requires ongoing effort and engineering resources. For organizations with the right capacity, Backstage delivers a powerful and highly flexible developer portal solution.
- Port: Port offers a no-code setup that makes it easy to get started quickly. It also has automation capabilities, allowing you to respond to events or trigger actions based on user input.
- Cortex: “Cortex is the enterprise Internal Developer Portal built to accelerate the path to engineering excellence.” It has a comprehensive service catalog, scorecards and integrates with a wide array of tools. Unfortunately, they only provide their pricing on request.
#2 Cloud Development Environments (CDEs)
Why it’s important: CDEs are remote development environments that are either hosted in the cloud, or self-hosted. CDEs allow developers to work from consistent, standardized environments that eliminate “it works on my machine” issues. The platform engineering team ensures that CDEs are secure, fast, and integrated with the developer workflow.
Tools to consider:
- Cloudomation DevStack: Cloudomation DevStack Cloud Development Environments (CDEs) are fully equivalent to local development environments. Complex applications can be run directly in the CDE. The source code can be mirrored locally, which means that local IDEs can be used. Developers do not have to change existing working methods, but can work with CDEs as they would locally – only with more resources and without troubleshooting local deployments.
- Gitpod: With Gitpod, you can launch secure, context-rich environments built for developers and their agents at enterprise scale.
- Coder: Coder provides secure environments for developers and their agents.
We wrote an article about available CDE tools here: 7 Remote Development Tools at a Glance.
We’ve also put together a comprehensive whitepaper covering all the major tools and vendors, complete with a detailed comparison table. As far as we know, it’s the only resource offering such an in-depth comparison of CDEs.
Integration & Delivery Plane
#1 CI Pipeline
Why it’s important: Automates code validation, testing, and faster feedback loops.
Tools to consider:
- Cloudomation Engine: Natively build CI pipelines from scratch, or migrate CI pipelines from other tools, integrate existing tools, orchestrate and extend existing pipelines.
- GitHub Actions: Native CI for GitHub, with customizable workflows.
- CircleCI: Highly scalable, with support for advanced parallelism.
- Buildkite: Developer-centric CI with scalable infrastructure.
#2 CD Pipeline
Why it’s important: CD pipelines automate the safe, repeatable deployment of software.
Tools to consider:
- Cloudomation Engine: End-to-end deployment automation. Automate complex deployment logic using Python. Gain full visibility with visualized deployment processes.
- Argo CD: GitOps-based delivery for Kubernetes.
- Flux: Kubernetes GitOps controller.
- Octopus Deploy: Suited for multi-cloud and on-prem environments.
#3 Platform Orchestrator
Why it’s important: Orchestration tools provide the logic to tie workflows together across tools and services.
Tools to consider:
- Cloudomation Engine: Pure Python Framework for Platform Engineering. Provide self service tools, automate complex tasks and get full visibility into your infrastructure with just one tool.
- Humanitec: A platform orchestrator providing dynamic environments.
Read more: Cloudomation Engine vs. Humanitec
Monitoring & Logging Plane
#1 Observability
Why it’s important: Observability tools provide visibility into the health, performance, and reliability of applications and infrastructure. The platform engineering team maintains dashboards, alerting rules, and ensures that teams get actionable insights.
Tools to consider:
- Prometheus: Monitoring and alerting toolkit, especially for Kubernetes.
- Grafana: Dashboarding tool often paired with Prometheus.
- Datadog: Cloud monitoring and analytics.
Security Plane
#1 Secret Manager
Why it’s important: Secret managers securely store and distribute credentials, API keys, and other sensitive data.
Tools to consider:
- HashiCorp Vault: Industry-leading secrets management.
- AWS Secrets Manager / Azure Key Vault / GCP Secret Manager
- Sealed Secrets (Bitnami): Encrypts secrets for Kubernetes.
Conclusion: Building Blocks, Not a Shopping List
If there’s one thing to take away from this article, it’s that platform engineering isn’t about picking the flashiest tools off a shelf, it’s about curating the right building blocks to create a seamless developer experience.
Think less about “which tool should I pick?” and more about “how can I design a platform that feels invisible and powerful to my developers and provides business value?”
Because the real magic happens when these tools stop being individual puzzle pieces and start becoming part of a cohesive developer platform, where developers barely notice the underlying complexity because the platform works with them, not against them.
To build a truly cohesive IDP, a core focus has to be on integrating all the different tools and services that are needed. A painful lesson that many platform teams learn early on is that the feature set of individual tools is far less important than the ability to connect these tools with the IDP, and to provide it to software engineers with a good user experience – because otherwise, even the flashiest tool will just sit on the shelf and gather dust.
As such, a central integration component (like a platform orchestrator) is key to building a successful internal developer platform.
Now that you're here...
Cloudomation Engine is a platform orchestrator that enables you to provide self-service tools, automate complex tasks, and gain full visibility into your infrastructure.
Let’s talk about how Cloudomation
can make that happen for you.
