Developer Self-Service: Beware of Missing the Point

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.