[irjustin]

Honest question, if you're locked in to AWS why not just use the CDK?

I've used Terraform and Pulumi in the past and the "platform agnostic" is only true for trivial builds. Once you get into medium sized infra you're writing so much AWS specific code it stands better to go 1st party.

I can't speak for GCP, but this is what happened to us. We kept fighting 3rd party code we ended up going CDK. While there are still issues, there were less issues. Cloudformation manages the state under the hood anyway so we're all just stuck wrapping that sucker, even in the CDK.

[anuraaga]

I have found Terraform or Pulumi to be very convenient even with a single cloud because they offer many cloud-agnostic features as well.

- random provider to generate a db password, cloud provider to provision db and admin user, random and mysql providers to provision additional non-admin users, k8s provider to upload credentials to secrets

- tls provider to create ca, k8s provider to create namespace, create certs for each k8s namespace, upload to k8s secrets

- Cloud provider to issue service account key, GitHub provider to upload to GHA (don't do this anymore since oidc is supported, before it was rather important)

While I haven't used CDK much, I believe it is still basically about provisioning aws resources and would not have such cross cutting configs, though I think they may have had a mechanism for importing tf providers.

Terraform can have its issues but overall being able to provision such diverse resources with a single command has been great for onboarding/reducing human error. I'm sure there are plenty of cases where CDK is easier too, these are just to demonstrate why you may use TF even when locked in.

[jochem9]

When I switched from Azure to AWS I just had to learn AWS specifics and then could use my existing TF knowledge to put it in code. No need to learn CDK as well. If I ever end up working in GCP, it will hopefully be the same.

If you solely work with one cloud and don't intend on switching cloud providers or working in a context where multiple cloud providers are used, then by all means specialise. Personally I'm working as a software engineer, so I don't really care in which cloud it runs, as long as I can provision whatever resources I need.

[nailer]

If you were using CDK you’d switch to bicep which also uses code instead of config files.

[e12e]

For anyone else out of the loop, that appears to be:

https://learn.microsoft.com/en-us/azure/azure-resource-manag...

[fcarletti]

It's not about being vendor agnostic, but being able to manage resources outside of AWS. in my use cases, our platform integrated GitHub, Auth0, AWS, kubernetes and so on. Everything managed via Pulumi, what would not be feasible if we were just on Cloudformation.

When trying to achieve a cloud agnostic approach, there are some other tools focused on that (such as serverless framework).

[pachico]

Because you can use Terraform not only for infrastructure. In our case, we use it also to setup GitLab and other services.

[danielbarla]

I absolutely love the CDK's typed approach. Having said that, I still would choose Terraform over CDK mainly because of the way they handle drift detection / drift resolution. Basically, with CDK and the underlying CloudFormation, you can get told that there's a drift. And that's it; now you have to go and fix it manually. Someone deleted half your infra? Well, have fun rebuilding it by hand. With terraform, you just apply again, and it fixes the drift.

There are a number of other subtler topics as well. In my experience, Terraform tends to be noticeably quicker to run (when the limiting factor is not some AWS service that's spinning up for ages - but usually that is not the case after the first run). And just because you're mostly vendor locked, doesn't mean you don't have a few 3rd party vendors to also integrate; it's nice to have a wider support for these providers. While the CDK's types are more consistent than the Terraform ecosystem and generally lead to faster prototyping, the type system itself only protects you from a small subset of errors. You can still wire things together that will never work, and you'll only find out at deploy time. Lastly, I've often found the CDK's versioning to be fairly odd. I get the idea behind stable and experimental packages, and the need to be explicit about these. However, it seems odd that certain packages spend _years_ in experimental, despite being absolutely mainstream from the very beginning (I am looking at you, API Gateway V2 - though it's been a few months since I last checked).

(OK, so this was a bit more tongue-in-cheek than I normally go for. I'm somewhat frustrated by CDK because it has so much going for it, that when it disappoints me, it really hurts.)

[irjustin]

> And that's it; now you have to go and fix it manually

This is very true. We didn't get far enough to get into a drift issue to compare CDK vs 3rd party, so this is new to me, thanks for that. Admittedly, we solved this by saying no one is allowed to click buttons at all on the console for certain envs.

What's worked well for us is we multiple sub-accounts which handle dev(s), stage, uat, prod. Dev(s) accounts are pure temp, use the CDK to stand it up, then click all you want while you "figure it out".

Stage, UAT, and Prod are all code only.

We also separate Network vs Application stacks, but it's more actually delete-able vs critical. Dangerous to delete/mess with - Route53, RDS, VPC, S3 (some). Delete-able is Lambda, EC2, ElastiCache, etc. If we lost these, we don't "lose" anything other than downtime no backups/cust data gone and restoring it is trivial.

Also agreed on the experimental packages or needing to use the escape hatches. We have L1, L2 mixed all over the place. We use almost no L3 because it's like Hello World - great for demos but not really practical and it's easier to customize the L2's because getting access to individual resources in L3 is janky (but we do do it for a few L2's).

[latchkey]

CDK is the correct answer.