The building blocks of an IDP

Table of content:

1. Why we need IDPs
2. The building blocks of an IDP

‍

In the prior chapter we discussed Why we need IDPs. Let's discuss now the elements of an internal developer portal and which indigents are important snd when.

An internal developer platform is a set of tools, frameworks, and services that enable developers to build, test, deploy, and monitor software applications within an organization more efficiently and effectively. It provides developers with a stable and consistent environment for building and deploying software, reducing the time and effort required to launch new applications and services. The term Internal Developer Platform refers specifically to the collection of tools serving resources whereas, the term `internal developer portals` refers to the physical interface to the developer platform. Therefore, the Internal Developer Platform is overarching and can encompass the portal interface as well, if applicable. In this previous blog post we provided an overview of the pain point arising from the increasingly complex tool stack, cloud native technology, and increased need for security and compliance. IDPs are meant to relieve these pain points experienced by engineering organizations and are becoming more critical than ever. 

Internal developer platforms evolved over the last 7 years from self-built tools to an end-to-end Platform as a Service (PaaS). The creation of internal tools and internal successes shared by major enterprises, including Spotify and AirBnb, brought the spotlight on the utility of internal developer enablement. For example, Backstage, an open platform for building developer portals, donated by Spotify to the Cloud Native Computing Foundation, promoted the utility of a centralized software catalog approach.  

Internal developer platforms provide access to a wide variety of tools, frameworks and services used across the enterprise from planning (Jira) to Authentication (Auth0), Version Control (Git-based tools) to cloud resources such as Kubernetes, AWS computing resources, and much much more.  

Various frameworks and reference architectures have been presented in the industry. For example, this article on DevOps.com presents sample reference architectures for AWS, GCP and Azure as well as tooling landscape framework. The common building blocks among these are a developer control plane, resource plane, integration and delivery plane, monitoring and logging plane, and authorization. Integrations with standard developer tools running from source control, to cloud resources, across the full suite of DevOps tools are an essential component and is required for an IDP to relieve the DevOps bottlenecks.

‍

Building Blocks of an IDP 

This diagram illustrates the common building blocks of an IDP and how they function as a system. 

As shown above these building blocks divide the architecture into different panes that connect together to provide all the functionality of an IDP. 

Admin Plane

This component gives the IDP admins control over who can access the service, what resources they can access and what permissions they have (sometimes powered by Open Policy Agent), any parameters required to integrate to 3rd party platforms: secrets, environment variables such as timeouts etc. If your IDP supports just-in-time access, admins need an interface to define the approval flow. Some IDPs will also include a cost management component that allows them to allocate budget across departments so they can better control spending. 

The Admin Plane can include components that control the policy (guardrails), secrets (security features), environmental configurations, approval policy, and budgetary controls. This plane sets the system wide controls to provisioning, tracking and securing applications. The configurations are generally managed by the DevOps team and should be enforced system wide. 

User Plane

The user plane is the developer facing component to access the system with the ability to find, request, and receive resources. This pane can be in the form of a portal or catalog or can be connected with existing tools (Slack). The interface should be easy to use, self-explanatory. This is an area what companies tend to neglect and a big reason why IDP initiatives fail. You use some kind of CI tool to trigger jobs but the interface requires constant context switching, familiarity with the job names, the required parameters etc. It’s a likely cause for frustration and prone to errors. 

Control Plane

This pane is the core interface to the system. Some of the components:

• Authentication manager - Authenticates the user to confirm the user is who they claim to be and makes sure unauthorized users can not access the system, given the sensitive nature of its operation.
• Observability - The ability to troubleshoot when things fail.
• Knowledge management - IDP can also be used to make organizational knowledge easily accessible to users. Many organizations have their knowledge spread across multiple systems: Google Docs, Confluence, Notion, Github, Google drive, Dropbox are just a few examples. It’s time consuming and a poor experience to have to search through all these platforms and IDPs can aggregate that knowledge into a single location, making your knowledge more usable and accessible.
• Audit - This component keeps track of who’s doing what and making sure there's an audit trail and admins can easily track back any issues.
• Deployment manager - A state machine that keeps track of the state of your requests and the status of resources that were provisioned. Some actions might run in sequence and potentially across multiple platforms. You want to properly handover from one action to the next, keeping sync of the status of each action.
• Application configuration - This component will include any application specific configuration.

Execution Plane

This plane includes an abstraction layer between the user interface (i.e “I want to provision an EC2”) to the platform specific SDK/API (CDK/Boto3 for example). You want to have a common interface that simplifies the maintenance and allows you to extend the functionality easily. This plane will also allow you to schedule actions or batch them.

Integrations

This component is platform specific and will include the ability to execute specific actions on a designated system typically using an API or SDK.

Enforcer

Whereas admins can define policies, associate them with resources and apply them to users, the enforcer, as its name suggests, enforces those policies. Every action, before being executed will go through this component which will authorize or deny the action based on the user, the resource, the action and additional metadata. The enforcer should also communicate with the approval flow.

Webhook

While most IDPs allow users to trigger actions and consume infrastructure related resources, next generation IDPs will allow bi-directional communication allowing your engineering platforms to trigger automated actions that are triggered by system events.

‍

Benefits of an IDP 

The basic building blocks presented above should work seamlessly together to relieve DevOps toil and increase productivity and results across the engineering organization from the developers, to managers, and beyond all the way to the customers. When developers can focus on building software rather than wrestling tools, all associated teams benefit, resulting in a better product in the end. Organizational benefits include increased developer productivity, reduced time to market, greater agility in the organization, better collaboration, and improvised quality. 

Mapping the building blocks back to the pain points ensures that the system is functioning to solve developer problems, providing ‘golden paths’ to productivity rather than adding yet another tool to the stack.

‍

‍