Ready to start?
Internal Developer Portals’ big breakout moment
Internal Developer Portals got their big breakout moment in 2023 with recognition in Gartner’s Hype Cycle for Software Engineering 2023, and acknowledgement that developer portals are the most mature tool to drive platform engineering in Gartner’s subsequent Market Guide for Internal Developer Portals. They were also cited as the most frequently piloted
technology in the 2022-2024 Gartner Technology Adoption Roadmaps for IT Leaders
Survey aimed at identifying technologies that improve developer experience.
TL:DR - Internal Developer Portals are becoming a big deal for engineering leaders who want to reduce the cognitive load on developers, drive productivity and improve engineering standards.
Why a report on developer portals?
As with any other big breakout moment in technology, portal usage is still in its infancy, and while the potential is huge - there are likely to be varied reasons for adoption, different types of use cases, and numerous ways in which the market can evolve.
We wanted to get a picture of where we are now with portals, and ensure that engineering leaders that are seeking to improve developer productivity, experience, service reliability and operational efficiency, gain a better understanding of the key tool that will help them to address these challenges. So we surveyed 100 engineering leaders from the US and Western Europe, and asked them about platform engineering adoption, whether they wanted a portal or what type of portal they used, and how they measured its success.
Here’s what we found:
2024 is a big year for Internal Developer Portals
Almost 85% of companies surveyed have either started implementing a portal (50%) or are planning to do so in the next year (35%). It’s clear that companies are committed to using portals on top of and in addition to their commitment to platform engineering. And we found that respondents acknowledged portals as a means to improve developer productivity and to enable faster deployment.
Just because you call it a developer portal, doesn’t mean it is
Of the more surprising findings, when asked what type of internal developer portal their company uses, 35% reported using spreadsheets with microservice data. But given its highly manual nature and an absence of developer self-service capabilities, this is exactly the kind of approach that an Internal Developer Portal is aiming to help companies shift away from. A further 12% said they used a self-service CI-based platform that isn’t a portal.
This shows just how nascent the space is that the market may be wrongly assuming that software catalog capability in a spreadsheet or a self-service CI constitute an Internal Developer Portal. The pillars of an actual Internal Developer Portal will be refined and over time respondents will become more aware of the make-up and benefits of a portal. At Port, we count four pillars of a portal: self-service, software catalog, automations and scorecards, along with developer dashboards and visualizations.
Surveys and custom reports preferred over space and DORA frameworks to measure productivity
An overwhelming majority (75%) of respondents used surveys or custom reporting to measure developer productivity instead of recognized frameworks such as SPACE or DORA. Users could prefer surveys and reports due to difficulty of implementation of the frameworks, or because they feel that the insights they glean from surveys and reports wouldn’t necessarily be captured by the frameworks. This echoes a report which found that SPACE and DORA are not particularly effective approaches to measuring team performance, according to engineers.
Without platform engineering, developers are spending too long on non-core work
A staggering 70% of respondents said developers spent 3-4 hours on non-core tasks due to the absence of platform engineering. And for 68% of respondents, the average lead time to deploy software to production is several weeks or even months. In both cases, the negative impact on organizations could be significant - no wonder the industry is focusing on developer productivity, platform engineering and the reduction of cognitive load. Of course, we recognize that perhaps some of the non-core work will remain (meetings, anyone?).
Only a third of respondents are using portals to drive engineering standards
While respondents said the primary objective in implementing platform engineering was to enhance software quality and engineering standards, only 34% of respondents use internal developer portals to drive engineering standards. This once again illustrates how the developer portal space is still emerging and that organizations are still getting to grips with how they can best utilize a portal to provide multiple benefits, including driving and maintaining engineering standards.
Want to read the report in its entirety? It’s here, and you don’t need an email address to download it.
If you’d like to know more about Internal Developer Portals, here’s our guide.
Check out Port's pre-populated demo and see what it's all about.
No email required
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Check out Port's pre-populated demo and see what it's all about.
(no email required)
Contact sales for a technical product walkthrough
Open a free Port account. No credit card required
Watch Port live coding videos - setting up an internal developer portal & platform
Book a demo right now to check out Port's developer portal yourself
Apply to join the Beta for Port's new Backstage plugin
It's a Trap - Jenkins as Self service UI
Further reading:
Example JSON block
Order Domain
Cart System
Products System
Cart Resource
Cart API
Core Kafka Library
Core Payment Library
Cart Service JSON
Products Service JSON
Component Blueprint
Resource Blueprint
API Blueprint
Domain Blueprint
System Blueprint
Microservices SDLC
Scaffold a new microservice
Deploy (canary or blue-green)
Feature flagging
Revert
Lock deployments
Add Secret
Force merge pull request (skip tests on crises)
Add environment variable to service
Add IaC to the service
Upgrade package version
Development environments
Spin up a developer environment for 5 days
ETL mock data to environment
Invite developer to the environment
Extend TTL by 3 days
Cloud resources
Provision a cloud resource
Modify a cloud resource
Get permissions to access cloud resource
SRE actions
Update pod count
Update auto-scaling group
Execute incident response runbook automation
Data Engineering
Add / Remove / Update Column to table
Run Airflow DAG
Duplicate table
Backoffice
Change customer configuration
Update customer software version
Upgrade - Downgrade plan tier
Create - Delete customer
Machine learning actions
Train model
Pre-process dataset
Deploy
A/B testing traffic route
Revert
Spin up remote Jupyter notebook
Engineering tools
Observability
Tasks management
CI/CD
On-Call management
Troubleshooting tools
DevSecOps
Runbooks
Infrastructure
Cloud Resources
K8S
Containers & Serverless
IaC
Databases
Environments
Regions
Software and more
Microservices
Docker Images
Docs
APIs
3rd parties
Runbooks
Cron jobs