terraform

With a background using Python and OOP, terraform is nearly a synonymous concept. I've only started using terraform in the past couple of years, and amazed at the ease yet its complexity when it comes to automation pattern and design.

For instance, when you start to break down individual components into hierarchies of modules, which consist of related resources, data, and variables; then the ability to dynamically referenced them from bottom up, depending how you organize the hierarchy can get convoluted and complex if you haven't had a well-thought out architectural design!

terraform vs oop

Terraform has been super popular that has been dominating the IaC area for sometime, especially when it comes to infrastructure as code within the devops and infra space. It it almost a prerequisite if you're in devops/infra engineering.

What makes terraform an awesome IaC is that is super well-documented, and and it's an OSS ecosystem that leverages a multitude of third-party API frameworks that is widely contributed across the platform. This also makes it a super friendly place to learn.

Here, the intention is not to cover the basics or how-to's, instead, I'd like to deconstruct terraform based on OOP concepts as aforementioned, because I really think that HCL has that kind of design in mind when it was first created by its creators.

abstraction

In my opinion, I think terraform is a highly abstractive Hashicorp language (HCL). To write great automation framework, you really have to understand how to decompose terraform into modules. This is really where the crux of dynamic programming comes into play.

So back to talking about what makes it an abstraction layer. It's really the fact that if you start to add in layers of hierarchical files, there are many hidden inputs under it that doesn't necessarily have to be spelled out each time - hence its an abstraction concept.

A simple real world example would be something like:

You created 3 storage boxes to organize your garage.

Storage A contains:
    - office supplies box
    - school papers box
    - personal mails box
Storage B contains:
    - backpacks box
    - climbing gear box
    - running shoes box
Storage C contains:
    - pet supplies box
    - pet food box
    - pet apparel box

To transcribe this into terraform design, the 3 storages can be created into modules as such: 
- Modules
    - Storages
        - A
            - main.tf
            - providers.tf
            - variables.tf
            - outputs.tf
        - B
            - main.tf
            - providers.tf
            - variables.tf
            - outputs.tf
        - C
            - main.tf
            - providers.tf
            - variables.tf
            - outputs.tf
    main.tf
    providers.tf
    variables.tf
    outputs.tf

Here, you can think of main.tf's as the abtraction layer, because its implicitly defining what each of storage modules are composed of without having to be explicit about it.

The explicit component sits in the variables.tf's, and its name is literally as such.

encapsulation

Going back to the same storage example here. Encapsulation in this case would be everything that gets defined in main.tf's should include all the storage API attributes such as resources, external data references, and providers that forms this dynamic invocation of related components.

These storage containers of boxes can have relationships between each other, where storage A could also have pet supplies, not just office supplies. Storage B can have both backpacks and climbing gear boxes packed together. Storage C can have pet supplies, food, and apparel boxes be in a single box.

composition

What about composition? Well, some

inheritance

automation

use-cases

Here is a simple Databricks usecase of how I built the databricks ecosystem using Terraform to automate the entire platform.

automating databricks using terraform

cicd deployment