Drive Platform Engineering Success with Humanitec and Port
Platform engineering is evolving like crazy. So many cool new tools are popping up left, right and center, all designed to boost developer productivity and slash lead time. But here’s the thing. For many organizations, this makes picking the right tools to build an internal developer platform an instant challenge, especially when so many seem to do the same job.
At Humanitec we get the need to ensure you’re using the right tech to get things rolling smoothly. This article aims to shed some light on two such tools: the Humanitec Platform Orchestrator and Port, an internal developer portal. We’ll dive into the differences, their functionalities and the unique roles they play in building an enterprise-grade internal developer platform.
The Power of the Platform Orchestrator
The Humanitec Platform Orchestrator sits at the core of an enterprise-grade internal developer platform and enables dynamic configuration management across the entire software delivery cycle. The Platform Orchestrator enables a clear separation of concerns: Platform engineers define how resources should be provisioned in a standardized and dynamic way. For developers, it removes the need to define and maintain environment-specific configs for their workloads. They can use an open source workload specification called Score to define resources required by their workloads in a declarative way. With every git push, the Platform Orchestrator automatically figures out the necessary resources and configs for their workload to run.
When used to build an internal developer platform, the Platform Orchestrator cuts out a ton of manual tasks. The platform team defines the rules, and the Platform Orchestrator handles the rest, as it follows a “RMCD” execution pattern:
- Read: Interpret workload specification and context.
- Match: Identify the correct configuration baselines to create application configurations and identify what resources to resolve or create based on the matching context.
- Create: Create application configurations; if necessary, create (infrastructure) resources, fetch credentials and inject credentials as secrets.
- Deploy: Deploy the workload into the target environment wired up to its dependencies.
No more configs headaches, just more time to focus on the important stuff that adds real value.
The Pivotal Role of Internal Developer Portals
Like the Platform Orchestrator, internal developer portals like Port also play a pivotal role from the platform perspective, mainly since it acts as the interface to the platform enhancing the developer experience. However, the two tools belong to different categories, occupy different planes of a platform’s architecture and have different primary use cases.
Note: The components and tools referenced below apply to a GCP-based setup, but all are interchangeable. Similar reference architectures can be implemented for AWS, Azure, OpenShift or any hybrid setup. Use this reference as a starting point, but prioritize incorporating whatever components your setup already has in place.
For example, where the Platform Orchestrator is the centerpiece of an internal developer platform, Port acts as the user interface to the platform, providing the core pillars of the internal developer portal: a software catalog that provides developers with the right information in context, a developer self-service action layer (e.g., setting up a temporary environment, provisioning a cloud resource and scaffolding a service), a scorecards layer (e.g., indicating whether software catalog entities comply with certain requirements) and an automation layer (for instance, alerting users when a scorecard drops below a certain level). Port lets you define any catalog for services, resources, Kubernetes, CI/CD, etc., and it is easily extensible.
Same tools or apples and oranges?
So, you could say comparing the Humanitec Platform Orchestrator and Port is like comparing apples to oranges. Both play important roles in building a successful platform. But they’re not the same thing at all. The Platform Orchestrator is designed to generate and manage configurations. It 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. As a result, developers don’t have to worry about dealing with environment-specific configs for their workloads anymore. The Platform Orchestrator handles it all behind the scenes, making life easier for them.
Port, on the other hand, is like the front door to your platform. It acts as the interface, containing anything developers need to use to be self-sufficient, from developer self-service actions through the catalog and even automation that can alert them on vulnerabilities, ensuring AppSec through the entire software development life cycle. In short, an internal developer portal drives productivity by allowing developers to self-serve without placing too much cognitive load on them, from setting up a temporary environment, getting a cloud resource or starting a new service. It’s all about making self-service and self-sufficiency super smooth for developers.
Building the Perfect Platform with Port and the Platform Orchestrator
The real magic happens when these two tools join forces. While they support different stages in the application life cycle, they can be used in tandem to build an effective enterprise-grade internal developer platform that significantly enhances DevOps productivity.
So when it comes to the Humanitec Platform Orchestrator and Port, it’s not about choosing one over the other. Both can be valuable tools for your platform. What matters is the order in which you bring them into the mix, and how you integrate them.
Step one, let’s set the foundation right. You should structure your internal developer platform to drive standardization across the end-to-end software development life cycle and establish a clear separation of concerns between app developers and platform teams. And the best way to do that is by starting with a Platform Orchestrator like the one from Humanitec. Think of it like the beating heart of your platform.
Next, you can decide what abstraction layers should be exposed to developers in the portal, what self-service actions you need to offer them to unleash their productivity, and which scorecards and automations need to be in place. For this, you can adopt Port as a developer portal on top of the platform.
Port and Humanitec in Action
Here’s what combining the Humanitec Platform Orchestrator and Port could look like:
- First, you’ll need to set up both Humanitec and Port. For Port, you’ll need to think about the data model of the software catalog that you will want to cover in Port, for instance, bringing in CI/CD data, API data, resource data, Kubernetes data or all of the above. You’ll also need to identify a set of initial popular self-service actions that you will want to provide in the portal.
- Let’s assume you want to create a self-service action to deploy a new build of a microservice in Port.
- Make sure the microservice repository/definition includes a Score file, which defines the workload dependencies.
- Port receives the action request and triggers a GitHub Workflow to execute the service build.
- Once the service is built, the Platform Orchestrator is notified and dynamically creates configuration files based on the deployment context. The Platform Orchestrator can derive the context from API calls or from tags passed on by any CI system.
- Humanitec deploys the new service.
- The resulting new microservice deployment entity will appear in Port’s software catalog.
Don’t forget what happens after Day 1, though. Dealing with complex app and infra configs, and having to add or remove workload-dependent resources (stuff like databases, DNS, storage) for different types of environments, can equate to a ton of headaches.
This is where the Platform Orchestrator and Score do their thing. With Score, open source workload specification, developers can easily request resources their workloads need or tweak configs in a simple way, depending on the context — like what kind of environment they’re working with. Let’s dive into an example to make it clear:
1. Add the following request to the Score file.
|
1 2 3 |
Bucket Type: s3 |
2. Run a git push.
3. 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.
4. At the end, it will register the new resource in the portal.
5. Resources provisioned by Humanitec based on requests from the Score file will be shown on the Port service catalog for visibility and also to enable a graphical overview of the resources.
Port comes with additional capabilities beyond scaffolding microservices and spinning up environments, and also for self-service actions that are long running and asynchronous or require manual approval. Sample Day 2 actions are:
- Add temporary permissions to cloud resource.
- Extend developer environment TTL.
- Update running service replica count.
- Create code dependencies upgrade PR.
- And more.
Drive Productivity and Slash Time to Market
To sum up, the Humanitec Platform Orchestrator and Port are an awesome match when it comes to building an effective enterprise-grade internal developer platform. And the best place to start? Build your platform around the Platform Orchestrator. That’s the key to unlocking the power of dynamic configuration management (DCM), which will standardize configs, ensure a clear separation of concerns and take your DevEx to the next level. Then, choose your developer abstraction layers. This is where you can use Port as a developer portal sitting on top of the platform. Successfully integrate the two and expect productivity gains, a boost to developer performance and, ultimately, slashed time to market.
