Enough high-level. Lean back, drink a Glühwein, and let’s actually learn something.
If there is one thing I love about our technical architecture at Humanitec, it’s the way we handle resources. I can praise this because I’m definitely not the brain behind it. Every single one of my brilliant colleagues in engineering is behind it. They’ve developed something that few yet understand the full beauty of. I’d make the self-confident bet that this design pattern will have quite some repercussions. Let’s dissect it.
An application for me is a set of workloads that have dependencies to each other as well as to dependent resources (cluster, DB, DNS, file storage). Today we conceptually follow the pattern that we “statically” script the application and its dependencies on an environment by environment basis. The “dynamic” element is restricted to the update of an image, assuming all else doesn’t change.
That’s great in 80% of all deployments. But this approach produces significant overhead if anything deviates from the standard workflow. Adding a service, resource, rolling back, or spinning up a new environment? You have to literally piece-meal stuff together. This makes it hard to maintain, adds overhead to the platform team, slows down developers, and eats up 53 hours per team of 7 developers. Not super-efficient.
Our Platform API is what helps you describe an abstract model of your application and will assemble its unique elements dynamically with every deployment. Not only on the application configuration level but also across all dependent resources. This means the API has to deal with any resource, in any cloud provider, with any networking configs. How does it do that? The answer is our approach to dealing with resources. They resolve the abstract request of the application model “I need a Postgres” to “I need a Postgres of type Cloud SQL and it should run in the following GCP account and should clone this data-set as it’s provisioned). In this article, my colleague Chris explains in detail what resources are.
How do you provision resources? Through a concept called “drivers”. In Humanitec drivers are little web services that form web accessible endpoints. The job of Resource Drivers is to take the Resource Inputs for a particular Resource Type and produce the appropriate Resource Outputs. They can give you a new DNS name, or wire your container to an existing database. Chris describes them well in his second article.
Our drivers are open source. You can use our wide range of existing drivers (we’re shipping a whole marketplace soon) or you can build your own. They can also be used in combination with any IaC setup such as Terraform, Pulumi, Crossplane, or CloudFormation.
Resources get matched based on certain criteria. This way the Platform API can just deploy to an environment of type “staging” and can resolve the abstract description of the resources (Postgres) against the actual Cloud SQL that it’s supposed to use for an environment of this type. Chris goes into detail in his third article.
That was a lot! And it’s really new. But the pay-off in terms of workflow efficiency and reduced maintenance overhead is tremendous. We’d be happy to explain it in person, also check out our docs-site or simply start a free trial to test it yourself. We cover a wide range of standard drivers for you to get started.
The year is coming to an end but we still have quite some interesting webinars:
- This week “How to set up Vault for your Kubernetes apps” with our lead QA Nils
- Next week “5 Reasons Internal Developer Platforms are next-level DevOps” with Steve Pereira
- Next year starting hot with Alan Barr “Your Internal Developer Platform s**ks!”
I’m sure you’re drunk by now, that’s great.
All the best,
Kaspar
