Internal developer portal

Internal Developer Platform vs Internal Developer Portal: main differences

June 27, 2024

Netta Borowitsh
Netta Borowitsh
Internal Developer Platform vs Internal Developer Portal: main differences
Example H2

Ready to start?

As companies grow, their tech stacks become more complex, and they realize growing developer responsibilities can sometimes breed chaos, the need for platform engineering becomes crucial.

Platform engineering necessitates the creation of an internal developer platform, but this can create a lot of terminology confusion: the term “IDP” is used interchangeably for both internal developer platforms and internal developer portals. So what are they and what are the differences between them? In this blog, we’ll explore each solution, their features and benefits, and how they differ from one another.

What are internal developer platforms?

An internal developer platform is the sum of the tools and services that offer reusable self-service actions that streamline the software development lifecycle (SDLC). It’s built by platform engineering teams to provide developers with a consistent, self-service environment that abstracts the complexities of underlying infrastructure and processes. The primary goal of an IDP is to reduce cognitive load on developers, allowing them to focus on coding and innovation rather than the intricacies of deployment and operations.

You can build platforms in all shapes and sizes, but most commonly they include:

  • Source Control Management (SCM): Tools like GitHub, GitLab, or Bitbucket provide version control, enabling developers to track changes, collaborate, and manage code repositories efficiently.
  • Continuous Integration/Continuous Deployment (CI/CD): Automation tools such as Jenkins, CircleCI, or GitHub Actions facilitate the integration and deployment of code. They ensure that changes are automatically tested and deployed, reducing manual intervention and errors.
  • Infrastructure as Code (IaC): Tools like Terraform, Ansible, and Pulumi allow the provisioning and management of infrastructure through code, ensuring consistent and repeatable environments across development, testing, and production.
  • Containerization and orchestration: Docker and Kubernetes are essential for packaging applications and managing containerized workloads, providing scalability, and ensuring consistent environments.
  • Observability and monitoring: Tools like Prometheus, Grafana, and Datadog offer insights into application performance, enabling teams to monitor metrics, logs, and traces to ensure reliability and quickly address issues.

Internal developer portal: This acts as the developer and manager interface to the platform, and for business process orchestrations using the automations feature in the portal.

Using an internal developer platform offers developer teams several benefits, including:

  • Compliance with Standards: An IDP ensures that software and infrastructure comply with standards for production readiness, cost management, and AppSec.
  • Increased productivity: By automating repetitive tasks and providing a self-service environment, developers can focus on writing code and delivering features faster, leading to shorter development cycles and quicker time-to-market.
  • Standardization: A platform promotes consistency across teams by enforcing standardized practices for code integration, deployment, and infrastructure management. This reduces the risk of errors and ensures high-quality software delivery.
  • Reduced cognitive load: Abstracting the complexities of the infrastructure and providing easy-to-use tools allows developers to concentrate on their core responsibilities. This reduces the learning curve for new team members and minimizes context switching.

Enhanced collaboration: By providing a centralized platform with integrated tools and shared practices, an IDP fosters better collaboration between development, operations, and other stakeholders, leading to improved communication and efficiency.

What are internal developer portals? 

An internal developer portal serves as the front-end interface for an organization's internal developer platform. It provides a centralized hub where developers can access the tools, resources, and documentation they need to build, deploy, and manage applications efficiently. It offers managers insights about engineering metrics, productivity, and standards compliance and supports the needs of different subject matter experts such as SREs, DevSecOps, and FinOps.

The primary purpose of an internal developer portal is to simplify the developer experience, enhance self-service capabilities, and improve overall productivity by offering a unified and user-friendly interface to interact with the development ecosystem.

The key components of an internal developer portal include:

  • Service catalog: The core of an internal developer portal is its comprehensive service catalog, which lists all available services, APIs, microservices, and tools within the organization. This catalog helps developers discover, understand, and utilize existing resources effectively.
  • Self-service actions: Internal developer portals provide self-service capabilities, allowing developers to perform routine tasks independently. These actions can include provisioning environments, deploying applications, requesting permissions, and more, all through a simplified, intuitive interface.
  • Automations: The portal often includes tools for business process orchestration using automations, such as triggering alerts and nudges, terminating temporary environments and permissions, and more. Automation ensures consistency and reduces manual intervention, streamlining the development process.‍
  • Analytics: Since the portal is a single source of truth for anything software in the organization, it can also be used for software engineering intelligence purposes.

Like platforms, portals are crucial for dev teams, offering advantages like:

  • Enhanced developer productivity: By centralizing access to tools and resources, an internal developer portal reduces the time developers spend searching for information. This allows them to focus more on coding and delivering features.
  • Improved self-service capabilities: Developers can independently perform tasks like provisioning environments, deploying applications, and accessing documentation. This reduces dependency on other teams and accelerates the development lifecycle.
  • Standardization and consistency: The portal enforces best practices and standardized workflows across the organization. This ensures that all teams follow the same procedures, leading to higher quality and more reliable software delivery.
  • Better collaboration and communication: The portal provides a single point of access for all development-related activities, fostering better collaboration among team members. Integrated communication tools ensure that developers can easily share knowledge and resolve issues together.

Managerial insight: Reporting and dashboards within the portal offer valuable insights for managers.

Platform vs. portal: comparing internal developer platforms and internal developer portals

With their similar names and purposes, it’s easy to get confused between internal developer platforms and internal developer portals. While both aim to improve the developer experience, they ultimately serve different yet complementary purposes that enhance the developer experience and streamline the development process.

An internal developer platform is the backbone of an organization's software development infrastructure. It provides a comprehensive suite of tools and services that allow developers to build, test, and deploy applications efficiently. The platform abstracts the complexities of the underlying systems, enabling developers to focus on writing code and delivering features without worrying about the intricacies of infrastructure management.

On the other hand, a portal acts as the user interface for the platform. It centralizes access to all the tools, resources, and documentation needed by developers, offering a unified and user-friendly interface. The portal enhances the developer experience by making it easier to find and use the tools provided by the platform facilitating self-service capabilities, and improving overall productivity.

Here’s a comparative overview of key aspects, elements, and features of both tools:

| | Internal Developer Platform | Internal Developer Portal | |--------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------| | Purpose | Provides comprehensive tools and services for building, testing, and deploying applications | Centralizes access to resources, tools, and documentation; enhances user experience | | Core Functionality | Infrastructure management, automation, CI/CD pipelines, container orchestration, incident management tools, feature flag tools, FinOps tools, AppSec tools, and more | Service catalog, self-service actions, workflow automation, documentation | | Focus | Creating reusable self-service actions | Simplifying access and usability for developers and reducing cognitive load by abstracting infrastructure complexities | | User Interaction | Users can interface directly with the tools that constitute the platform, but that can actually add cognitive load and complexity | Direct interaction through a unified and abstracted interface | | Key Tools | Source control, CI/CD tools, infrastructure as code, containerization, observability | Service catalog, self-service interfaces, knowledge base, monitoring dashboards | | Automation | Automates integration, deployment, and infrastructure provisioning | Automations for business process orchestration and alerting | | Standardization | Enforces best practices and standardized workflows across teams | Reinforces standards by providing consistent access and user experience, using golden path and guardrails | | Benefits | Enhances productivity, ensures consistent and high-quality software delivery | Improves self-service capabilities, fosters better collaboration |

In short, while the internal developer platform serves as the robust backend infrastructure necessary for software development, the internal developer portal enhances the developer experience by providing an accessible and intuitive interface to interact with these tools. 

Together, they form an essential structure that optimizes productivity, standardizes processes, and simplifies the complexities of software development. Investing in both ensures that organizations can build, deploy, and manage applications more efficiently and effectively.

Choosing the right solutions

Selecting the appropriate internal developer platform and portal for your organization requires careful consideration of your specific needs and goals. Both components are vital for optimizing the software development lifecycle, but their implementation depends on various factors.

  • Evaluating your needs: First, assess your organization’s current challenges and objectives. Are you facing issues with infrastructure management? Is the developer experience and self-service capability a concern? 
  • Internal developer platform tools: Choose the best-of-breed platform tools that match your engineering DNA. 
  • Internal developer portal: The portal should offer a user-friendly interface that centralizes access to all necessary resources, tools, and documentation. Key features to look for include a comprehensive service catalog, the ability to support any data model, automations, and customizability since the portal and platform continuously evolve. The portal should make it easy for developers to discover services, access documentation, and perform tasks independently.
  • Integration: Ideally, an organization benefits most from a combination of both a platform and a portal. Using both ensures that while the technical complexities are managed efficiently, developers have a streamlined and productive experience.

Conclusion

Choosing the right platform and portal is essential for optimizing your software development lifecycle. By evaluating your organization's specific needs and integrating both solutions, you can optimize workflows and enhance the developer experience, ensuring higher productivity, better collaboration, and consistent software quality.

Previous article

Next article

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

You may also be interested in

Building the perfect internal developer platform

Building the perfect internal developer platform

Read more
How to use JQ commands to speed developer workflows

How to use JQ commands to speed developer workflows

Read more
Debugging K8s with K8sGPT in your internal developer portal

Debugging K8s with K8sGPT in your internal developer portal

Read more

Starting with Port is simple, fast and free.

Let’s start