Portal vs. Platform: Why You Need to Think about Both
Like it or not, you already have an internal developer platform, even if your organization never set one up and doesn’t have people with “platform engineering” in their title. It might not be the right platform, it may be difficult to scale or use, but it exists.
This means you probably don’t need to build a platform; you just need to make it better. The real question you’re facing is whether you should use an internal developer portal on top of your platform, given it is the most mature element in the platform engineering stack.
What we’ll argue in this post is that portals matter and that they also have an impact on the quality and usefulness of your platform efforts, essentially becoming part of the platform as they and the technology evolve.
But wait! Internal developer platform? Internal developer portal? What’s the difference and why should one be used “on top” of the other? Let’s first define both and make some bold arguments as to where this will take us.
What Is an Internal Developer Platform?
Let’s begin with the basics. A platform is what helps engineers get their job done. It lets them code, stay in the zone and not worry too much about operation issues that they can’t control or have no expertise with.
Since modern architectures are complex and made of many underlying technologies with hundreds of microservices, the software development life cycle is becoming too much for any human mind, and requires too much expertise in both operations and development.
The solution is abstracting away some of the complexities and creating a uniform developer experience that will reduce cognitive load for both developers and operations people. These better developer experiences should grow productivity. This is what the platform is about.
A definition of sorts, inspired by Gartner, is that platforms are about self-service capabilities and reusable tools with automated infrastructure operations. Built by platform engineers, the platform frees developers from “glue work” and sets standards and golden paths for developers.
All this can be summed up to developer self-service. Instead of building your own temporary cloud environment or performing a Day 2 operation, or asking someone in DevOps to do so, you access an interface and get what you need. Imagine a Jenkins self-service form or Terraform no code.
Abstracting everything away for the sake of better productivity sounds nice on paper, but some data, like dependencies, memory or CPU usage, needs to be shown.
This isn’t perfect, of course. No one said that the platform you already built and need to evolve is perfect. It probably isn’t. For instance, using Jenkins for self-service means lack of context and state, a flat UI and an inability to set organizational standards (engineering quality can and should be the outcome of good portal/platform work). It also isn’t de-coupled. You change Jenkins, you need to change the developer experience too. That won’t work well.
Another part of the platform is about providing developers with some level of transparency about the underlying infrastructure so they can make informed decisions. Abstracting everything away for the sake of better productivity sounds nice on paper, but some data needs to be shown, from dependencies to Kubernetes setup, memory or CPU usage and more.
You can’t do “you build it, you own it” without at least some of that data. A good example is GitOps (which may form the core of your existing platform). Pure GitOps doesn’t work well for developers, since it contains too much information, and allows too much space for developers to roam free and make mistakes. In that case, replacing GitOps with a platform or putting some platform elements on top of it may do the trick.
What Is the Internal Developer Portal?
The portal is the platform’s interface, and as such helps users access the underlying heterogeneous software development life-cycle resources as well as consume the self-service actions offered in the portals. Portals create similar experiences for both developers and operations people, so everyone can self-serve and get the right level of visibility into the infrastructure so that they can make the right decisions. These experiences are product-like and are meant to both offer simple, golden-path self-service, as well as enforce quality standards and make engineering quality better. Otherwise, productivity can’t happen.
Self-Service
Developers consume self-service actions in the developer portal. The more actions, the better. First, developers don’t just need to scaffold microservices; there are many Day 2 operations they need, as well as permission requests (with TTL, or time to live), setting up ephemeral environments and more. A good self-service experience should be as product-like as possible and help developers work easily, within golden paths and with as few errors as possible. In doing that, developers are informed by the software catalog, but the self-service actions themselves need to be reflected in the catalog immediately.
Let’s deal with the elephant in the room. Is the internal developer portal “just a UI” for developer self-service? It isn’t.
Let’s deal with the elephant in the room. Is the internal developer portal “just a UI” for developer self-service? It isn’t. To understand why, let’s examine the software catalog, and then we’ll explain how it can evolve into a platform API.
The Software Catalog at the Center of It All
The software catalog is usually described as a catalog that contains microservices, cloud resources and infrastructure, showing all elements in context. It shows and can help manage permissions, ephemeral environments and almost anything else. It contains all the metadata you can drive into it. It will be abstracted away for developers, showing them only what they need.
However, even though you may be abstracting what’s in it, the software catalog still acts as a general-purpose metadata store. As such, you can run any query against it and get the answers you need, even for problems that are considered complex, like package vulnerability initiatives. This is where operations people start getting excited about the software catalog.
The software catalog needs to be neutral enough at the outset so you can build it to fit whatever data model you have.
The software catalog needs to be neutral enough at the outset so you can build it to fit whatever data model you have, creating an opinionated software catalog that fits whatever your organization is building.
A central catalog isn’t just about all the data in it or how it’s useful for both developers and operations. Using scorecards, the catalog also reflects quality, health and other metrics in the context of specific entities, such as a specific service running on a given environment. This helps prioritize actions and drive quality in environments with many microservices, repos and regions. It also helps change organizational behavior by determining quality in one central place.
The Software Catalog Is Made for Machines and Operations Too
If you’re reading this closely, you may have already noticed that as a general-purpose metadata store, we’re talking about a software catalog that goes beyond the developer experience. In other words, despite the name, the catalog in the internal developer portal is made for machines too, and for the operations people who manage them.
In fact, many operations people we speak to want to begin to use the portal themselves, to manage software and system sprawl. They are the ones complaining about messy microservice tracking and too many DevOps tools, about complex AppSec issues that need a central place of control. Then it dawns on them: They want to run workflows against the software catalog.
This is workflow automation, where a workflow checks the state of everything in the software catalog. We hear this all the time, and it goes like this: “If the software catalog has all information about service locking/packages/versions/etc., can I have the CI workflow check the software catalog as part of the workflow?”
If a service is locked, workflow automation will check it in the catalog and won’t let it deploy. If service health is off, another action will be taken. In this respect, the scorecards mentioned earlier are valuable, since automations can and do check scorecard information as part of their processes.
The Core Principles of the Portal
Let’s go through the core ideas behind the internal developer portal:
- Bring-your-own-data model. The software catalog should support common data models (such as the backstage C4 model), as well as unique ones. It should be neutral enough so that you can build an opinionated data model in it. In Port, this is done through what we call “blueprints.”
- The software catalog should contain all the data that is required, acting as a general-purpose metadata store for software and resources. Data may be abstracted away for developers, but the data will remain in the catalog for other users, such as operations teams or workflow automations.
- Product-like experience. The UI should provide developers with a golden-path experience. Product thinking is at the core of internal developer portals, and the UI should be configurable and support no-code creation to support this.
- Loosely coupled from underlying infrastructure and automation. Platforms evolve all the time, regardless of whether they were haphazardly built over time or are a result of a new technology stack. As a result, the internal developer platform (IDP) should be loosely coupled with them. If the underlying cloud resources, CI or CD systems are replaced, the developers should have the same experience.
- Allow developer self-service in the broadest way. To ensure adoption, developers need to have all their needs satisfied in the IDP. Focus on just one self-service action, and your platform progress as well as the IDP won’t grow.
- API first (for real)
- Compliant and secure by design
The Future Is the Platform API
The future of the developer portal is to become a platform API, providing a unified interface for interacting with the platform. The developer portal will also host the software catalog, giving context to the platform state, and be responsible for triggering platform automations as part of its self-service actions. The platform API will be used by both the developer portal as a frontend interface and by the platform’s internal components to make automated decisions based on the contextual information stored in the API.
To Do Platform Engineering, You Need to Begin with the Portal
Regardless of whether you agree that you already have a platform, an internal developer portal is probably the most mature and well-defined element you can begin using to join the platform engineering movement. Internal developer portals are valuable enough to drive important improvements to developer productivity and bring order to operations people. You can try Port’s no-code internal developer portal for free here, or check what it can look like here.
