The top 10 ways to use an internal developer portal: what we’ve learned from our customers

Improving developer productivity and experience, better managing standards, abstracting away complexity; these are just some of the headline benefits of using an internal developer portal. There are a (seemingly) endless number of use cases for portals. 

We wanted to establish exactly which are the more popular users of an internal developer portal. To do this, we analyzed the way customers actually use Port and ranked the top 10, by popularity.

1. Discoverability and context (via the software catalog)   

The service catalog is the first element that’s built in an internal developer portal - reflecting the state of the SDLC - because everything in the portal (scorecards, self-service, dashboards) relies on it.A service catalog directly improves the developer experience by enabling developers to: 

• find the information they need, especially when on-call 
• reduce the manual work required to update data in other places, such as Jira, spreadsheets or CMDB, and not have to switch between various interfaces, 
• Grow re-use of services, APIs and more, through the fact that they are discoverable, and
• adopt InnerSource practices as a result of discoverability. 

‍Port’s software catalog is populated in a way that prevents maintainability issues (which are common with Backstage). It is also real time, meaning it includes runtime information. Further reading: Top examples of service catalogs in action. 

2. Drive organizational standards (using scorecards)  

Almost all Port customers use scorecards.Scorecards can grade production readiness, code quality, migration quality, operational performance, and more. By defining scorecards for elements in the organization’s software catalog, organizations both set standards, track them and drive developers to fix non-compliance or make changes when standards evolve. But internal developer portals go beyond just setting standards; they also provide the practices to rectify cases when standards aren’t met. Using production readiness as an example, you can not only monitor assets using dashboards and automated alerts, but also  drive actions for rules that aren’t met - whether it’s missing documentation, a misconfiguration detected or any other compliance issue. And when the time comes to add a new requirement, you can update the relevant scorecard and create an initiative page so everyone can act. 

‍Further reading: Managing production readiness in an internal developer portal - a how-to guide.

3. Shipping faster to production using developer self-service

One of the key obstacles to developer productivity is waiting for tickets or taking too long to perform certain actions, as a result of cognitive load, too many interfaces or lack of clarity as to how to perform these actions. Developer self-service provides developers with autonomy to perform tasks themselves without filing tickets or waiting for other teams. Our post on defining a portal MVP contains an example of how to create self-service that lets developers ship quicker to production. Self-service actions include scaffolding a new microservice, but also provisioning, terminating and performing day-2 operations, which are often overlooked.  Recently, cybersecurity company Cybersixgill’s director of cloud operations Naveh Katz explained that with developer self-service in the portal, building new microservices takes minutes compared to days without an internal developer portal. 

‍Further reading: How Cybersixgill has significantly improved developer efficiency with self-service actions‍

4. Improving API management 

Just like a software catalog addresses microservice proliferation, an API catalog addresses API proliferation, by making APIs discoverable and showing them in context, reducing replication and making it easier to scaffold APIs and track them.
Internal developer portals offer more than traditional API catalogs by showing APIs in context and enriched metadata or structured performance feedback on the quality of the API.Self-service actions in the portal can enable developers to scaffold APIs that are compliant and secure by default, and streamline API lifecycle management. Scorecards help ensure API quality and compliance, while initiatives can enable managers to better track progress of API governance improvement. Meanwhile, dashboards can provide customized information about APIs to different stakeholders. 

‍Further reading: Manage your APIs using an internal developer portal
                          API catalog vs API developer portal ‍

5. Simplifying Kubernetes for developers 

With Kubernetes emerging as the de facto cloud development platform, developers have been tasked with interacting with it more and more. However, Kubernetes requires expertise that many developers don’t have. This is why a large proportion of organizations using Port are relying on the internal developer portal to provide them with the right abstractions and guardrails for developer interaction with Kubernetes. Further reading: How to drive a culture of Kubernetes standards with platform engineering. 

6. Reducing MTTR 

Reducing MTTR factors in the time it takes to fully resolve a failure, including detection, diagnosis, repairing and ensuring it won’t happen again. While incident management tools can handle incident logistics, the burden is on the on-call engineer to resolve it. But anyone on-call needs more support in order to reduce the mean time to resolution (MTTR). The internal developer portal provides on-call with the information they need at their fingertips including being able to answer ‘what are the upstream/downstream dependencies’, identifying the owner of a service, obtaining underlying infrastructure health metrics, and checking if a service is being monitored correctly. Portals also offer automated runbooks, making incident resolution faster. They can also be used to grant temporary access to cloud resources.

These capabilities speed up detection, diagnosis and repair by providing you with context you wouldn’t otherwise have. To reduce the chances of an incident happening again, you can use maturity scorecards to ensure best practices are always upheld, while SREs can define and monitor MTTR (and other metrics) in the portal’s dashboards so you can more readily identify resources prone to incidents, check how long it takes to recover per team and per service, and establish initiatives to improve. 

‍Further reading: How internal developer portals improve incident management‍

7. Migrations 

You can use a portal to migrate deprecated versions to ensure services, APIs and packages use the most up-to-date version This is crucial for reducing AppSec risks. Without portals, tracking versions is often carried out manually and it’s not easy to tell which versions are used across the board.

TransferGo used the portal to track the yearly PHP version upgrade initiative it has; it previously relied on Jira and Slack which presented significant communication challenges. Now, it uses Port to communicate initiatives and track them by developer, team and service, reducing the previous manual load on developers.

‍Further reading: How TransferGo is revolutionizing developer experience with Port   

8. Engineering metrics and insights (including DORA metrics) 

Since the portal contains all the data it can easily be used to create reports and dashboards on engineering metrics, which are often difficult to create elsewhere. Since the portal also provides the option to drive initiatives, standards and self-service, it can both measure and provide the tools to improve these metrics. 

‍Further reading: Developer experience metrics: best practices, key components and examples  

9. Optimizing and contextualizing cloud costs  

Developers are responsible for optimizing application costs but often lack the necessary context to do so effectively. While they use cloud cost tracking and optimization tools, there's a common issue: stakeholders such as developers, tech leads, product managers, engineering team leaders, and FinOps professionals don't have a clear understanding of the connections between costs, resources, owners, and services.The portal addresses this by allowing users to import and associate resources with their costs. This enables stakeholders to see the costs linked to specific resources and services, along with additional business domain information. Consequently, users can pinpoint areas for cost adjustments and aggregate expenses per domain. 

‍Further reading: Using an internal developer portal for superior FinOps visibility   

10. Managing feature flags

Feature flags act like switches within your software, allowing you to turn features on or off without deploying new code. This gives you the power to gradually roll out new features, test them on a subset of users, and easily roll them back if anything goes wrong. One of the issues engineering teams have while managing feature flags is a lack of context; there’s a lack of clarity on how these flags connect to various environments and services.When remediating, teams often manually create and update spreadsheets to map out these connections. But this method is far from ideal as it’s time consuming and the information gets outdated quickly.Using a portal to manage feature flags, means you can:

• Understand exactly where and how feature flags are implemented across different environments.
• Gain a comprehensive overview of all feature flags used by any given microservice.
• See all the details about feature flags including configurations, available values, and default values.
• Gain insights into the specific settings of feature flags, attributes, and associated segments.
• Toggle on/off features flags while having all the relevant context in the catalog

What else can be done with a developer portal?

There are excellent use-cases that didn’t make it into the top 10 use cases, but we thought that it was worth it to point them out:

Just-in-time permissions

Internal developer portals can increase security by integrating Just-in-time (JIT) permissions. JIT permissions grant developers temporary, elevated access to critical resources only when needed, reducing the risk of unauthorized access and potential security breaches. For developers, this means no more waiting on ticket approvals to access the resources they need, streamlining their workflow. By incorporating JIT permissions into the portal, organizations can streamline access requests, automate approvals, and provide a clear audit trail. Automation further enhances this process by enabling granular rules for JIT permissions. For example, on-call engineers can automatically gain access when their shift begins and have it revoked when their shift ends, ensuring that access is always aligned with operational needs.

‍Further reading: Managing Just-in-time Permissions in a Developer Portal
‍See JIT permissions in the live demo https://demo.getport.io/temp_permissions

‍Unified alerts 

You can use your portal to consolidate alerts from multiple monitoring and/or security tools. This centralized view helps address alert fatigue and provides important context. Developers can quickly see if an alert is from a production or development environment, identify the service owner, and access relevant health metrics. Moreover, because Port dashboards are actionable, developers can directly respond to alerts from within the portal. This could include triggering a runbook or reverting to a previous version of a service, all without leaving the portal. 

‍Further reading: Alert Management With an Internal Developer Portal | Port
‍See the unified alert dashboard in the live demohttps://demo.getport.io/code_alerts

‍Policy enforcement 

Internal developer portals make it easier to enforce company policies. Instead of relying on wikis or training sessions that can be outdated or overlooked, the portal can automatically enforce that developers are following the rules. For example, the portal can prevent developers from deploying a service they’re not authorized to deploy, or it can limit the number of development environments they can create. If a developer needs to break a rule, the portal can automatically require approval from their manager. This helps to ensure that everyone is following the rules and that the company's systems are secure.

‍Further reading: Announcing: automations

‍Concluding thoughts

The internal developer portal may initially be used for discoverability and context, to drive organizational standards and to ship software more quickly to production, but it’s clear that engineering teams are looking at numerous other use cases that can help to improve engineering processes and the experience of all of its stakeholders. 
Want to get started with Port but don’t know how? Check out these resources:

Try: Our live demo
‍Read: Fast-tracking service deployment with Port: a plain vanilla internal developer portal
‍Use: The portal roadmap planner