Five Best Practices for Building an Internal Developer Portal
As platform engineering has gained momentum, Internal Developer Portals (IDPs) have emerged as a must-have tool to relieve the pressure on software engineers. Gartner anticipates that by the end of the year, 75% of organisations with platform teams will have self-service developer portals.
Often, these portals are built on open source frameworks, with Backstage the most popular. However, without the right ingredients, IDPs are unlikely to be adopted widely enough to deliver the benefits organizations are seeking to achieve.
Based on conversations with engineering leaders, here are five key best practices that can help maximize the success of an IDP:
1. Focus on Self-Service
The primary goal of an IDP should be to improve the developer experience by making it easier to access the tools and capabilities they need to manage the end-to-end software development lifecycle (SDLC). Self-service is therefore a foundational component in any IDP. It needs to be as easy as possible for developers to find what they need to complete the task at hand, whether that’s provisioning infrastructure or pipelines, deploying observability tools, or executing test cases.
The best way to enable this is to build a catalogue of services and documentation, and allow developers to navigate it via an intuitive interface. Discoverability is key here, as IDPs work at their absolute best when developers start to experiment with tools or services that aren’t typically used in their immediate team, and find new ways to drive efficiencies in their workflows.
2. Use Automation to Reduce Toil
An effective IDP should also empower developers to automate as many repeatable workflows as possible, to eliminate unnecessary toil. Basic tasks such as spinning up a new staging environment, and progressing code through the build, test, and deploy process should be highly automated. Infrastructure as Code (IaC) tools play a central role here, reducing the need for developers to be experts in configuring and managing the increasingly complex environments their software runs in. They are therefore free to focus the maximum amount of their time on what they do best – coding, and creating value for the business.
To safeguard quality and security, these automated processes should be governed with scorecards that measure new code against KPIs such as app response time, or vulnerabilities, to prevent any bad releases progressing to production. This takes some of the pressure off developers by giving them guardrails to prevent any of their changes from causing disruption, which allows them to release with confidence.
3. Integrate Everything
Most developers have their own preferred tools and processes that they’ve grown accustomed to over years of experience. With the central goal of an IDP being to improve the developer experience, it’s important to respect these preferences and allow engineering teams to continue working in the way they feel most comfortable, rather than mandating a wholesale change in tooling.
Development toolchains also usually feed information into other critical systems, such as IT service management platforms like ServiceNow and collaboration apps like Slack. Of course, they also need to pull source code from repositories like Git, or access information from a centralized knowledge base.
IDPs therefore need to be fully integrated with the wider ecosystem of third-party and home-grown tooling that developers rely on, so they can work effectively and in whatever way works best for them.
4. Enforce Governance and Control
Engineering leaders need to remain in control of their IDPs and ensure they are being used in the right way to avoid introducing risk. It is therefore important to have governance and control policies set up to enforce best practices and maintain security standards across the SDLC.
IDPs should include Identity and Access Management (IAM) solutions to ensure that capabilities can only be accessed by developers who have the relevant privileges, based on the nature of their role. There also needs to be a clearly defined security policy to ensure that sensitive data is protected from inappropriate use and the organization can maintain compliance with regulatory requirements such as GDPR.
5. Keep It Simple
Of course, it’s also possible to use a purpose-built, enterprise grade platform like Harness to simplify the process. By removing the need to build an IDP from scratch, developers can just focus on creating and running software.
What have your experiences of building an IDP been? Do you have any other best practices to share with engineering leaders?