Blog
/
/
Some takeaways: Gartner’s “market guide for internal developer portals”
Internal Developer Portal

Some takeaways: Gartner’s “market guide for internal developer portals”

Zohar Einy
Zohar Einy
Oct 3, 2023
Sign up
Download PDF
Internal Developer Portal
Example H2
Example H3

Introduction

On September 21st, 2023, Gartner released a market guide for internal developer portals. It also mentioned Port as one of the vendors in the space (we’re super happy about that).

Having read it, I think Gartner makes some very powerful points on where internal developer portals are going and how it all connects to platform engineering. As someone who’s been in the market for quite some time, some of the points really resonated with us.

{{cta-demo}}

Let me explain what these points are:

The Internal developer portal space is white-hot

In Gartner-speak this is “Portals are the most frequently piloted technology in the 2022-2024 Gartner Technology Adoption Roadmaps” with 22% of respondents piloting dev portals.

We’re seeing this too. Seems like we’re in a pivotal time in software development where platform engineering is becoming a must to reduce developer cognitive load, drive productivity and improve engineering standards. 

What the market seems to understand is that having an internal developer portal to serve as the developer interface to the platform is core. What everyone wants is an internal developer platform. Portals are how to get there.

Platform coverage is where you want to go

Portals are a living, breathing thing. They exist to provide developers with the ability to perform self-service tasks. What are those self-service tasks? Anything in the platform, from provisioning ephemeral environments to performing day-2 actions. There are a lot of things you can add to the portal-platform - many developer routines you can add.

In real life, no-one creates a portal that encompasses all of the platform (everything devops, really). Instead, most platform engineers start with a portal MVP (minimum viable portal) and then extend the portal, effectively creating a roadmap to cover all functions of the platform (what Gartner call “platform coverage”), all with a product mindset. So, if you want to understand how your portal is doing, check its “platform coverage” to get a good sense of the breadth of developer self-service made available in it.

The software catalog: more than meets the eye

This is probably one of the more exciting things in how Gartner understands the internal developer portal market. 

As data is brought into the internal developer portal it becomes a metadata store for anything software - this means that data about feature flags, appsec, CI/CD, anything really, all exists in the catalog and is up to date. The naive take on this is that developers can see the status of everything software (hopefully abstracted). The more interesting angle, which Gartner got just right, is that having the catalog as a central hub of knowledge can play a part in pipelines, namely CI pipelines. 

We’ve been telling this story for quite some time, calling it workflow automation. What is it exactly? Having machines use the API to collect data that only exists in the internal developer platform, such as CI/CD data. Gartner actually identifies this ability as “platform orchestration” and lists it as one of the core capabilities of an internal developer portal. I hope that this signals the formal addition of a fourth pillar to portals: not just catalog, self-service and scorecards, but also automations. By recognizing that software teams often lack a central technology and knowledge hub, the software catalog gets the place it deserves.

AppSec - a killer feature, not a filler feature

Gartner lists some use cases for portals, from reducing developer onboarding time to growing productivity and measuring DORA metrics. They also mention “The ability to identify service owners, track software component metadata, integrate with application security tools, and provide a consistent mechanism to apply security patches reduces the time to apply security mitigations”.

We can only agree! Many of our customers cite AppSec pains as one of the areas where internal developer portals can make a difference. AppSec is a core use case for internal developer portals and they seem to be one of the core developer routines platform-as-product managers want to address.

‍Backstage is where portal evaluation begins

While Gartner mentions backstage as a major driver of the market they also call it “Kubernetes of IDPs” — with similar benefits and cautions. What’s needed is to compare backstage vs alternatives, mostly commercial platforms. While the backstage approach has many strengths, it requires quite a lot of development effort - and that’s where Gartner recommends companies take a second look. SaaS can offer anything from no-code portal setup to RBAC, the ability to customize the UI and more.

Eventually, the market will evolve a set of well defined criteria of what’s inside an internal developer portal and what isn’t. We’d love to know how all this evolves. In the meantime, here’s our guide to internal developer portals.

{{cta-demo}}

Book a demo right now to check out Port's developer portal yourself

Book a demo
{{jenkins}}

It's a Trap - Jenkins as Self service UI

Read more
{{gitops}}

How do GitOps affect developer experience?

Read more
{{ebook}}

It's a Trap - Jenkins as Self service UI. Click her to download the eBook

Download eBook
{{cyberark}}

Learning from CyberArk - building an internal developer platform in-house

Read more
{{dropdown}}

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

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

Check live demo

No email required

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

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

Let’s start

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

(no email required)

Let’s start

Contact sales for a technical product walkthrough

Let’s start

Open a free Port account. No credit card required

Let’s start

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

Let’s start

Let us walk you through the platform and catalog the assets of your choice.

I’m ready, let’s start