Developer Self Service

Developer self-service: beware of missing the point

January 2, 2023

Zohar Einy
Zohar Einy
Developer self-service: beware of missing the point
Example H2

Ready to start?

Introduction

‍

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.

‍

{{cta_1}}

‍

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

{{tabel-1}}

‍

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.

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