[ldoughty]

I don't get the obsession with ansible and terraform as CF replacements....

When I explored both, I found no way to "translate" an AWS VM into an azure VM, you have to use completely different modules and inputs.

Same for just about every module I could find... I see almost no benefit if you're working in one cloud to use a "platform agnostic" tool, if that platform agnostic tool uses platform-specific modules.

We tried terraform for making VPCs and Subnets for a simple 4-VM setup, and every module was AWS specific.

I tried it in Ansible and had the same issue

Ultimately we went with CloudFormation because, while it's not perfect either, it didn't break from minor-level module revisions on the community supported packages

[oneplane]

Sounds like you had a bad experience when you tried to set application state (a VM) using a declarative tool (Terraform). That's not very surprising and also not even remotely related to what I wrote.

At the same time, CloudFormation does nothing for Azure, so I don't understand where your comparison is coming from.

CloudFormation can only do AWS. Period. And unless you somehow manage to pin yourself to AWS in a greenfield scenario that means it will not be sufficient.

At the same time, CloudFormation is (in my opinion) a nasty way to describe desired state, and sharing anything (i.e. results) with anything else (i.e. non-AWS systems) is not possible, meaning you have to write something for that yourself.

If you are creating a single AWS account with a VPC, some subnets and a few EC2 instances, you're essentially just doing fake-cloud and you might as well do that in the console with no IaC whatsoever. That is not meant as some weird derogatory statement, but I'm not talking about managing a handful of resources in a single account here. I'm also not talking about a magic multicloud translator, but about IaC orchestration across multiple providers (terraform terminology applied).

If we take AWS out of the equation and look at something else, i.e. Cisco ACI, VMware NSX, Palo Alto, F5, those all have Terraform providers as well. No CloudFormation tho. So what if you're setting up a BGP peering over your DirectConnect, you gonna do the CloudFormation thing on the AWS side and manual configuration on the Palo Alto side? That would require at least 3 different CloudFormation stacks that you manually have to run in the right order.

[cconstantine]

You will never find a tool that does a good job of translating between different platforms like that. The systems are too different, and the details matter too much.

The value of being multi-platform is that it lets you manage resources in multiple clouds with the same tool, and coordinate the changes. For example; it would let you have application instances and databases in GCP, and manage your DNS is AWS. When you make changes to the instances in GCP, the tool would know to update the DNS records in AWS.

[raffraffraff]

Another real-world example I've used that doesn't even require you to have multi-cloud: deploying an EKS cluster to AWS, deploying charts to EKS and finally creating a CNAME to the ALB in Cloudflare. You could even add Cloudflare Access, Workers etc.

[oneplane]

I'm doing the same thing. First a repo is setup in GitHub using the GitHub provider, when that is done, the base configuration for Flux is added in there and then the lifecycle on that is going to ignore future changes.

Next, an AWS account is generated and then a CIDR is read from Netbox. That is used to create the VPC and subnets, and after that an EKS cluster is created. Next the Kubernetes provider is used to install everything needed for Flux, and it is pointed to the GitHub repo that was setup earlier.

At this point the team that wanted a dedicated Kubernetes cluster can just put their charts and manifests in the github repo and it is automatically deployed.

[cconstantine]

I'd still call that multi-cloud ;)

I've done something similar in the real world. We used cloudflare for our dns / application firewall, but we kept a route53 zone mirrored after cloudflare had a spat of issues. It would have let us switch our dns provider as quickly as dns would allow if we had to drop cloudflare.