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. Humanitec itself is about enabling fellow 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”. The idea is that developers tell the platform abstractly how their workload relates to other workloads and their dependent resources (databases, DNS, filestorage, clusters etc.). The platform regenerates all app and infrastructure configs with every deployment. This has a wild impact on standardization and consistency and ultimately slashes the organization's lead time. 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 Humanitec’s products shine. 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 never to leave the version control system and stay in the flow they are familiar with.
Integrate & build golden paths with Humanitec’s products
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 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 incidences.
All in all, we’re slashing lead time and time to market.
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 Postgres (not a specific RDS DB, for instance, just in general a 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, where it “hits” 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. Or if a resource already exists, the Orchestrator can be configured to wired 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, 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!
