[firesteelrain]

You can do that through abstraction. You “include” your Terraform Azure Provider or Terraform AWS Provider. At the end of the day, your module needs to know what it’s interacting with but not the higher level of abstraction. We have done it at my work to make it cloud agnostic just in case we need to go to another CSP

[mattpallissard]

This hould be done even if you don't care about being agnostic. Lay out your declarations in the format you'd like to interact with, then transform them to whatever they need to be.

[m_0x]

> We have done it at my work to make it cloud agnostic just in case we need to go to another CSP

Have you actually tested migrating Cloud Providers with your cloud-agnostic infrastructure?

[firesteelrain]

Yes we tested it with Azure Stack Hub and AWS Outposts

[firesteelrain]

Meaning we made our own wrapper for the terraform azure provider. The higher level does not expose those technical details. It just says virtual machine.

[datahead]

How did you approach testing this? Anything to watch out for when defining abstractions? I'm following Crossplane's abstraction model.

[firesteelrain]

So we start with terraform fmt -check, terraform validate, and terraform plan.

Contract tests are used

Then we have test resources that get created, validated then instantly destroyed.

If we don’t have access to the CSP, then we can only go as far as contract tests. I can’t integrate with it live such as GCP.

Starting to look into Terratest.

[drewcoo]

That's a lot like peppering your C code with #ifdef/#ifndef to write code that's "platform independent." Just like in the bad old days.

[firesteelrain]

No, it’s object oriented like