The Humanitec Platform Orchestrator and Port are two complementary parts of a successful enterprise-grade Internal Developer Platform (IDP). This article explains how they can work together, and highlights the new integration recently published by Port.
You can also see the integration live and in action in this recording of a webinar we hosted together with Port:
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.”
While a portal acts as the interface (frontend) of an Internal Developer Platform, the Platform Orchestrator is the graph-based backend of the platform.
In this article, we’ll cover the primary features of the Humanitec Platform Orchestrator and Port developer portal, the categories they belong to, where they sit within an Internal Developer Platform, and how they integrate.
What is the Humanitec Platform Orchestrator?
A Platform Orchestrator is a platform backend that sits post-CI system. It reads in a declarative, abstract request (for instance, a developer wants a Postgres database for their workload, to be deployed to staging). It interprets the context of the request (environment=staging in this case) and matches it to the rules set by the platform team. It then outputs an executable resource graph that can be deployed directly by the orchestrator or by an existing CD solution (synced to the cluster by ArgoCD).
Humanitec offers such a Platform Orchestrator. It works hand-in-hand with an open-source workload specification called Score, which recently became a CNCF Sandbox project.
As represented in the Resource Graph above, you can see how the Platform Orchestrator takes a declarative input of dependencies (frontend input, workload spec, etc). It then interprets the context of the request, matches Resource Definitions provided by the platform, and constructs an execution-ready Resource Graph.
This architectural approach ensures that the definition of a Resource Type remains consistent across different contexts. For instance, all "Postgres" resources in the "staging" context are configured identically and managed throughout their lifecycle, and any changes made outside the platform are automatically reverted to the standard configuration.
The Resource Graph can be executed directly by the Orchestrator or generated as code and synchronized by a GitOps operator like ArgoCD.
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 take care of app and infrastructure configuration in a dynamic way, 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).
The Internal Developer Platform, which you could build with Score, Humanitec Platform Orchestrator, and Port will look similar to the one in the reference architecture diagram above.
Check this page for more examples running on Google Cloud, AWS, Azure, or Red Hat OpenShift.
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 or 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 graph-based backend, a Platform Orchestrator like the one provided by Humanitec. Next, make sure you provide a code-based interface to developers to avoid the necessity of context switching by using a workload specification standard like Score in combination with the Humanitec Platform Orchestrator. Then you can decide what other kinds 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 (see also the docs of Port’s Humanitec integration):
- 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.
Get started right away by speaking to one of our platform architects, or joining the Humanitec Minimum Viable Platform (MVP) program.
