Developer Self-Service: Beware of Missing the Point

Everybody is talking about platform engineering and the rise of internal developer portals. Yet it seems that most of the buzz in the industry is about microservice catalogs and KPIs that measure DORA metrics, production readiness, migrations and more.

But are software catalogs and software maturity KPIs the point of internal developer platforms? They are, but they are not alone. The point about internal developer platforms is that they are about accelerating delivery at scale by bringing all data and tools together, in one tab. That can’t happen just by looking at a software catalog and understanding dependencies. In this post I will argue that the point of internal developer portals is very different. It is about creating a unified portal that shows the software catalog, the KPIs associated with it AND enabling developers through self-service actions. This combined approach is what simplifies and accelerates their productivity and sets better standards.

‍

Internal developer portals need robust (and loosely coupled) developer self-service

Let’s look at the different parts of an internal developer portal:

‍

The purpose of an internal developer portal is to provide every engineer with a single, unified place to be autonomous while delivering software.

Through the internal developer portal, platform engineering teams design and release product-like experiences that let developers perform self-service actions. The logic is that this provides a great developer experience, reduces cognitive load and abstracts away complexity. It sets standards and codifies infrastructure security, cost governance and production-readiness policies.

Developers need to be able to get a good understanding of the SDLC process. In most organizations the associated information resides in dozens of different tools. In addition, Developers need to be able to deliver software that meets organizational standards in terms of operations, security and compliance. An internal developer portal also supports them in meeting various engineering initiatives, from cloud migration, moving from single to multi-tenant, from monolith to microservices etc.

‍

While this is covered by a descriptive Software catalog and service maturity KPIs that ensure that organizational standards are met it isn’t enough for developer autonomy. To be able to achieve “You build it you run it” you also need to enable developers to consume resources and perform actions against services, environments and resources. This part is covered by a Self-Service layer that allows developers to act on their own with a product-like experience, thus breaking the last brick of the silo once and for all.

In this blog we will talk about the Self-Service part of the portal and the different use cases this maps to.

‍

But what should be included in developer self-service?

The right approach is to create on-demand self-service on top of any automation created by the platform or devops teams. This is a proactive service model and it enables developers to achieve most of what they need in just one place, or even exposed through slack or other platforms to engage users wherever they are.

Here are some 1 click, self-service examples:

Scaffolding a new microservice
Cloud resource creation (either within certain bounds or initiating a manual approval process for exceptional requests)
Deploy or Revert a version of microservice
Temporary cloud permission requests
Fetching logs from production systems
Running health checklists
Running queries and actions against a production environment
Running queries and reports about cloud billing

‍

Here’s a list of developer self-service actions

‍

Some core rules for developer self-service

A one-click experience: build an interface your developers will understand and that puts them immediately on the golden path (but not in a golden cage, you can’t restrict them in 100% of cases…)

Keep the interface consistent and decoupled from the infrastructure. By decoupling the interface layer (which is the internal developer portal) from the backend layer (where the real automations and jobs exist), you ensure that developers experience a consistent UI while DevOps or platform teams still have the freedom to change the underlying technologies, tools and processes without facing a huge adoption challenge vis a vis developer habits

Reflect consumed resources in your software catalog and their correlated state in real time. Here’s an example: if a developer spins up an on-demand environment for 5 days, make sure to add an entity to your software catalog with all the details about the temporary environment, and once the environment is terminated, make sure it also stops existing in the software catalog to make it a stateful resource

Role-based access control is a must. Set proper authorizations with regards to who who can do which action. This drives compliance & security and also provides a sleek experience for the developer, who only sees what they need to see.

Set proper guardrails and controls - self-service doesn’t need to open all doors. Make sure you use manual approvals, TTL on consumed resources or limitations on number of actions a team or individual can make within a given period.

Audit log everything - or compliance will be a mess.

‍

Is self-service worth it? The ROI of self-service

Developer self-service is worth it. It saves devops resources - instead of answering tickets they can focus on what matters. From the developer point of view, self-service drives productivity since developers save time and are more autonomous, hopefully improving satisfaction and autonomy. Compliance and cost controls immediately become better too.

‍

‍

How Port enables developer self-service

With Port you can easily build a User Interface for your developers (on top of our software catalog). Every self-service action that is done through Port is automatically updated in the software catalog. Using the UI sets the right guardrails and control measures to make sure you allow developers to roam freely without worrying about it. Any action made is Port is kept in a detailed audit log to make sure compliance and security practices are met. Start your free trial now.

Home

Blog

Developer Self-Service: Beware of Missing the Point

This is some text inside of a div block.

Developer Portal

DevOps

Developer Experience

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

It's a Trap - Jenkins as Self service UI

Developer Experience

GitOps

DevOps

Internal Developer Platform

How do GitOps affect developer experience?

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

Developer Portal

Developer Velocity

Developer Experience

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

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": "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
   }
 }
}

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

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

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

Internal developer portals need robust (and loosely coupled) developer self-service

But what should be included in developer self-service?

Here’s a list of developer self-service actions

Some core rules for developer self-service

Is self-service worth it? The ROI of self-service

How Port enables developer self-service

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

It's a Trap - Jenkins as Self service UI

How do GitOps affect developer experience?

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

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

Example JSON block

Order Domain

Cart System

Products System

Cart Resource

Cart API

Core Kafka Library

Core Payment Library

Cart Service JSON

Products Service JSON

Component Blueprint

Resource Blueprint

API Blueprint

Domain Blueprint

System Blueprint

Microservices SDLC

Development environments

Cloud resources

SRE actions

Data Engineering

Backoffice

Machine learning actions

Engineering tools

Infrastructure

Software and more

Our blog

How to Drive a Culture of Kubernetes Standards With Platform Engineering

A Package Catalog in Your Internal Developer Portal

Announcing the GitHub and Bitbucket Exporters

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