The 2024 state of internal developer portal report

December 13, 2023

The 2024 state of internal developer portal report

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

{{cta_1}}

Check out Port's pre-populated demo and see what it's all about.

Check live demo

No email required

{{cta_2}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_3}}

Open a free Port account. No credit card required

Let’s start
{{cta_4}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta_5}}

Check out Port's pre-populated demo and see what it's all about.

(no email required)

Let’s start
{{cta_6}}

Contact sales for a technical product walkthrough

Let’s start
{{cta_7}}

Open a free Port account. No credit card required

Let’s start
{{cta_8}}

Watch Port live coding videos - setting up an internal developer portal & platform

Let’s start
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Example JSON block

{
  "foo": "bar"
}

Order Domain

{
  "properties": {},
  "relations": {},
  "title": "Orders",
  "identifier": "Orders"
}

Cart System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Cart",
  "title": "Cart"
}

Products System

{
  "properties": {},
  "relations": {
    "domain": "Orders"
  },
  "identifier": "Products",
  "title": "Products"
}

Cart Resource

{
  "properties": {
    "type": "postgress"
  },
  "relations": {},
  "icon": "GPU",
  "title": "Cart SQL database",
  "identifier": "cart-sql-sb"
}

Cart API

{
 "identifier": "CartAPI",
 "title": "Cart API",
 "blueprint": "API",
 "properties": {
   "type": "Open API"
 },
 "relations": {
   "provider": "CartService"
 },
 "icon": "Link"
}

Core Kafka Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Kafka Library",
  "identifier": "CoreKafkaLibrary"
}

Core Payment Library

{
  "properties": {
    "type": "library"
  },
  "relations": {
    "system": "Cart"
  },
  "title": "Core Payment Library",
  "identifier": "CorePaymentLibrary"
}

Cart Service JSON

{
 "identifier": "CartService",
 "title": "Cart Service",
 "blueprint": "Component",
 "properties": {
   "type": "service"
 },
 "relations": {
   "system": "Cart",
   "resources": [
     "cart-sql-sb"
   ],
   "consumesApi": [],
   "components": [
     "CorePaymentLibrary",
     "CoreKafkaLibrary"
   ]
 },
 "icon": "Cloud"
}

Products Service JSON

{
  "identifier": "ProductsService",
  "title": "Products Service",
  "blueprint": "Component",
  "properties": {
    "type": "service"
  },
  "relations": {
    "system": "Products",
    "consumesApi": [
      "CartAPI"
    ],
    "components": []
  }
}

Component Blueprint

{
 "identifier": "Component",
 "title": "Component",
 "icon": "Cloud",
 "schema": {
   "properties": {
     "type": {
       "enum": [
         "service",
         "library"
       ],
       "icon": "Docs",
       "type": "string",
       "enumColors": {
         "service": "blue",
         "library": "green"
       }
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "system": {
     "target": "System",
     "required": false,
     "many": false
   },
   "resources": {
     "target": "Resource",
     "required": false,
     "many": true
   },
   "consumesApi": {
     "target": "API",
     "required": false,
     "many": true
   },
   "components": {
     "target": "Component",
     "required": false,
     "many": true
   },
   "providesApi": {
     "target": "API",
     "required": false,
     "many": false
   }
 }
}

Resource Blueprint

{
 “identifier”: “Resource”,
 “title”: “Resource”,
 “icon”: “DevopsTool”,
 “schema”: {
   “properties”: {
     “type”: {
       “enum”: [
         “postgress”,
         “kafka-topic”,
         “rabbit-queue”,
         “s3-bucket”
       ],
       “icon”: “Docs”,
       “type”: “string”
     }
   },
   “required”: []
 },
 “mirrorProperties”: {},
 “formulaProperties”: {},
 “calculationProperties”: {},
 “relations”: {}
}

API Blueprint

{
 "identifier": "API",
 "title": "API",
 "icon": "Link",
 "schema": {
   "properties": {
     "type": {
       "type": "string",
       "enum": [
         "Open API",
         "grpc"
       ]
     }
   },
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "provider": {
     "target": "Component",
     "required": true,
     "many": false
   }
 }
}

Domain Blueprint

{
 "identifier": "Domain",
 "title": "Domain",
 "icon": "Server",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {}
}

System Blueprint

{
 "identifier": "System",
 "title": "System",
 "icon": "DevopsTool",
 "schema": {
   "properties": {},
   "required": []
 },
 "mirrorProperties": {},
 "formulaProperties": {},
 "calculationProperties": {},
 "relations": {
   "domain": {
     "target": "Domain",
     "required": true,
     "many": false
   }
 }
}
{{tabel-1}}

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

{{tabel-2}}

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

Starting with Port is simple, fast and free.

Let’s start