Resources in Humanitec
A Resource is something that is consumed or used by a Workload. Resources can either be Shared (available to all Workloads in an App) or Private (only available to a single Workload).
Examples of Resources include:
- a PostgreSQL database used to store customer data,
- a DNS name that a service is exposed to the internet with and
- the Kubernetes Cluster the workload runs in.
Resources can be in-cluster - for example a Kubernetes Namespace that the Workload resides in, or an Ingress Object that defines how the Workload can be reached from outside the cluster. Many Resources are external to the cluster - for example a MySQL database running in an Amazon RDS instance or a DNS name configured in a Cloudflare Zone.
Developers define dependencies on Resources in the Deployment Set - Either as a Shared Resource (available to all Workloads in an App) or a Private Resource (only available to the Workload that defines it).
Platform Teams, independently, create Resource Definitions that describe how and when to provision a Resource. The Dependencies are then matched to the relevant Resource Definition at deploy time by Humanitec.
Every Resource has a Resource Type that defines the technology or class of the object that the Resource represents. Resource Types provide a way to work with resources without worrying about how the actual resource is provisioned. Resource Types define a set of inputs and outputs that are specific to the technology they represent. The inputs are hints that a developer can give to how the resource should be provisioned. The outputs are parameters that the workload will need in order to make use of the resource. For example, a Resource with a
mysqlResource Type represents a MySQL database. It does not matter if the service providing that database is hosted by Amazon RDS, Google CloudSQL or a self-managed instance running on a VM. What matters is that the Workload can connect to the database using a MySQL client at deploy time.
If you are familiar with Object Orientated Programming (OOP), you can think of a Resource Type as an Interface or Base Class that decouples the usage of a system from the implementation of the system. The implementation of the resource can therefore be changed without affecting the way a workload interacts with the resource.
Every provisioned resource requires an ID that doesn't conflict with any other resources in a given Environment. These IDs must begin and end with lower-case alphanumeric characters (
[a-z0-9]), but may also contain dashes (
At deployment time, Humanitec identifies the Resource Types that are needed to satisfy resource dependencies. For each Resource Dependency identified, a matching Resource Definition is selected. The Resource Definition controls which Driver to use in order to provision the resource. The Placeholder outputs provided by the Resource Type are then used to inject the Driver's output into the Workload.
We use provision as a catch-all term for "making resources available". In many cases, you will need to create a new thing - a new DNS name, a new database in an existing instance. However, there are also cases when you will want to provide something that already exists without creating a new thing. For example, in Production, you probably want your Application accessible by a fixed DNS name that you are managing. Rather than create a new subdomain automatically, the production environment should be accessible via a previously defined and configured DNS name.
It is important to remember that when we say provisioning, it does not necessarily mean that anything new has been created.