Overview

Orientate yourself with Resources.

Understanding Resources #

In the context of the Platform Orchestrator, Resources refer to elements consumed or utilized by a Workload or another Resource. These elements can be either infrastructure-based, like an Amazon S3 bucket, or logical, such as AWS IAM Policies. Each Resource is characterized by a type that signifies the technology it represents, irrespective of its implementation or provisioning method.

• Developers specify dependencies on types of resources that their workloads require.
• Platform Teams devise definitions for provisioning types of resources in various contexts.

Resource Types #

Each Resource is associated with a Resource Type, which defines the technology that the Resource represents. Resource Types facilitate interaction with resources without the need to understand their provisioning specifics. They define a set of inputs and outputs unique to the technology they represent. Inputs guide the resource’s provisioning, while outputs provide parameters necessary for the workload to utilize the resource.

For instance, a Resource with a mysql Resource Type signifies a MySQL database. The actual service hosting the database could be Amazon RDS, Google CloudSQL, or a self-managed instance on a virtual machine. The key aspect is that the Workload can connect to the database using a MySQL client at deployment.

If you’re familiar with Object Orientated Programming (OOP), you can liken a Resource Type to an Interface or Base Class. This analogy helps to understand how it decouples the system’s usage from its implementation. Consequently, the resource’s implementation can be modified without altering how a workload interacts with it.

Context #

Each resource is provisioned within a specified context, comprising three elements:

• Application ID
• Environment ID
• Resource ID

When combined with the Resource Type, the context uniquely identifies a provisioned resource. This combination allows differentiation between active instances of the same resource across various Applications and Environments.

Example #

A developer has added a shared Resource Dependency on a resource of type dns and given it the ID api-dns. (This makes its fully qualified resource ID shared.api-dns.) If there are three environments (development, staging and production) then there are three instances of this resource - one in each environment. Each active resource has the same Application ID and Resource ID, but they contain different Environment IDs. Therefore, they each have a unique context:

Resource provisioning #

During deployment, Humanitec identifies the Resource Types needed to fulfill resource dependencies. For each identified Resource Dependency, a corresponding Resource Definition is chosen. This Resource Definition determines the Driver to be used for resource provisioning. The Placeholders outputs provided by the Resource Type are then utilized to incorporate the Driver’s output into the Workload.

The term provision is used broadly to denote making resources available. Often, this involves creating a new entity - a new DNS name, a new database in an existing instance, etc. However, there are situations where you might want to use an existing entity without creating a new one. For instance, in a Production environment, you might want your Application accessible via a fixed DNS name that you manage. Instead of automatically creating a new subdomain, the production environment should be accessible via a pre-defined and configured DNS name. Remember, provisioning does not always imply the creation of something new.