The challenge

There are several key problems that today’s platform teams have to tackle. A general lack of standardization leads to config drift and a massive amount of static scripts (e.g. Helm charts) mushrooming throughout the organizations. With no unified developer experience across teams, it’s hard to switch from one product or feature team to another. The usual performance issues (low deployment frequency, long lead times, high change failure rate, long MTTR) are the obvious consequence.

From an Ops perspective, there is the pain of repetitive, manual work and the need to constantly catch up on ticket ops. Too often Ops effectively becomes a help desk (and bottleneck) for devs, who are unable to self-serve what they need to run their apps. This can result in an overall setup that becomes very hard to maintain and scale.

And from a developer standpoint, a lack of self-service means teams constantly have to wait for Ops to do simple tasks (e.g. provision a database or spin up an environment). If they don’t want to wait, developers are expected to understand complex toolchains end-to-end. This leads to extra cognitive load, derails them from coding, and often results in shadow Ops. Not to mention a poor developer experience due to lack of documentation, context switching, and context when underlying tech and tools get hidden from them.

Get started building your Internal Developer Platform

An Internal Developer Platform (IDP) is the sum of all the tech and tools a platform engineering team uses to bind into a golden path. It helps drive standardization and enables developer self-service along the entire life-cycle of an application. The Humanitec Platform Orchestrator enables platform engineers to build IDPs in the fastest, most reliable way. The “magic sauce” is our approach to configuration management, known as Dynamic Configuration Management. Developers use Score (or the UI, CLI or API) to describe how their workload relates to other workloads and their dependent resources (databases, DNS, file storage, clusters, etc.). The Platform Orchestrator generates all app and infrastructure configs with every deployment. This has a wild impact on standardization and consistency and slashes the organization's lead time and time to market. Let’s explore this in more detail.

Start with what you have 

The reality of any engineering organization is legacy. You never start from scratch. You have CI/CD, IaC, resources in the cloud, on-prem, and a wide range of applications. The trick to building great platforms is to integrate, not throw away. This is where our tool shines. Take the below example of a platform which has a wide array of different tools integrated by the Platform Orchestrator. The primary interface to this platform is code-based with our product Score, which allows the developer to never leave the version control system and stay in the workflow they are familiar with.

Integrate and build golden paths with the Platform Orchestrator

The key question in platforming is, how do you get the developer request effectively aligned with the response of the platform team? For mediocre platforms, the answer is a “service catalog”, which prepackages how a “fresh” microservice depending on a PostgresDB, should look like. When the developer uses that template, the platform or Ops team is off the hook, and the developer is on their own.

Platforms that use proper orchestration and Dynamic Configuration Management (DCM) treat every single deployment like day 0. That means it generates a full representation of the app and, if necessary, infrastructure configs with every single deployment. This has an array of advantages:

• Significant impact on standardization and maintainability. This approach leads to a whopping 95% reduction in configuration files.
• High rate of developer self-service and thus a reduction in repetitive requests to operations teams.
• Lower change failure rate and a significant drop in security incidents.

Lead time and time to market drop by up to 40%.

How developers interface 

We’re big believers that the interaction method and the interface between developers and their platforms should primarily be code-based. To drive adoption, it simply makes sense to meet developers “where they are”. We also believe developers don’t want to learn the “quirky YAML format” your organization has come up with and instead want to use reusable industry standards. This is why we developed Score, which has since been adopted by hundreds of teams.

Score is a way for developers to express what their workload depends on in a generalized way. If you look at the Score file below, you can see the dependency on a resource DB of type Postgres (not a specific RDS DB, for instance, just a general Postgres).  You need exactly one Score file per workload repo. It replaces all other config formats and works across all environments. 

The Score file gets sent through your existing CI pipelines to the Platform Orchestrator. The Orchestrator executes an RMCD pattern which stands for Read, Match, Create, Deploy. It’s reading your abstract request and matching the context (deployment to an environment of type staging) with the Resource Definitions and default configs provided by the platform engineering team. It then creates app and infrastructure configs just in time for the deployment. The Orchestrator can now create/update or wire the infrastructure and perform the deployment of the image, although it can also be used in combination with a CD engine.

This is the exact same procedure whether you’re deploying to dev, launching a new service or environment, or making your way to production. It’s a single file, just with varying context.

“Teach” the Orchestrator

The Orchestrator simply does what you configure it to do. Be it how a workload gets deployed, what webhooks are executed, or how a resource is created. The easiest way to tell the Orchestrator what to do is by using the Humanitec Terraform Provider. So when a new resource is needed, users can dynamically configure the Orchestrator to create a new resource. If a resource already exists, the Orchestrator can be configured to wire existing resources to the workload.

Alternative interfaces

The Orchestrator is API first, which means you can build and extend whatever interface you need for your developers. This ranges from the Orchestrator UI to a CLI or any service catalog and developer portal, such as Backstage, Compass, Port or Cortex.

Get your first version of a platform in a day with our reference architectures

After helping a large number of teams build their Internal Developer Platforms, we started to identify common patterns. We’ve summarized our learnings in a reference architecture tailored to your preferred cloud or on-prem environment. Check them out, we hope you’ll find them useful!