Blog
/
/
Top 5 internal developer platform tools
Internal developer portal

Top 5 internal developer platform tools

Netta Borowitsh
Netta Borowitsh
Jul 15, 2024
Sign up
Download PDF
Internal developer portal
Example H2
Example H3

What is an internal developer platform?

An internal developer platform (IDP) is made to offer developer self-service to drive developer autonomy and promote better DevOps practices. Its goal is to drive developer productivity by creating a simple product-like experience that abstracts away many of the complexities and tooling of the underlying platform infrastructure, reducing cognitive load. Through golden-paths and better engineering operations, the IDP also ensures that software complies with standards. A one sentence definition of an internal developer platform is that it enables developer self-service by offering golden paths. 

Since the SDLC spans many tools, systems and practices, the goal of the internal developer platform is to provide developers with an “opinionated and supported path to build and run systems” (credit: Chad Metcalf)  across all these tools, which in effect, comprise the platform. This helps developers gain autonomy despite the fact that many tools and processes are involved.

Typically, internal developer platforms are built and operated by DevOps, developer experience of platform engineering teams. In this article, we’ll refer to the platform engineering team. The users of internal developer platforms are developers and engineering managers, as well as subject matter experts, such as AppSec, FinOps or site reliability engineers. They are the “customers” of the platform engineering team.

The maturity of internal developer platforms can be assessed according to the CNCF’s platform engineering maturity model, which ranks internal developer platforms from a provisional state which is ad-hoc and requires little investment to “optimizing platforms” where there is widespread adoption and dedicated investment.

How platform engineers build the internal developer platform

To determine which golden paths and self-service actions developers should be able to accomplish using the internal developer platform, it is recommended that platform engineers take a platform-as-product approach, determining the features that the platform needs to provide developers and managers, much like a product manager would do for a product serving external developers. 

The best approach is iterative, meaning that instead of defining all the developer self-service experiences at once, platform engineering teams begin with a platform minimal viable feature set, to serve the more common developer needs, and then further evolve the platform offering over time.

The platform encompasses many tools and systems, such as:

  • CI/CD
  • IaC
  • Cloud resources
  • Control planes
  • Kubernetes 
  • Secrets management
  • Observability and more

Many internal developer platforms also make use of data coming from AppSec, cloud security, FinOps, feature flag and incident management tools. This data allows developers to ensure standards are met and ensures better outcomes and more self-service options, going from standing up environments to executing runbooks when a developer is on-call.

While many argue that an internal developer platform requires a tool category called platform orchestration we believe that platforms are the tools and the APIs that connect them and that platform orchestration actually occurs in the internal developer portal. 

But what do platform engineers actually do:

  • They build what’s needed for the platform, from CI/CD to the self-service actions that will be triggered by developers
  • They choose an internal developer portal which is the interface for developers and then maintain it

What developers can do with an internal developer platform

Since the goal of the internal developer platform is to create developer self-service and that the platform needs to support all developer workflows throughout the software development lifecycle (SDLC), developers and managers use the IDP for a variety of use cases. Here are some of the more common ones:

Top 10 use cases for internal developer platforms 

  1. Self-service environment management: letting developers spin-up ephemeral environments, or provision infrastructure and environments for application development, testing and QA. Platform engineers will ensure that such self-service is done in accordance with policies and standards, and the internal developer platform will also provide developers with a simple and abstracted product-like interface to do so.
  2. K8s visualization and standards: most internal developer platforms use Kubernetes, but it needs to be abstracted for developers. This applies to either allowing developers to easily change replica counts, redeploy image tags, or rollback running services, or ensure they meet K8s standards and policies. 
  3. Shipping features to production: platforms support developer self-service for all SDLC activities, from scaffolding new microservices to testing them and promoting them to production.
  4. Service catalog: using a service catalog or a microservices catalog, such as the one provided by Port or Backstage is a core use case for internal developer platforms. Microservices architectures are inherently complex and understanding dependencies or even just preventing unnecessary duplication of effort is a challenge. By having a service catalog as part of the platform developers can easily understand the system, especially when they are on-call.
  5. Developer onboarding: developer self-service and abstractions not only help developers become more productive but it can also make developer on-boarding much quicker. Providing developers with information, a service catalog, documentation and self-service can get them to productivity much faster.
  6. Incident management: the use of service catalogs and the integration with other platform tools can help on-call developers quickly resolve incidents.
  7. Standards compliance: since all software entities are contained within the platform, standards can be set, managed and monitored, leading to better quality of software and compliance with standards such as AppSec, production readiness and more.
  8. IaC for developers: through an internal developer platform, IaC infrastructure can be leveraged to allow developer self-service.
  9. Cost management: since platforms consolidate all information, including cost costs, cloud costs can be easily monitored and controlled both throughout the scaffolding phase as well as post deployment, using policies and setting alerts, providing developers with the information they need to control costs.
  10. Just in time permissions: developers can use the platform to request just in time permissions to cloud resources.

The benefits of internal developer platforms

Better standards compliance, resulting in lower MTTR, better availability and less time wasted by developers and managers alike. This also reduces security risks and cost overruns. The most important part is the ability to drive modern, high quality software engineering.

Better developer experience, enabled through developer autonomy and clear and simple golden paths. This drives productivity since less time is spent trying to figure out self-service or waiting for tickets to be served, and leads to developer satisfaction and retention.

Software engineering intelligence, since platforms consolidate all this information, allow its measurement and then changes to the platform can serve to improve those metrics.

Top 5 internal developer platforms for 2024

1. Port - an open internal developer portal

To provide a product-like experience to developers, internal developer platforms need interfaces. This is the internal developer portal, although it does much more. It supports scaffolding as well as a broad range of day-2 actions for developers and a full service catalog. 

Gartner reports that internal developer portals are the most piloted tool in 2023, and that they are the most mature tool in the platform engineering stack.

Internal developer portals are where platform engineers make the internal developer platform accessible to developers. Portals are the interface where self-service actions are triggered, through the various APIs that make up the platform. They are also where the service catalog (or software catalog) is offered to developers, providing them with the insight they need for standards compliance, understanding the stack or dependencies and more. 

Without a portal you risk creating an internal developer platform with either too many self-service interfaces, or no abstractions, risking the creation of a poor developer experience.

Port is well-known for its flexible and non-opinionated internal developer portal platform, supporting both developer self-service, standards compliance and strong automations. In Port, the setup of an ephemeral environment and the ability to provide it a TTL and then terminate when needed is easily accomplished. 

2. Backstage - an open source service catalog

Spotify Backstage started the platform engineering revolution almost single-handedly by offering an open source framework for internal developer portals. In 2020, Spotify contributed backstage to the CNCF. While there are disadvantages to using backstage, including a limited ability to offer day-2 operations, issues with backstage plugins and the need to hire developers, it has certainly triggered the entire idea behind internal developer platforms.

3. Syntasso - Kratix

This tool goes under the category of platform orchestrator or, as Gartner calls this category, “self-service environment management”. Kratix calls itself an open-source framework for building composable internal developer platforms. The idea behind Syntasso (the developer of Kratix) is that cost compliance and security need to be governed and policies need to be set when environments are set up, ensuring compliance, production readiness and uniformity.

4. Qovery

Qovery calls itself an “internal developer platform” although it is more of a platform orchestrator or self-service environment management platform. It is focused on “cutting noise” for developers by setting paved paths, allowing developer self-service on top of Kubernetes for ephemeral environments, testing and more. It also supports audit and RBAC, to ensure compliance. 

5. Appvia

Just like Qovery and Syntasso above, Appvia focuses on giving developers the ability to self-service with regards to environments, workloads and service dependencies, creating a uniform and reliable way to deliver applications. Appvia supports the integration of Terraform modules and to enforce security scans to ensure that all the infrastructure built with Appvia complies with best practices.

{{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-baner}}

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

{{port-for-backstage}}

Apply to join the Beta for Port's new Backstage plugin

Apply for beta
{{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
{{cta-demo}}
{{reading-box-backstage-vs-port}}

Further reading:

Read: What are the technical disadvantages of Backstage?

Compare: 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

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

I’m ready, let’s start