[habitue]

I just started using CDK for a project, and after having fought with terraform and trying pulumi, I have to say CDK is a breath of fresh air. Really well thought out, makes doing things the right way easy as well.

The biggest difference I can see between CDK and pulumi (other than CDK only being for AWS) is that the CDK is more opinionated. When you spawn a new database, it'll automatically create a secret in secretsmanager, and set up rotation etc. And since it can assume IAM, it generates granular policies for you easily with calls like `dbInstance.grantRead(lambdaInstance)` etc, instead of you having to manually construct a JSON policy.

I really think the pulumi / CDK method of "Use a real programming language to generate a declarative spec" is the right way to go.

For those keeping score:

- chef/puppet: imperative language, imperative effects

- ansible: declarative language, imperative effects

- terraform: declarative language, declarative effects

- CDK/Pulumi: imperative language, declarative effects

Not to mention, CloudFormation actually allows ~transactions, which is something you can't really get without cooperation from the cloud provider

Edit: I incorrectly mentioned that terraform uses cloudformation to get transactions, but it does not

[throwaway894345]

> Not to mention, CloudFormation actually allows ~transactions, which is something you can't really get without cooperation from the cloud provider (terraform and pulumi both use cloudformation on AWS for exactly this reason)

Terraform doesn't use CloudFormation on AWS (and I thought Pulumi used Terraform under the covers in some capacity?). I've also seen a lot of CloudFormation stacks get into completely unrecoverable states because AWS was trying to roll back a transaction, but the rollback failed. If you have a premium support contract, someone can un-stick it for you, but for the rest of us we just had to create a new stack. I've been off AWS for a year and change, so maybe this has improved?

In whichever case, I've only dabbled with CDK, but I was disappointed. What I really want is a better Troposphere[0]--sort of an AST library for CloudFormation, ideally type-safe. I don't care that the backend is CloudFormation in particular, but the idea is that we should have a clean separation between the backend diff engine and the abstraction layer that humans use to DRY the input to the backend diff engine.

[0]: https://github.com/cloudtools/troposphere

[onefuncman]

> maybe this has improved?

Yes, you can recover a Cloudformation stack from any status nowadays. Ex: https://aws.amazon.com/premiumsupport/knowledge-center/cloud...

[ldoughty]

Note that the CDK has "levels" of abstraction.

Level 1 is basically full parity to CloudFormation.

Level 2 has reasonable defaults, typically.

Level 3 has opinionated implementations.

At level 3, you can have a reasonable multi-az multi-subnet ECS cluster in 5 lines.. which is a good starting point to work from in many cases.

For those doing really nitty gritty stuff, you can still work at level 1, and make IaC in a familiar language better suited for programming logic than CF (or even ansible or terraform) are.

We've used raw CF for hundreds of thousands of deploys (VM stacks).. AWS SAM for thousands of our serverless infra deploys, and we've also used ansible and terraform for some of our overhead / management layers (managing IAM, mostly). we're really excited to move our raw CF templates into the CDK next year, our "conditions" and parameter blocks are getting annoyingly dense and difficult to follow.

[fitzoh]

>The biggest difference I can see between CDK and pulumi (other than CDK only being for AWS) is that the CDK is more opinionated. When you spawn a new database, it'll automatically create a secret in secretsmanager, and set up rotation etc. And since it can assume IAM, it generates granular policies for you easily with calls like `dbInstance.grantRead(lambdaInstance)` etc, instead of you having to manually construct a JSON policy.

Hopefully this will get better soonish on the pulumi side. [awsx](https://github.com/pulumi/pulumi-awsx) has existed for a while which is sort of takes the CFN higher level construct approach, but it's currently typescript only.

They just finished some foundational work to enable multi-language components, and I expect we'll see some opinionated/higher level components from them for all languages in the next 6 months or so.

[Aeolun]

I kind of like that Pulumi doesn’t do everything at a high level. Figuring out how many resources you have in AWS is hard enough even with the current implementation.

[nsonha]

just another reminder that teraform has a CDK. Everything has a CDK these days, at the end of the day the decision comes to your position on vendor lock-in/multicloud, and quality of the CDK. The fact that AWS/Pulumi have imperative CDKs is not that intersting

[fitzoh]

>Not to mention, CloudFormation actually allows ~transactions, which is something you can't really get without cooperation from the cloud provider (terraform and pulumi both use cloudformation on AWS for exactly this reason)

Terraform and Pulumi use Cloudformation?

[habitue]

Sorry, I was mistaken about this. I was under the impression terraform would create transactions with cloudformation, but it only does this if you manually create cloudformation resources.

[dastbe]

aws recently launched cloud control, which more or less decouples the individual resource management aspect of cloudformation from everything else. providers like terraform/pulumi can use it in lieu of manual integrations with every aws api.