Live data from Hacker News

Release of AWS CDKv2 and Construct Hub

aws.amazon.com

11–20 of 44 posts

Re: Release of AWS CDKv2 and Construct Hub

#11
post #9

Honestly, always surprised I don't see more about CDK. As far as I am concerned, this is the future of software development. Object oriented infrastructure, where you create abstractions over pieces of infrastructure, put them into a library, and then use them as composable components is incredibly powerful. We are just scratching the surface, and through libraries like constructs, large swaths of development will be…

It would be even better if most of your new features were actually supported by CloudFormation.

I wish I could upvote this more - if I can’t do it in CloudFormation I won’t use it.

Re: Release of AWS CDKv2 and Construct Hub

#13
post #2

Why should one use CDK vs Pulumi?

In my experience CDK has much nicer documentation. It also has a lot of high-level constructs, e.g. I can very easily say give me an EC2 instance on the public internet, whereas with pulumi you have to set up all of the security groups, vpc, internet gateway, etc.

Re: Release of AWS CDKv2 and Construct Hub

#15
post #10

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 secrets…

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

Re: Release of AWS CDKv2 and Construct Hub

#16
post #10

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 secrets…

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

Re: Release of AWS CDKv2 and Construct Hub

#17
CDK is absolutely brilliant. My eyes glaze over when I see lines and lines and pages and pages of CloudFormation/Terraform config... sometimes spread over multiple files and having to manually join them in them head to get the full view of the infrastructure.

But CDK reads so beautifully and gets rid of so much noise in these templates that I don't care about. Unfortunately... the devops people and those who hold they keys to cloud resources at my current company (and many other companies) are so all in on Terraform that most won't even consider CDK/Pulumi as an option despite the CDK/Pulumi paradigm being objectively better than CloudFormation/Terrform paradigm.

Re: Release of AWS CDKv2 and Construct Hub

#18
post #15
post #10

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 secrets…

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

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.

Re: Release of AWS CDKv2 and Construct Hub

#19
post #2

Why should one use CDK vs Pulumi?

Pulumi's biggest benefit is if you want to manage resources outside of AWS. There are providers for Azure, GCP, GitHub, Postgres, Datadog, etc.

It's also nice if you want to be able to manage resources in multiple AWS regions or accounts from a single stack.

Re: Release of AWS CDKv2 and Construct Hub

#20
post #2

Why should one use CDK vs Pulumi?

I have a few years of experience with terraform (pulumi is built on terraform), and moved to a place using CDK about a year ago. From what I've seen, CDK is worse than terraform, and I would expect it to be strictly worse than pulumi. I haven't seen a problem that CDK solves better than terraform, and it fails pretty hard at the core of its job. I genuinely want to find something to like (because I'm stuck with it), but I'm really struggling.

CDK is bad at the core of its job; managing the state of resources in AWS. The two big ways this manifests with CDK are that you can't completely import existing resources into CDK, and CDK is bad at detecting changes made out-of-band.

CDK has a way to "import" resources, but unlike terraform, it's not something you do once then forget about. When you "import" a resource in CDK you are doing that as an alternative way to define the resource, so the code will always need to 'remember' which resources to create and which ones to import. Imported resources can be modified, but there are restrictions on what modifications can be made so they aren't really interchangeable with native cdk built resources. Our CDK stacks are littered with "if STAGE" blocks that will never go away until we recreate those resources with CDK, and there is no clean way to do that.

In general I would say making changes to CDK/terraform created resources out-of-band (ie, in the aws console) is a bad idea, but it happens sometimes. Maybe you aren't exactly sure how a parameter maps to a feature in the aws console, or there is an active outage and you need to make the change now, or the guy in IT that owns the root account decided to "fix" something for you. Whatever the cause, it's important to be able to run your IaC tool and 1) see the changes, 2) remediate them. CDK can detect some changes but not everything, and that's left me with very little confidence that things are actually setup correctly. No one's complaining, so I guess it's fine?

There are a few other quality-of-life things I don't like about CDK, but I don't think they are as important. It's slow. I don't like the diff output format. We always see diffs and different devs see different diffs, and we have no way to debug/resolve it. I'm boggled that a bunch of resource types (it's not clear which ones) default to not being deleted when you delete them from cdk. Overall, I get the feeling that "it works" and "no one's complaining" is the quality bar CDK is trying to meet, and that just isn't good enough for me.

The only reason I don't say terraform is strictly better than CDK is that terraform doesn't allow you to define your infrastructure with a 'real' programming language. I don't think that's an important feature, and it might tempt you into doing horrible things (like littering your codebase with "if STAGE" blocks). In general I think keeping infrastructure stuff simple and separate from application stuff is important, and HCL really encourages that. I've been bothered by the lack of programable logic in terraform, but honestly, I think that constraint has ultimately resulted in cleaner logic. If it's important to you, then pulumi is always there.

Ugh, I took way to long writing this. To answer your question, IMHO, don't use CDK.

Post reply on HN