[oneplane]

This is great if you only target AWS and only have a small scope, but for anything else it sucks (just like CloudFormation itself).

This is one the main problems with most of the CDK-abstracted SDKs for clouds in general where you're essentially just going to re-implement Terraform or SaltStack or Ansible but with your own code that doesn't have the same portability in technical and human terms.

That knowledge about the in-house system is useless elsewhere, and anyone coming in from the outside can't use any pre-existing knowledge. This is of course only a problem in larger scopes, say a larger company with an internal team that does the Ops-leaning side of DevOps.

A company that is larger might simply delegate an entire set of accounts and infrastructure to individual teams where they have to sort everything out themselves, and a company that is smaller is essentially the same as a small division in a large company.

And then you still have the problem if the glue between your AWS cloud, Google cloud, Cloudflare and whatever Git provider you use. No CDK covers that the way something like Terraform with delegation to providers does where you have a standard data format where you can transport information between providers. If you want to create a repo in GitHub, preset some configuration and contents, add that repo to a CD solution that you run on Kubernetes on EKS in AWS with delegated accounts per EKS workload and then connect Cloudflare to ingress ALBs, that's at least 4 different APIs you're talking to with incompatible interfaces. Most of them have CDK's so your interface becomes your own implementation that you now have to maintain. Delegating that to a specialised tool works much better.

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