Internal Developer Portal

2024 Platform engineering predictions

January 16, 2024

Jenny Salem
Jenny Salem
2024 Platform engineering predictions
Example H2

Ready to start?

2023 was all about platform engineering. This movement largely happened thanks to a growing need to make the developer experience smoother and drive more performant software. It was also the year of Internal Developer Portals, which were the most piloted tool in 2023, according to Gartner. 

In this article, we'll explore our predictions for 2024 in platform engineering. 

All Eyes Remain on Developer Experience:

Speaking from our own experience at Port, 2023 saw a lot of companies establish developer experience teams, for the first time in their history. This intense focus on optimizing the Developer Experience (DevEx) is tied to the goal of improving developer and devops productivity.

For years, there has been a lot of focus on measuring developer productivity and this has only grown with shrinking teams and increased tool complexity. However, the emphasis has always been on defining measurements and benchmarking against others. But developers distrust productivity metrics, and the complexity of using different frameworks - of which the number keeps on growing - is high. There is also uncertainty on how tangible these metrics are, and conflicting views on which metrics or frameworks are best to use. 

Our own State of Internal Developer Portals report found that in actual fact, surveys and custom reports trump developer productivity measurement frameworks such as SPACE or DORA. And this gets to the heart of the matter - developer productivity is intrinsically linked to how much an organization is communicating and enabling their developers. 

For years, what has been overlooked is how engineering leaders can help developers become more productive. This is where DevEx comes in; by putting a greater focus on streamlining developer workflow and engaging in feedback with developers on what they need to be productive, developer productivity is likely to increase. Abstracting away complexity from platforms is key to this, and engineering teams will be looking towards developer portals to help. We expect the establishment of more DevEx teams and the integration of Developer Experience as a vital performance metric, closely monitored through surveys and reports.

Developer Portals Should be Managed Using a Product-Centric lens:

One of the most interesting approaches emerging out of 2023 was ‘Platform as a Product’. This is an approach whereby platform engineers adhere to a product management methodology when implementing an internal developer platform. This puts forward the idea that a platform is a fully-fledged product that serves internal customers and requires a thoughtful and user-centric approach in its ongoing development. The trend is driven by the understanding that each organization has its own specific processes and operational nuances.

In 2024, we believe that the same principles will be applied to the implementation of internal developer portals. Platform engineers would start by identifying the real needs of developers and understanding what should be abstracted for them, taking a portal-as-product approach.  It is then recommended to adopt a 'Jobs-To-Be-Done' framework to gather user stories, to plan roadmaps and sprints, evaluate success metrics, and continuously refine the portal, just like a consumer-oriented software offering. 

Evolution of Use Cases in Internal Developer Portals:

‍As the adoption of Internal Developer Portals  grows in 2024, we're expecting to see an expansion in the use cases covered by the portals. Currently, portals are predominantly utilized as service catalogs, as mentioned by Viktor Farcic in his “best devops tools for 2024”. However, with increasing usage, portals will deliver on the developer self-service promise, including day-2 operations, and adding third party tool data and self-service actions. Other potential use cases include managing costs, handling feature flags, understanding internal APIs, and more. These examples illustrate just the beginning of what’s possible. As adoption widens, the scope of portals will evolve, serving a broader and more complex set of developer needs and organizational requirements.

Expanding Portal Usage Across Roles and Personas:

‍As the range of use cases for Internal Developer Portals grows, a more diverse set of users will emerge, going beyond developers. Technical support staff, SREs, FinOps and CISOs are all expected to become regular developer portal users. To serve them well, the portal owner, using a product-centric approach, will need to think about how it is personalized per use case. This includes creating custom dashboards and experiences for different teams, as well as paying attention to RBAC to accommodate the unique needs and access requirements of each role.

From Spreadsheets to Automated Processes

‍Our "State of Internal Developer Portals" survey uncovered that 35% of respondents that believe they are using a developer portal still rely on spreadsheets for managing microservices data. However, as Internal Developer Portals become more standardized in the industry, we anticipate a significant shift. Platform engineers are expected to move away from manual spreadsheet-based reporting and tracking, transitioning to fully automated software catalogs and adding developer self-service actions as the main driver of an improved developer experience. 

Innersource Will Gain Momentum in Software Development:

The shift towards innersource - a methodology that brings an open-source approach to software development- is rapidly gaining momentum. According to Gartner, it's expected that 40% of software engineering organizations will have innersource programs by 2026, but we'll already start witnessing this growth in 2024. Internal Developer Portals will become a catalyst in adopting innersource. They serve as centralized catalogs, offering visibility into developed components and encouraging developers to utilize existing code. Additionally, Internal Developer portals facilitate the initiation of new innersource projects and ensure adherence to best practices in code development. This evolution towards innersource, with the support of portals, is a significant step towards more collaborative and efficient software development.

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