| 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. |