Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Release of AWS CDKv2 and Construct Hub

aws.amazon.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Release of AWS CDKv2 and Construct Hub

#21

Post by throwaway894345 »

habitue wrote: 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 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

Re: Release of AWS CDKv2 and Construct Hub

#22

Post by habitue »

fitzoh wrote: post #15
habitue wrote: 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?

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.

Re: Release of AWS CDKv2 and Construct Hub

#23

Post by taeric »

fdgsdfogijq wrote: post #8
taeric wrote: post #7

Earlier quoted context omitted.

I guess the main question I have is what makes this different from any other abstraction? Specifically, is this that much better than a ton of vm orchestration that has existed for a while? I'm also concerned about it throwing out the lines of infrastructure lifecycle versus software lifecycle. Runs heavily afoul of the common mono repo criticism that, just because you can commit the infra update with the software, d…

"Runs heavily afoul of the common mono repo criticism that, just because you can commit the infra update with the software, does not mean they magically deploy together." Yeah funny you mention this, as the idea of vending infra resources as a common package runs into the issue of how to know if every consumer will be able to successfully ingest updates. From there you have the issue of "blast radius", how to handle…

The amount of tooling needed is impressive.

But my concern was more in the teams that try and get it all into one code source and pipeline.

Don't get me wrong. One team having to deal with dozens of deployment orchestrations is a straw man just as much as the complication that would be forced into a single pipeline. I would love finding that sweet spot without too much swinging between the fires.

Re: Release of AWS CDKv2 and Construct Hub

#24

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

Re: Release of AWS CDKv2 and Construct Hub

#25

Post by jaxxstorm »

cconstantine wrote: post #20
manojlds wrote: 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),…

Pulumi isn't "built on terraform", that's a common misconception. See here: https://www.leebriggs.co.uk/blog/2021/11/06/pulumi-faqs.html

Re: Release of AWS CDKv2 and Construct Hub

#26

Post by cconstantine »

jaxxstorm wrote: post #25
cconstantine wrote: post #20

Earlier quoted context omitted.

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),…

Pulumi isn't "built on terraform", that's a common misconception. See here: https://www.leebriggs.co.uk/blog/2021/11/06/pulumi-faqs.html

Thanks for the correction! I've never used Pulumi directly, and thought it was just a wrapper around terraform providers.

Do you think it changes anything about how I've characterized it above?

Re: Release of AWS CDKv2 and Construct Hub

#27

Post by ldoughty »

habitue wrote: 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…

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.

Re: Release of AWS CDKv2 and Construct Hub

#28

Post by ldoughty »

oneplane wrote: post #24

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…

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

Re: Release of AWS CDKv2 and Construct Hub

#29

Post by cconstantine »

ldoughty wrote: post #28
oneplane wrote: post #24

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…

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

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.

Post reply on HN