Internal developer platforms (IDPs) have become essential for streamlining software development and deployment processes in modern tech environments. An IDP is a set of tools and functionalities allowing software development teams to automate part of the development process while forming a standardized way of doing things across the company, often referred to as a golden path.
Leading companies like Spotify, Netflix, and Google have pioneered IDPs to enhance productivity, automate workflows, and ensure scalability. This article explores the essential features and best practices for implementing and operationalizing an IDP, leveraging insights from industry leaders to guide your journey.
The number of tools necessary to build scalable, secure, maintainable, and robust software continues to increase. Modern systems need container deployment or orchestration, infrastructure as code functionality, build pipelines, and many other tools. They also require many skills from developers to build the core functionality of a product. All of this creates expectations on developers to understand all of the complexities of a system even for small changes such as adjusting an environment configuration or adding a testing development.
Investing in IDPs pays off by streamlining the development process and improving developer productivity. One team can be knowledgeable about deployment, provisioning, and infrastructure in general, while the other teams can focus on what they do best: developing the product.
IDPs establish processes that can be automated and enforced within the software development lifecycle. They allow better cross-team communication, improved security practices, automated compliance checks, and quick feedback loops. IDPs also improve the developer experience and reduce operational overhead through automation and self-service functionalities.
{{banner-large-dark="/banners"}}
Efficient IDPs are characterized by a few essential capabilities. IDP users need to make sure that all of the following features are available to them.
All users of the IDP should be able to automatically provision a new environment with the click of a button and should otherwise manage existing environments within the user interface. Great integrations provide CLI or shell access to the environments when necessary. More about ephemeral environments can be found here.
Container orchestration should be handled by the infrastructure teams and abstracted away from the development teams while still providing options to customize and adjust infrastructure as needed via infrastructure-as-code changes.
CI/CD is already a staple in modern software development cycles, and an automated CI/CD pipeline should be integrated into the IDP. The underlying system should be irrelevant since good IDPs keep the integrations abstract. All pipeline runs should be visible, versioned, and retriggerable. This should be integrated with a version control service (e.g., Github) so that builds are automatically started upon merging code.
{{banner-small-4="/banners"}}
In general, secrets can be difficult to store, share, rotate, and manage. IDPs often provide functionality for managing these secrets with a simple UI, where users can view and update secrets with the click of a button, leaving the propagation of the secrets to the relevant containers up to the underlying infrastructure.
Development teams should have the ability to import various monitoring dashboards and integrate and configure alerting and logging features into the visible panels associated with each service, reducing the number of places a developer needs to go to debug and/or ensure system health. Some of the best dashboards within the IDP allow for acknowledgment and resolution of alerts that have been triggered as well as a historical view of past alerts.
The centralized and standardized nature of IDPs lends itself perfectly to storing all types of documentation. Good IDPs provide an infrastructure that retrieves documentation and READMEs from code repos and provides a searchable interface for users.
Anyone who needs any information about a system or an architectural decision can search within the IDP and be led directly to the results. This creates the perfect platform for hosting onboarding and learning tools, which can be added to the documentation store, acting as a centralized knowledge base for new and existing team members alike. In other words, the IDP should essentially act as a developer portal and be the main interface among APIs, SDKs, other interactive digital tools, their users, and all stakeholders.
Here are some effective practices to get the most out of your internal developer platform.
When developing an IDP, the architecture of the IDP must be modularized. This means that there is a base skeleton for the IDP where any team can add an extra feature to the platform whenever necessary.
Modularizing the platform prevents single points of failure because a single module breaking will not bring down the entire platform. This also improves the system’s maintainability, as single teams can own and maintain modules while a dedicated platform team owns and maintains the skeleton.
Modularizing also allows development teams to customize their experience to best fit their needs, adding available features to various views within the platform only when needed, and allowing them to easily extend something if it is not yet provided by the platform.
Finally, this sets up the organization to scale as needed, with the IDP able to grow alongside the growth of users, projects, and general resources without needing any larger refactoring or redesign that might require extra time.
{{banner-small-1="/banners"}}
Deciding to build an IDP from scratch is a major decision that requires a lot of time and energy as well as stakeholder buy-in, strong alignment, and expectation management. To ensure that the project is successful, the implementation should be done incrementally rather than attempting to build a “complete” system in one go.
Spend time before implementation identifying the pain points of the current infrastructure and processes. Single out the areas where an IDP could make the most positive impact, and then design a strategic vision for the IDP with those areas as the starting points.
Clearly define success metrics from the beginning and constantly gather metrics to help measure success. Building a user-centric product and providing an opportunity for quick and frequent feedback loops with IDP users will be imperative to gathering these metrics. These metrics and feedback loops will be the inputs that determine how to proceed with further building out the IDP, and through frequent iterative adjustments, the IDP will come to life until it is a part of day-to-day work for all developers.
Centralization does not necessarily mean that every user needs to have access to every aspect and feature, so when building an IDP, it is imperative to integrate identity and access management (IAM). Since the IDP will provide management tools for various things such as deployments, secrets, and internal documentation, admins should be able to create, manage, and otherwise organize access groups not only for the platform itself but also for all external applications where access management might be necessary. This includes the cloud platform where resources are deployed as well as tools for communication, project management, and developer productivity. Having a single place to go to where all forms of authentication and authorization management can be managed saves time and effort.
IDPs should also be a centralized place for information about and even enforcement of various policies and compliance considerations that are relevant to the system being built. For example, suppose that it is known that a particular microservice does something vital to the business, such as dealing with finances or user data management. In this case, the CI/CD pipeline should automatically integrate a code check or an extra version control main branch control, such as minimum test coverage or minimum pull request approvals from team members in a specified IAM group.
In the current cloud-focused era of software development, it is imperative to design and build tools and workflows that support the needs of software engineering teams in a self-service manner. The teams building the IDP should view the platform as a product and the other software engineering teams in the organization as their customers. This implies that the IDP should be developed in a way that caters to the users.
The platform should be easy to start using and have clear documentation. The tools and features offered should not force anything on the users, and all provided workflows should be flexible. The platform should also provide security and compliance by default.
Building the IDP with the mindset that it is a product for users ensures that the IDP that is built will be compelling to use.
{{banner-small-2="/banners"}}
Apart from neglecting the aforementioned best practices and core functionalities that all good IDPs have, there are a few common pitfalls that teams run into when attempting to adopt IDPs, particularly when trying to implement one from scratch.
One of the main goals of the IDP is to improve the developer experience. While implementing an IDP, it is ideal to not disrupt developer work through massive change—teams should not always need to take one step back to go one step forward. Of course, this is easier said than done, but this can be made easier by limiting the number of transitions that need to be made and prioritizing integrating with tools that developers are using. The IDP should be a centralized tool where developers can get the majority of information they need by going to one location, and they should not have to migrate everything they are doing to the new platform before being able to use it.
Early integration of tools that are already being used will also help the adoption rate. The transition phase will be smoother, resulting in minimum reductions in efficiency, if any at all, and an increase in the general feeling of confidence in using the newly created IDP over their usual distributed workflow.
The name of the game should be to automate as many processes as possible and, in general, to streamline work processes and reduce manual intervention. This can be done by utilizing powerful tools such as Terraform to centralize logic and configuration around spinning up infrastructure as well as maximizing the use of CI/CD pipelines.
Not focusing on automation results in a larger risk of human error, reduced efficiency, and a lack of cohesiveness across solutions. At the absolute least, the “simple” things should be automated, such as deploying services, updating monitoring dashboards, collecting metrics, collating documentation, and managing dependencies.
One of the drawbacks of automating so many things away from the developers who will be using the IDP is that the developers are no longer always required to maintain the basic things such as the pipeline definitions or the canary deployment functionality. This means that many developers do not learn these tasks or leave tasks related to those topics to infrastructure teams maintaining the IDP, resulting in knowledge silos.
To break down and prevent these knowledge silos, knowledge must be shared from day one. This can be done in a very passive way because developers will search for the information when they need it and not necessarily need to know everything at any time. Documenting decisions regarding the IDP implementation, underlying infrastructure, functionalities, nuances, tricks, and anything else that could potentially be useful to any given individual should be a priority from the beginning of the project.
{{banner-small-1="/banners"}}
Implementing an internal developer platform from scratch can be quite an endeavor that requires lots of effort, planning, and (in many cases) prior knowledge of infrastructure. One way that many teams can benefit from the use of IDPs without needing to put in all of the effort upfront to build one themselves, is to use an off-the-shelf solution.
Coherence is an IDP that organizations can purchase, control, and customize to meet their needs. The Coherence platform offers a modular design, CI/CD, and IaC execution layer all as one product, functioning out of the box. Secrets management is also handled smoothly alongside automatically deployed preview environments.
No matter what route organizations take when determining how to launch an internal developer platform, they must ensure that they choose a solution that follows best practices and provides the best possible developer experience for their squads. This will result in increased efficiency and, in turn, the best possible end product or experience for end users.
