Community post by Abby Bangser, Christophe Fargette, Piotr Kliczewski, Valentina Rodriguez Sosa
Let’s define what is an IDP (Internal Developer Portal)
The term IDP can be confusing, as some of the industry refers to Internal Developer Portals and some speak about Internal Developer Platforms. And the fact these are two different things helps us actually to define the portal, which is our focus today. An Internal Developer Portal (IDP from now on in this article) is an interface that combines the essential tools, information, and support to enable software developers to succeed in their jobs. These interfaces are often webpages that allow users a familiar interface while integrating all the tools capabilities and actions they depend on. An IDP is an addition to your existing tools. Not a replacement for your current solution.
What’s the value of using an IDP?
We all know too well that different services are scattered around the infrastructure. It is considered tribal knowledge on how to get things done, which is acquired over time. It is not surprising that the most productive developers are usually those who work the longest. Thanks to IDPs, it doesn’t need to be this way. They bring a single pane of glass to interact with the infrastructure and reduce cognitive load. Additionally, they will provide organizations with self-service capabilities. IDPs provide a way to share best practices across different teams and standardize infrastructure management.
What are the main use cases? Who are the personas?
Internal Developer Portals are a powerful tool for Developers to build, deploy and manage any application without looking into the underlying infrastructure. Additionally, they could access other resources in a secure and controlled self-service approach, such as virtual machines, namespaces, clusters, etc.
IDPs are very powerful and can integrate diverse tools called plugins, enabling developers to access platform capabilities without needing to learn and manage these tools directly. Platform Engineers and Operations can shape the developer experience by integrating the IDPs with business specific plugins and building software templates to be consumed by developer teams.
It is important to keep in mind that software engineers are the most common consumers of portals, but given their visual and web based nature, there are many other roles that find value in them. This includes managers who want to get an overview of the system, QAs or SMEs who want access to testing environments and to validate features, and Customer Support agents who may want to track down the state of an issue.
What are the anti-patterns?
Some portals try to build the data and tooling logic into their interface. This often leads to challenges with scaling both horizontally (to other interface types such as CLIs or CI/CD pipelines) and vertically (as in composing more complex experiences within the portal).
Another concern is when the data in the portal can become stale. This may be because of systems getting out of sync or a lack of adoption, leading to reduced investment. In either case, the immense value of a portal is a single pane of glass access to information, so it must be easy to keep current with what is available on the platform.
How an IDP relates to Platform Engineering and Platform as a Product
Platform Engineering is the practice of taking common elements available in the market (such as cloud resources or SaaS products) and engineering them fit for their own business while prioritizing the use cases that are most common across the organization. The way to be successful here is to apply the same software practices to any engineering team, and therefore, treating the platform as a product is a key part of long-term success. This means investing in understanding your customers, drawing clear boundaries of what the product is trying to achieve (and therefore also what it is not going to help with), and constantly looking at ways to improve, which can be adding new features or deprecating ones that are no longer useful and cost a lot to maintain. A portal is frequently identified as a platform feature that will support adoption and usability and is an area the team will invest in.
Main challenges and solutions for Day 2 operations
An Internal Developer Portal is needed to help bootstrap new engineers and projects and maintain the entire software lifecycle at the organization. This includes streamlining day-to-day operations, which can be done by using orchestration. Successful orchestration needs to consider everyday business needs including Infrastructure as Code automation, incorporation of all business processes, and the reality that success often depends on managing handoffs across several different teams. The orchestration tooling can interact with a ticketing system and any services needed for approval processes or manual steps that are hard to automate. Good examples of orchestration are onboarding and offboarding users, infrastructure management or application modernization.
What’s the Future ahead and opportunities for innovation
What are the trends you have seen when working with customers, and How do you see IDPs evolving in the next few years?
The biggest trend I see is that people are getting value from portals due to their user-friendliness and visual nature, which means teams are ready to (and need to) invest in longer-term operability. This includes decoupling logic from the front end, building their portal via Infrastructure as Code and declarative techniques, and sharing the load with the community through sharing Open Source plugins.
How far can an IDP go? What are the use cases that can bring innovation to diverse teams?
Application modernization development and maintenance are part of many organizations’ daily activities, and developers are still a crucial part of this process. Providing a self-service approach where developers can easily access legacy applications and provision virtual machines will remove barriers and accelerate the software development lifecycle from:
- Removing the complexity for DevOps and Developers
- Reducing the time to access a VM
- Standardizing VM creation with best practices
- Shared best practices and standards
Onboarding end-users
Usually, when a new person joins a company or a new consultant needs to be onboarded, there is a lengthy list of steps containing account creation and infrastructure provisioning, and most of those steps require interactions with many teams. Effective Internal Developer Portals offer self-service ways to automate onboarding steps, so teams maintaining systems provide an action to onboard, which significantly accelerates the time needed for new employees to become effective.
The same building blocks can be used to orchestrate infrastructure management like migrating virtual machines from one infrastructure to another, application modernization, and container or virtual machine management combined with business-related actions like approvals.
Security
Security will become more important in IDPs. The templates used to create new applications, or provision infrastructure, will have security baked in, so developers don’t have to add it later. The supply chain will be entirely secured and provide features not only to scan for vulnerabilities in the source code and dependencies but also to generate signatures, SBOM and more.
IDPs and future- in the next five years
Portals will continue improving their impact through broader use cases in users and technologies.
AI features such as assistant/chatbot will add very powerful capabilities to developer-centric IDPs.
Successful portals will focus on their extensibility and community engagement, allowing them to onboard both existing tooling (yes, even mainframes use cases!) and future use cases.
To conclude, the future of Internal Developer Portals is to continue building a user-centric approach that drives business further with innovation, reducing friction and thinking on the personas and bringing together their knowledge, processes, and best practices into one single point of contact to provide an excellent user experience beyond Developers to different teams such as Data Scientists and any teams that build applications and components to end users.