Forget CDK and AWS's insane costs. Pulumi and DigitalOcean to the rescue

Re:Forget CDK and AWS's insane costs. Pulumi and DigitalOcea... by x0x0 on Wednesday November 06, 2024 @09:30PM (#42072689)

I also had a really rough go with cdk. I personally found the lack of upsert functionality -- you can't use a resource if it exists or create if it doesn't -- to make it way more effort than I felt was useful. Plus a lack of useful error messages... maybe I'm dumb, but I can't recommend it to small companies.

[ Parent | on HN ]

Re:Forget CDK and AWS's insane costs. Pulumi and DigitalOcea... by otterley on Thursday November 07, 2024 @12:28PM (#42078778)

Upserting resources is an antipattern in cloud resource management. The idiom that works best is to declare all the resources you use and own their lifecycle from cradle to grave.

The problem with upserting is that if the resource already exists, its existing attributes and behavior might be incompatible with the state you're declaring. And it's impossible to devise a general solution that safely transitions an arbitrary resource from state A to state A' in a way that is sure to honor your intent.

[ Parent | on HN ]

Re:Forget CDK and AWS's insane costs. Pulumi and DigitalOcea... by x0x0 on Thursday November 07, 2024 @02:20PM (#42079905)

Hmm.

If you don't mind sharing, suppose (because it's what I was doing) I was trying to create personal dev, staging, and prod environments. I want the usual suspects: templated entries in route53, a load balancer, a database, some Fargate, etc.

What are you meant to do here? Thank you.

[ Parent | on HN ]

Re:Forget CDK and AWS's insane costs. Pulumi and DigitalOcea... by otterley on Thursday November 07, 2024 @04:17PM (#42081144)

If they're all meant to look alike, you'd deploy the stack (or app, in CDK parlance) into your dev, staging, and prod accounts. You'd get the same results in each.

[ Parent | on HN ]