Humanitec makes use of drivers to provision resources used by workloads. For example, one driver might provision a new DNS name for an environment, a second might provision a Redis cluster using AWS’s ElastiCache for Redis, and a third might create a Traefik IngressRoute CRD. In many cases, an easy-to-use driver is available that requires the definition of only a handful of inputs. However, if you want more control you might use a more general driver, such as the Terraform driver. This allows precise control but at the expense of much more complexity.

The Virtual Driver feature allows operators to abstract away this complexity by defining a “virtual driver” that provides a simpler interface.

Let’s dive into the details!

Using generic drivers is complex

A Resource Definition specifies how to provision a resource by stating the resource type, which driver to use, the driver inputs, and the context in which to provision the resource.

Let’s take an example of provisioning a managed Redis cluster in AWS using Terraform. Our resource definition would have:

• A type of redis
• The humanitec/terraform driver
• Driver inputs that need to specify the following
• ~ A path to our Github repo containing the Terraform files
• ~ Module inputs such as:
  - The subnet to assign IPs from
  - The security group IDs that the cluster should have
  - The version of the Redis engine to use
• We would also need to define a matching criteria.

This is a lot of data for one Resource Definition. What if we wanted to make some small changes (e.g., the subnets and security groups) for provisioning the Redis cluster in staging or production? We would have to repeat everything in a second resource definition. This does not follow the DRY (Don’t Repeat Yourself) principle, making maintenance harder.

Making resource definitions DRY with virtual drivers

Virtual drivers allow you to wrap up all the complex parts of one driver and expose a simple subset.

Let’s take our example from before: Rather than re-specifying all of the details (e.g. the GitHub repo and Redis engine version), these can be hard-coded into the virtual driver. The virtual driver then exposes the inputs you want to change. Then, resource definitions can use this new virtual driver. Meaning you will only need to provide a smaller number of inputs. Under the hood, the virtual driver combines those inputs with the hard-coded ones and calls the Terraform driver.

Check out the documentation, or schedule a demo call to learn more.