Live data from Hacker News

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

github.com

111–120 of 172 posts

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

#111

Earlier quoted context omitted.

Honestly curious, I've been writing terraform for a while but I have never heard of "The three colors of variable thing". Could you expand on that?

They mean var vs local vs from-a-resource. There are some places you can’t use some types of variables. It can be annoying but it’s not really a huge problem if you design your approach with that in mind. The worst part is that the Terraform team at Hashicorp often excuse not fixing these design issues as “safety measures” which isn’t entirely untrue but when over half of your users want something, sometimes you shou…

That makes sense I guess, I just never considered locals or data resources as variables.

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

#112
post #63

Earlier quoted context omitted.

As SRE dealing with former Pulumi, "Hey Devs can use code to deploy infrastructure" is not great idea you think it is. I've seen some real ugly conditional behavior where I'm like "Is this or is this not going to run? I honestly can't tell."

We had so much conflict with the ops team over their choice of Terraform. The three colors of variable thing is just fucking bonkers. Getting tests wrapped around it that actually did what we thought they meant was a giant pain in the ass. I won't go as far as to say we burned bridges arguing back and forth about it but they were definitely significantly singed. Config files simply don't work until they do. And if it…

Honestly, the culture/org structure is a way bigger problem in this story than any proper noun tool.

If you’re ignoring guidance and patterns and getting mad reinventing the wheel, that’s on dev. If “ops” mandates tooling and doesn’t have any skin in the game, that’s on them. And both problems are on your leadership.

If y’all just hate each other and don’t listen or participate, then you can’t be successful. It is ironic that this is the pattern that the devops movement landed us in.

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

#113
post #82
post #79

Earlier quoted context omitted.

Makes sense! Except for one little thing.. We've been migrating off of Terraform at BigCo recently and it has been a tremendous success. The migration has saved countless hours. Before, I was jaded and routinely in the office until 8 or 9 or so manually running terraform deploys for our engineering teams in India. Now, thanks to Pulumi, I'm able to leave the office at 7:30-8 -- and I can tell you single handed that t…

Thanks for sharing your story it sounds like you had a really rough time of Terraform. I don't have much experience running Terraform at scale. What has Pulumi made easier? Why is looping a bottleneck in infrastructure code? Based on the info I can glean from this story you may be working at a scale / use case that may be too big or a poor fit for Terraform but I'm not sure...

I think he's kidding... there's no C CDK:

https://www.pulumi.com/docs/iac/languages-sdks/

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

#114
post #98

Hetzner has been our "expensive AWS cloud costs" saviour We've also started switching our custom Docker compose + SSL GitHub Action deployments to use Kamal [1] to take advantage of its nicer remote monitoring features [1] https://kamal-deploy.org

I’ve been pretty happy with something like Docker Compose or Docker Swarm and Portainer, but honestly it’s nice that there are other alternatives that strive for something manageable and not too complex!

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

#115
post #81

Earlier quoted context omitted.

As SRE dealing with former Pulumi, "Hey Devs can use code to deploy infrastructure" is not great idea you think it is. I've seen some real ugly conditional behavior where I'm like "Is this or is this not going to run? I honestly can't tell."

Seconded, as someone that really does developer / operations, depending on the project assignment, I have learned the hard way that infrastructure configuration code should be as declarative as possible. Sure "use code to deploy infrastructure" sounds great, and that is why we get stuff like Ant, Gradle, Pulumi, Jenkins Groovy scripts, .NET Aspire,.... until someone has to debug spaghetti code on a broken deployment.

On the flip side dsl declarative stuff is obfuscated magic that you can't step through or drive into.

a dsl like SQL involves one basic substrate (data organized in tables) that you can compile in your head. But declarative infra as code involves a thousand different things across a dozen different clouds.

Declarative will hold off spaghetti for... A bit. But it devolves to spaghetti as well (think fine grained acls, or places where order of operations, which the dsl does not specify and is magically resolved, becomes ambiguous).

And if you need to go off the reservation (dsl support doesn't exist or is immature for rapidly evolving platforms, need some custom postprocess steps) then you are... What?

Probably writing code and scripts to autoinvoke on the new node, phone home to a central.... Yup that's code.

Finally, declarative code has an implicit execution loop. But for something like iac that is a very complicated, the execution loop that isn't well documented. And some committed changes to declarative code May trigger a destructive pass followed by a possibly broken constructive phase.

It's a tough problem.

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

#116

Earlier quoted context omitted.

Keep an eye on reachability and performance. I’ve seen DO consistently perform terribly and/or drop connections for months (that is, didn’t look like some brief routing glitch somewhere) for some US and Canadian routes (not, like, Sri Lanka or something) on excellent Internet connections. The fix was moving to AWS, problem gone. It felt like a shitty-peering-agreements issue.

How do you monitor the connection quality?

From the client side. You can’t know what it should be like without knowing the client.

I’m sure there are lots of DO clients seeing the same things we did, but not realizing it.

We did see it (multiple DCs—we didn’t just not try to fix this before going to AWS) in multiple cases with tens of clients so if there’s good news it’s that if you can monitor like 100 clients distributed over a wide area and all of them behave as expected you may not be experiencing what we did. What we saw was closer to 5% with absurd slowness or frequently-dropped connections than to 0.01%.

And if you are just operating a website and sticking Cloudflare or whatever in front of DO anyway, this doesn’t matter. I expect that’s why it’s not a more widely-reported issue.

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

#117
post #78

Why's everyone going away from declarative? Terraform, CloudFormation, AWS Copilot etc have a lot of virtues and are programming language agnostic. Using a complex programming language (C++ of the browser world) just for this has a big switching cost. Unless you're all in on TS. And/or have already built a huge complex IaC tower of babel where programming-in-the-large virtues justify it.

Declarative has in-practice meant “programming, but in YAML” more often than not, which is hell. YAML’s not even a good format for static data, and it’s even worse when you try to program in it.

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

#119
post #78

Why's everyone going away from declarative? Terraform, CloudFormation, AWS Copilot etc have a lot of virtues and are programming language agnostic. Using a complex programming language (C++ of the browser world) just for this has a big switching cost. Unless you're all in on TS. And/or have already built a huge complex IaC tower of babel where programming-in-the-large virtues justify it.

A small CDK project is a lot more readable in my opinion. It doesn’t have a ton of yml files where your config is spread out

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

#120

My DO K8S cluster ist bugging me every couple of months to do an upgrade. I am always scared to just run it but moving shit over to a new cluster instead is so much work that I simply gamble on it. AWS ECS is worth over penny

DO's K8S is more equivalent to AWS's EKS offering, so of course ECS which abstracts away pretty much all of the other parts of K8s is going to require less maintenance. It's sort of a false equivalence to say ECS == that solution.

On EKS, you need to do the same version updates with the same amount of terror.

You do pay the extra for the further management to just run containers somewhere!

(you might want to say "every" instead of over, "is" instead of "ist")

Post reply on HN