Internal Developer Portals Can Do More than You Think
Platform engineering is the new thing. Like all new things, there are different takes on what it really means and does, and more importantly, what it’s used for. The same goes for internal developer portals, which are the main developer-facing tools used by platform engineering folks.
Even in the plain-vanilla version of internal developer portals, there are several flavors, and the use cases go further and deeper than what’s evident at a first look. We’ll explain the core use case for internal developer portals, and then talk about some surprising and compelling use cases that most platform engineering folks miss. These use cases also point to what internal developer platforms can become.
Why is it important to explore all use cases now rather than wait for the future? Because setting up an internal developer portal takes time, not necessarily time to set up (that’s actually easier than you assume), but the time to drive engineering culture changes.
Even if uploading data and reflecting it in the software catalog can happen quickly, there is an adoption effort associated with getting developers to abandon TicketOps or excessive permissions and begin using the internal developer portal for self-service actions or software catalog visibility.
Internal developer portals are also about a culture of measurement (through scorecards), quality and standards, and this change also takes time and effort. So you better make sure you’re covered for what is needed now and what will be needed in the future.
Plain-Vanilla Internal Developer Portals
Just like soft-serve ice cream, where chocolate is intertwined with vanilla, internal developer portals have two main intertwined parts: the software catalog and the developer self-service. It’s not about an accidental bundling of a visibility layer (the catalog) and a self-service UI that is loosely coupled with existing DevOps automations. Both elements work together, since self-service actions are immediately reflected in the software catalog, through APIs and plugins.
The main point about plain-vanilla portals is that they provide a deep in-context understanding for developers, as well as the broadest developer self-service actions there are. This isn’t just about microservice scaffolding.
It includes Day 2 operations, permissions with a time to live (TTL), provisioning cloud resources and more. Without it, adoption won’t be enough to improve the developer experience or reduce the TicketOps drudgery for both developers and DevOps. In this respect, scorecards are also a big part of the puzzle (maybe they’re the ice-cream cone?) because they present valuable information in context — the specific health or readiness metrics for a given entity, such as a service deployed in a certain environment.
The breadth of developer self-service actions should already provide hints about some of the additional use cases. You still probably won’t guess the last one on the list.
Use Case No. 1: A Portal for DevOps
DevOps are humans too. They need some respite from the clutter and complexity of microservices. The days of tracking everything in a huge csv file are over. A developer portal gives DevOps the ability to track the state of distributed applications from the point of view of microservices, infrastructure, cloud resources, DevOps and dependencies. It’s impossible to do this any other way; there are too many deploys per day, even in systems with only tens of microservices.
So while the internal developer portal has “developer” in it, it can be used by DevOps. Actually, we’ve seen several companies where it is solely used by DevOps.
Use Case No. 2: Provisioning Ephemeral Environments
Have you ever heard the story about the orphaned developer environment that lives forever in the dark, bleeding dollars, lurking somewhere hidden?
Up until the use of internal developer portals, the best practice to address this issue was a dedicated database with the timestamp for temporary resources and to follow up on that with a cleanup script. Even worse, sometimes this information was tracked in a csv file.
Needless to say, this method is error-prone. An internal developer portal has built in TTL that can be used in determining self-service actions (for instance, allowing three days and requiring manual approval for five days). When time is up, the resource goes down — and it’s all immediately reflected in the software catalog.
Use Case No. 3: Temporary Permissions
The case of permissions is very much like the case for developer environments. Someone needs a temporary permission to a cloud resource, but that permission is forgotten, never revoked, thus creating a security risk. Using a developer portal both to request the permission, with a TTL, and then revoke it is the way to go.
Use Case No. 4: Managing Packages
Packages and microservices share some similarities — they are both modular and made to be reused by many software elements. When we say that microservice management is difficult, we should probably remember that the same applies to package management. Packages are a hotbed for security vulnerabilities, and it’s often almost impossible to track them when a security issue occurs (log4j, for instance). Packages present the same missing information challenges, from ownership to version visibility.
In a developer portal, these problems go away. You can track package versions and dependencies, and easily enforce package quality standards as well as track any issues.
It’s important to note that should security vulnerabilities occur in packages, it is almost impossible to track that with ordinary security tools. In the usual case, security analysts will look for vulnerable packages and try to determine which microservices and infrastructure they are on. This requires mapping packages in a container or analyzing memory, which isn’t easy to do on Kubernetes and is very intrusive.
Use Case No. 5: Automated CI/CD Decisions Based on the Catalog
This is the most interesting use case: a developer portal that isn’t used by human developers but rather by machines. Why should this happen, you may ask. The reason is hidden throughout the previous sections of this blog: The software catalog is the best place to track all things software and resources.
This will become a core use case for internal developer portals, where machines will query service maturity, readiness, locking and more before they execute workflows. This is because developer portals create a single source of truth about the state of software in the organization.
Cron jobs, CI/CD jobs and cleanup scripts will access the internal developer portal to get the context they need for terminating resources or running CI or CD jobs. This beats doing this through glue-code or ad-hoc databases.
What Now?
Internal developer portals are set to cover many more use cases, so make sure you choose the right one that’s flexible and API-first, and able to collect all the data needed. Try Port.
