Yes. But only with the CDK.

Same. The CF templates are a nightmare at any reasonable size.

Yes. Directly – no CDK or wrappers – using the serverless transform when it makes sense.

I know how CloudFormation behaves, and none of the wrappers have convinced me that translating through CloudFormation makes sense. ("through" because if you're using CDK, you're translating from imperative to declarative to imperative... why?!)

I write CloudFormation for a living. I had been quick to disregard CDK, and sort of ignored it for a while.

I tried it on a recent greenfield project, and now I’m kicking myself for not giving it a try in earnest earlier.

It's in my opinion one of the more interesting tech in the IaC space. Even the way it works internally with the JS interpreter is kind of smart.

What do you mean by "JS interpreter"? Can you elaborate?

The libraries for other supported languages of CDK are built as wrappers for underlying JS or maybe TS code via https://github.com/aws/jsii

So all the core CDK code is written first in JS/TS and then stubs for the other languages are added

Unfortunately this is often done without consideration for how the other supported langs actually work, and artefacts of e.g. JS lack of support for kwargs leak through

This is why e.g. the typing in CDK Python is completely broken - pretty much uniformly the concrete types like "Resource" don't implement their corresponding interface like "IResource" (to a type checker)

(There are many other typing niggles like this but that's the most egregious and pervasive one)

At the end of the day, having to explicitly cast concrete types as their interface to satisfy type checker is a minor annoyance, albeit a stupid one that could have been avoided with more care in the core library.

I could live with that, but I encountered so many bugs and issues trying to use CDK on current project that it's now much clearer to me why every company I worked at previously was using Terraform.

Pretty sure some of those issues are ultimately CloudFormation ones. The cumbersome CF > CDK JS > CDK Python stack is great for obfuscating errors and making debugging hard or impossible though.

Pulumi do something similar, albeit with Go as the core language and Terraform underneath. From what I've seen with a little use they have a much more successful result though, Pulumi Python was not a complete mess, and deploys faster and more reliable with better error feedback. I guess they just took more care to get it right.

Yes, purely from a user pov, the way fake stack traces are reported to point out the failing construct is quite nice.

Try Pulumi and have the same experience (but now vs CDK) all over again?

Pulumi is not on some of my clients’ approved software list, so no can do.

Plain CF sucks because it doesn't really provide any kind of abstraction capability. So in any kind of real world application the yaml gets humongous that is very hard to review.

I would have been perfectly happy to use CF if they added the notion of higher level constructs at CF level, but for whatever reason they haven't. So I use CDK because it provides the ability to reuse service compositions from third party libraries as well as across different internal projects.

CDK is imperative but imperatively building the configuration is not at all the same as imperatively managing the infrastructure. Even if with CDK the configuration is imperatively built you retain all the benefits of having declarative infra - version control, selective auto update, rollback to previous state etc.

Yes, while CF is clunky and slow, and I am sure everyone who uses it has at times gotten stuck with rollback failures, but CDK does provide a somewhat better dx on top of it.

There are tons of resource types only available via cfn compared to cloud control api vs terraform vs direct api, any decently complex deployment often requires mixing one or more options just to get full coverage

> There are tons of resource types only available via cfn compared to ... terraform

And the other way round

Besides SAM junk what else is not available through APIs?

It's used under the hood by AWS CDK and AWS SAM, both of which are popular

Used by serverless framework.

Indirectly and/or under the hood. What alternatives are there? Terraform?

Terraform

Crossplane (although it's quite new, and missing a lot of things that Terraform has)

i use it on my team. Makes it easy for every dev to set up their own environment

Yes. Curios what do you use?

Yes, I have engineers who refuse to use anything else.

What would you use instead?

not OP, but I use terraform instead.

Terraform is too low level. If only there were L2 / L3 constructs like CDK. There are modules, but often only community / 3rd party.

> There are modules, but often only community / 3rd party.

What, it's Terraform's fault that you haven't bothered to write one yourself?

> What, it's Terraform's fault that you haven't bothered to write one yourself?

Let's just all code in assembly then? Because we all should bother to write anything and everything from scratch?

No? The complaint was that they had to use a third party or community one, as though those people are doing by some kind of magic unavailable to them; they for some reason don't want to use those (maybe they're not suitable for particular use case, I don't know) and it's somehow terraform's fault that they haven't then written their own. It is possible, so I just don't understand what the complaint is.

> It is possible, so I just don't understand what the complaint is.

And it is also possible to write in assembly, will you?

> The complaint was that they had to use a third party or community one

And isn't that fair? People want support? Official support? Is that wrong? And yes community modules especially since they might not be from the same group lack consistency, documentation and often doesn't get updated as regularly. The magic is the vendor is the only 1 that can properly coordinate updates.

> as though those people are doing by some kind of magic unavailable to them

Then why are you using Terraform? The APIs behind Terraform are also available to you so you can use that directly. There's no magic unavailable to you either. And you go beyond not using those APIs and build your own servers and data centers too.

I don't get why Terraform is a fair abstraction you're defending yet you're arguing against people wanting a higher level of abstraction.

I'm not arguing against higher abstraction, I'm not saying write assembly.

Modules are the same abstraction as L2/L3 constructs. In either case if you don't want to use someone else's (and you want one) you write your own. If you then haven't, it's not Terraform's or AWS CDK's fault.

Yes. No L2/L3 constructs is a hard no from an IaC buy-in perspective

Well terraform is never going to have 'L2/L3 constructs' because that is just AWS terminology. https://docs.aws.amazon.com/prescriptive-guidance/latest/aws...

What it does have is modules, which accomplish the same. And of course, if you don't want to write them then just as with L2/L3 constructs you are limited to using others'.

That’s on the way, eg

https://developer.hashicorp.com/terraform/cdktf

Sure, but we're talking about now. Lots of things have been "on the way".

I find terraform doesn’t do the tear down as well

In what way?

I've always found that Terraform does it exceptionally well, mostly because of the dependency graph and how good providers map resources so that they don't end up in a dead lock.

I've found the exact opposite of that in practice. Had way more problems with tearing down CDK stacks

Yes. It’s good.