Use terraform for build (and destroy)

[stevemcghee]

consider using https://cloud.google.com/docs/terraform/blueprints/terraform-blueprints and blueprints-controller

[ameer00]

https://cloud.google.com/docs/terraform/best-practices-for-terraform

[stevemcghee]

let's make sure we understand if we are building a blueprint (made of modules) or just a single module.

[MKand]

We could go either way, but IMO starting off with modules and then refactoring to blueprints might be a better approach. Here is why. You will start getting things out faster, and then get an idea with some use of what an effective blueprint might be. Otherwise it might risk over-engineering things from day 1. My initial idea was to keep each archetype as a separate module (taken from the GCP examples from your deck). And then later expand to creating more dynamic configurations with things like autopilot, cloudrun, and also archetypes. How do you guys see this?

[stevemcghee]

thats fine by me. before we get into cloudrun etc, lets just focus on getting modules that allow turnup/turndown of this system, of course.

[ameer00]

I wanted to share three options for Terraforming (in my opinion):

Option 1: Convert all build steps into Terraform

1. No changes or enhancement, simply "lift and shift" to terraform.
2. Create custom code to achieve this
3. Quickest to achieve
4. If we want to move to other options, then this may be considered wasteful work.
5. Not much re-usability (since it will be very specific to this workshop)

Option 2: Convert to Terraform by using only existing modules/blueprints

1. Use only existing/supported Terraform modules and blueprints. No custom code.
2. Convert current builds steps to conform to modules/blueprints for example convert the current custom CICD to the (secure cicd)[https://github.com/GoogleCloudPlatform/terraform-google-secure-cicd] blueprint
3. Not the quickest, requires some refactoring (of the current build process)
4. Mimics how we want customers to use Terraform modules/blueprints
5. Customers can use this repo as an example on how to build archetypes in their environmensts but they won't have blueprints that allows then to build this (see option 3)

Option 3: Create new blueprints and use the new blueprints for the workshop build (like customers would)

1. For instance, we can create one (or more) gke-multicluster-archetypes blueprints that represent the 5 archetypes
2. We use these blueprints for the workshop repo just like a customer would
3. We build these blueprints to align with other blueprints like (secure cicd blueprint)[https://github.com/GoogleCloudPlatform/terraform-google-secure-cicd] to. maximize composability
4. These will be "official" blueprints so will need to be maintained by the "community". If we go this path, we will need to make sure we have a community to build/maintain this
5. Longest of the 3 options to achieve
6. Easiest for customers to build archetypes using these "official blueprints"
7. Required for Jump Start Solutions.

Note we can also do this in phases/milestones instead of choosing one and only one.

[stevemcghee]

@MKand can you comment/close here? i think we just went with (1)