Spec out how to support Azure in conjunction with AWS

[lorenyu]

Separate infra-template or is there a way to support Azure in the same template using configuration/scripts ?

[doshitan]

Somewhat depends on the outcome of #857

But it should be straightforward to have a template variable for "cloud" or "backend" with aws and azure choices that folks are prompted for on install with the CLI.

Particularly if we move the template content into a subdirectory (example), we should be able to somewhat cleanly separate different clouds like:

templates
  aws
    base
    app
  azure
    base
    app

Or if we can manage the same "interface" for an app regardless of backend, maybe something like:

templates
  app
  base-aws
  base-azure

Or a world where we have the cloud-specific code self-contained and the top-level infra/ are a common "interface" that sources the relevant backend modules (which the selection at template install would prefill).

.
└── templates/
    ├── app/
    │   └── infra/
    │       └── {{app_name}}/
    └── base/
        └── infra/
            ├── modules/
            │   ├── aws/
            │   └── azure/
            ├── accounts/
            │   └── main.tf
            └── ...

One oddity will be around tagging versions. Would seem we have two options:

1. The repo as a whole/"template-infra" entity is what gets tagged
2. We create different tags for each backend

The simplest approach would be the former, but would result in some do-nothing updates to projects when there aren't changes to the cloud they are using.

The second approach may require some additional custom logic in the Platform CLI to retrieve the correct scoped list of tags based on the selected cloud.

[lorenyu]

All makes sense to me.

I lean towards one interface for an app regardless of backend if we can pull that off. But not sure how feasible or if it adds unnecessary complexity.

re: tagging, I lean towards the simpler approach. The release notes can have separate sections, so projects can see if there are any changes relevant to their project. Some releases might say "no impact to projects on Azure" for example. And some changes, like changes to github actions workflows, might impact both.