 |
VOOZH | about |
|
VOOZH | about |
We’re so glad you’re here. You can expect all the best TNS content to arrive Monday through Friday to keep you on top of the news and at the top of your game.
Check your inbox for a confirmation email where you can adjust your preferences and even join additional groups.
Follow TNS on your favorite social media networks.
Become a TNS follower on LinkedIn.
Check out the latest featured and trending stories while you wait for your first TNS newsletter.
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.
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.
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.
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 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.
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.
Let’s go through the core ideas behind the internal developer portal:
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.
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.
