At the beginning of your platform journey, there are many tools to understand and discover. Some may appear similar in functionality, making it hard to choose which is right for your platform. This article provides a brief overview of the difference between two such tools: Port’s developer portal and the Humanitec Platform Orchestrator.
First, let’s clarify the categories.
According to Gartner, “Internal developer portals serve as the interface through which developers can discover and access internal developer platform capabilities.”
A Platform Orchestrator, on the other hand, sits at the center of an Internal Developer Platform and enables Dynamic Configuration Management across the entire software delivery cycle.
In this article, I’ll cover the Humanitec Platform Orchestrator and developer portal primary features, the categories they belong to, where they sit within an Internal Developer Platform (IDP), and how they integrate.
What is the Humanitec Platform Orchestrator?
A Platform Orchestrator is the centerpiece of any enterprise-grade IDP. With every git-push, the Orchestrator interprets what resources and configurations are required for a workload to run. It creates app and infrastructure configs based on rules defined by the platform team, and executes them.
Humanitec offers such a Platform Orchestrator. It works hand-in-hand with an open-source workload specification called Score.
What is Port?
Port is an internal developer portal that lets you define any catalog for services, resources, K8s, CI/CD etc. It supports any developer self-service action, and is easily extensible.
Comparing the Humanitec Platform Orchestrator and Port
Comparing the Humanitec Platform Orchestrator and Port is like comparing apples and oranges. Both tools are useful components of a successful IDP. However, they belong to different categories, occupy different planes of the platform’s architecture, and have different primary use cases.
As discussed above, Humanitec provides a Platform Orchestrator, whereas Port is a developer portal. The Platform Orchestor’s main purpose is to enable DCM, which eliminates developers’ need to define and maintain environment-specific configs for their workloads. Port, on the other hand, acts as the interface to the developer platform, through a software catalog (services and resources), a user interface for developer self-service actions (e.g. setting up a temporary environment, provisioning a cloud resource and scaffolding a service).
McKinsey developed an IDP reference architecture based on their analysis of hundreds of real-life setups. They broke down IDPs into five constituent architectural planes with unique functionalities. The diagram above is inspired by McKinsey’s research and includes examples of which tools can be included and how they can be combined. The most basic IDP is made up of the Developer Control Plane, Integration and Delivery Plane, and Resource Plane. While Port is part of the Developer Plane and can act as an interface on top of the platform, the Humanitec Platform Orchestrator is part of the Delivery Plane.
How the Humanitec Platform Orchestrator and Port work together
The question is not if you should use the Humanitec Platform Orchestrator Port. Both can be valuable components of your IDP. However, the order in which you select and integrate a Platform Orchestrator and a portal can make a big difference.
First, you should architect your IDP in a way that drives standardization by design across the entire software development lifecycle. The best way to accomplish this is by building your IDP around a Platform Orchestrator like the one provided by Humanitec. Next, make sure you enable Dynamic Configuration Management (DCM) to standardize configuration, provide a clear separation of concerns, and improve developer experience. You can implement DCM by using a workload specification standard like Score in combination with the Humanitec Platform Orchestrator. Then you can decide what kind of abstraction layers should be exposed to developers. For this, you can adopt Port as a developer portal on top of the platform.
Here’s an example of what using the Humanitec Platform Orchestrator and Port together can look like:
- You create a self-service action for a microservice in Port.
- This blueprint is a template in a VCS that includes a sample service and a Score file, which defines the dependencies of the workload.
- Port executes this blueprint by pinging GitHub Actions to execute a build of this service.
- Port then creates an app inside Humanitec and runs the deployment by calling Humanitec’s API.
- The deployment and components are stored as a blueprint in Port’s service catalog.
The scaffolding actions above, you could have also done via GitHub Actions, but now your service is already registered in a portal which is great.
Be aware that problems that usually occur after day 1, have not been solved by scaffolding yet: the complexity of app and infra configurations, adding or removing resources the workloads depend on (such as databases, DNS, storage) for different types of environments.
This is where the Platform Orchestrator and Score come into play.
While the app has been created, Humanitec also created a Score file in the workload repo. Score is an open source workload specification standard.
Via the Score file, developers can now simply request resources their workload depends on or change configs in a very simple way, depending on the context (e.g. environment type). Let's take an example:
- Add the following request to the Score file.
Bucket
Type: s3 - Run a git-push
- The Orchestrator will pick this up and update or create the correct S3 based on the context, create the app configs and inject the secrets.
- At the end it will register the new resource in the portal
- Resources provisioned by Humanitec based on requests from the Score file will be shown on the Port service catalog for better overview
With this setup, developers can choose which interaction to use for which activity:
Conclusion
The Humanitec Platform Orchestrator and Port play complementary roles in building a successful IDP. Organizations deciding which tool to adopt should clarify the base architecture of their platform first, including a Platform Orchestrator and most pressing config management questions, before building a portal on top. See how Humanitec can help you build an IDP your developers will love when you book a demo today.
