Starting your journey into platform engineering is not a simple task. With a seemingly endless landscape of tools to choose from, the task of finding the right one can quickly begin to feel impossible.
This article aims to shed light on this challenge by highlighting two specific tools: Cortex’s developer portal and the Humanitec Platform Orchestrator. We’ll take an in-depth look at their key features, how they fit into your Internal Developer Platform (IDP), and their integration capabilities.
Per Gartner’s definition, "Internal Developer Portals act as the interface that allows developers to discover and access the capabilities of an Internal Developer Platform.”, you can think of the Portal as the frontend of your Internal Developer Platform, while the Platform Orchestrator would be the graph-based backend. Let’s dive in.
Platform architecture
Let’s take a look at the architecture of an Internal Developer Platform that uses the Humanitec Platform Orchestrator and Cortex Developer Portal.
This reference architecture has 5 planes.
- Developer control plane, including a developer portal like Cortex and an open source workload specification such as Score, alongside Resource Definitions in the Platform Source Code section
- Integration and delivery plane, which includes the Platform Orchestrator, in this case, Humanitec.
- Resource plane
- Observability plane
- Security plane
The reference architecture above focuses on an IDP for AWS, however, reference architecture implementations are also available for GCP, Azure, and Red Hat OpenShift. You can also find more on resource definitions, Score implementations, and other open-source building blocks in the Humanitec marketplace.
Humanitec Platform Orchestrator - graph based backend
As stated above, the Platform Orchestrator serves as the Internal Developer Platforms backed. It operates after the CI process and reads declarative, abstract requests (such as a developer requesting a Postgres database for their workload in a staging environment). It then interprets the context (in this case, environment=staging) and applies the rules defined by the platform team. The orchestrator then generates an executable resource graph, which can either be deployed directly by the Orchestrator or through an existing CD solution, like ArgoCD, to synchronize with the cluster.
The Humanitec Platform Orchestrator integrates seamlessly with your chosen interface, whether that is the Portal, your CLI, or a workload specification like Score, which was recently accepted as a CNCF Sandbox project.
In the above image, you can see how the Platform Orchestrator takes a declarative input of dependencies (such as frontend input or workload specifications from Score) and then interprets the request's context, matches it with the Resource Definitions provided by the platform, and builds an execution-ready Resource Graph.
This architectural approach ensures that the definition of a Resource Type remains consistent across different contexts. For example, all "Postgres" resources in the "staging" environment are configured uniformly and managed throughout their lifecycle, with any external changes automatically reverted to the standard configuration.
The Resource Graph can either be executed directly by the Orchestrator or generated as code and synchronized by a GitOps operator, such as ArgoCD.
Utilizing Cortex as a portal
As highlighted in the reference architecture diagram above, it's common practice to position a developer portal on top of such a platform setup. These portals typically include a service catalog, which helps manage existing services and offers scaffolding features for standardized Day 1 operations, enhancing developer self-service capabilities.
Developer portals will also frequently feature scorecards, which assist developers and management in tracking DORA metrics, operational maturity, and migration efforts.
Though, open-source options like Backstage often require a steep learning curve and can be challenging to configure, however, there are now an increasing number of available commercial developer portal vendors that focus on resolving this issue.
One of those, Cortex, has quickly become one of the leading internal developer portals. Its intelligent software catalog automatically aggregates the latest information about all your services and resources from your critical developer tools into a single place. Cortex also enables scaffolding and Day 1 operations that ensure all new services are deployed according to the same standards.
Achieving the optimal Internal Developer Platform setup
When building an Internal Developer Platform using the Humanitec Platform Orchestrator alongside Cortex as the developer portal, the use cases for these two tools might look like this:
Cortex and Humanitec in action
Next, let's examine how the Platform Orchestrator and Cortex can collaborate effectively.
- To begin, you'll need to configure both Humanitec and Cortex. For Cortex, it's important to carefully assess the data model of the software catalog, which includes components like CI/CD data, API data, resource data, Kubernetes data, and more. Additionally, determine an initial set of self-service actions to offer in the portal.
- Let's say your goal is to create a self-service action for provisioning a microservice within Cortex.
- Make sure the microservice template includes a Score file defining workload dependencies.
- Cortex starts the scaffolding by triggering a GitHub Workflow to execute the service build process.
- After the service build is complete, the Platform Orchestrator is notified and dynamically generates configuration files tailored to the deployment context. This context may be based on API calls or tags provided by your CI system.
- Humanitec takes charge of deploying the new service.
- The newly created microservice entity seamlessly integrates into Cortex's software catalog.
However, keep in mind that the journey doesn't stop on Day 1. Managing intricate application and infrastructure configurations, along with adding or removing workload-specific resources such as databases, DNS, and storage for different environments can be a large challenge.
This is where the Internal Developer Platforms backend, the Platform Orchestrator alongside Score comes into play. Once the app is created, Humanitec generates a Score file in the workload repository.
Through the Score file, developers can now easily request the resources their workload depends on or modify configurations in a simple manner, based on the context (e.g. environment type) For example:
1. Add the following request to the Score file.
resources:
...
s3:
type: s3
class: basic-admin2. 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 Cortex service catalog for a better overview
With this setup, developers can select which interaction to use for each specific activity.
Conclusion
The Humanitec Platform Orchestrator and Cortex are a powerful combination for building a highly effective enterprise-level internal developer platform. Organizations that are looking to improve developer productivity, and, drive a significant reduction in time-to-market should first adopt a Platform Orchestrator as their backend, and then enhance it with a seamlessly integrated developer portal like Cortex.
Want to get started right away? Speak to one of our platform architects, or join the Humanitec Minimum Viable Platform (MVP) program.
