Live data from Hacker News

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

github.com

81–90 of 172 posts

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

#81

Pulumi is really a royal piece of shit. Why the f*ck am I writing code to do "deployment". In C# --> new Dictionary when dealing with a values.yaml for instance. The whole need to figure out when and when not to use Apply. Give me Terraform (as much as I hate it) any day.

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.

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

#82
post #79

Earlier quoted context omitted.

Because you can use that to interface with existing tooling. Terraform has a huge and established ecosystem and it’s an uphill battle to compete with it. It’s risky to bet your infra on a tech that tries to drink the ocean and supplant the entire thing. Meanwhile if you compile down to TF you get to use a different language without having to pay the cost of moving out of the tf ecosystem. And given that the language…

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

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

#83

Earlier quoted context omitted.

Why are people templating yaml for terraform like they templated html in php in 1996?

Because it works fine, and is also used in for other things like Helm Charts? https://helm.sh/docs/chart_template_guide/control_structures...

Helm charts are a horrible example of text based templating.

You have YAML/JSON that k8s API wants, that is fed through helm which is fed through helmsman or whatever newer thing. There might be a layer or two of other templating around. Sometimes companies have built systems so developers/devops don't even have the ability to see what the final compiled version of the template is which is like the mother of all: "works on my laptop" problems.

It's super easy to break text based templating because of some space, tab, string escaping or whatever.

YAML makes it worse as there are lots of gotchas and different ways of doing. JSON, being quite verbose and inflexible at least has strong structure right in your face so it's a bit easier to figure out what went wrong.

With a proper programming language data structure you can be much better with verifying that the things you add or remove or iterate over will produce a valid result, much better refactoring and working as a team independently.

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

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

> Why's everyone going away from declarative?

If I had to guess it's because

- more imperative background developers need to work with infrastructure and they bring over their mindset and ways of working

- infrastructure is more and more available through API's and it saves a lot of effort to dynamically iterate over cattle than declaratively deal with pets

- things like conditionals, loops and abstractions are very useful for a reason

- in essence the declarative tools are not flexible enough for many use cases or ways of working, using a programming language brings infinite flexibility

Personally I am more in the declarative camp and see the benefits of it, but there is certain amount of banging ones head against it's rigidity.

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

#85

Earlier quoted context omitted.

> Give me Terraform (as much as I hate it) any day Terraform sure is a quirky little DSL ain’t it? It’s so weirdly verbose. But at the same time I can create some azure function app, setup my GitHub build pipeline, get auth0 happy and in theory hook up parts of stripe all in one system. All those random diverse API’s plumbed together and somehow it manages to work. But boy howdy is that language weird.

I haven't used Terraform in years (because I changed jobs, not because of the tech itself), but back in the day v0.12 solved most of my gripes. I have always wished they'd implement a better "if" syntax for blocks, because the language itself pseudo-supports it: https://github.com/hashicorp/terraform/issues/21512 But yeah, at $previous_job, Terraform enabled some really fantastic cross-SaaS integrations. Stuff like s…

I get around most of the if stuff using "for each" to iterate over a map. That map might be config (usually from the hiera data provider) or the output of another deployment. It's not generally a very flexible "if" that you need most of the time, it's more like "if this thing exists then create an X for it", or "while crafting X turn this doohickey on of that data set has this flap", which can be accomplished my munging together days with a locals var for loop (which support if statements).

Honestly, I only use terraform with hiera now, so I pretty much only write generic and reusable "wrapper" modules that accept a single block of data from Hiera via var.config. I can use this to wrap any 3rd party module, and even wrote a simple script to wrap any module by pointing at its git project.

That probably scares the shit out of folks who do the right thing, and use a bunch of vars with types and defaults. But it's so extremely flexible and it neutered all of the usual complexity and hassle I had writing terraform. I have single handedly deployed an entire infrastructure via terraform like this, from DNS domains up through networking, k8s clusters, helm charts and monitoring stack (and a heap of other AWS services like API Gateway, SQS, SES etc). The beauty of removing all of the data out to Hiera is that I can deploy new infra to a new region in about an 2 hours, or deploy a new environment to an existing region in about 10 minutes. All of that time is just waiting for AWS to spin things up. All I have to do in code is literally "cp -a eu-west-1/production eu-west-2/production" and then let all of the "stacks" under that directory tree deploy. Zero code changes, zero name clashes, one man band.

The hardest part is sticking rigidly to naming conventions and choosing good ones. That might seem hard because cloud resources can have different naming rules or uniqueness requirements. But when you build all of your names from a small collection of hiera vars like "%{product}-%{env}-%{region}-uploads", you end up with something truly reusable across any region, environment and product.

I'm pretty sure there's no chance I'd be able to do this with Pulumi.

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

#86

I wish CDK was fully baked enough to actually use. It's still missing coverage for some AWS services (sometimes you have to do things in cloudformation, which sucks) and integrating existing infra doesn't work consistently. Oh and it creates cloudformation stacks behind the scenes and makes for troubleshooting hell.

CDK is an abomination and I'm not sure why AWS is pushing it now. A few years ago all their Quick Starts were written in CloudFormation, now it's CDK that compiles to CloudFormation. Truly a bad idea. Just write CloudFormation directly. Once you get the hang of the declarative style and become aware of the small gotchas, it's pretty comfy.

[deleted]

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

#87

Controversial opinion here: just use CDK. Learn cloud formation for advanced stuff. It’s really not that hard and pays dividends

CDK is a second class citizen, it is missing implementations for many services and features. CDK was DOA as it should have been a requirement that when AWS added something to terraform it needed to be added to CDK as well.

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

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

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

#89
post #68

Earlier quoted context omitted.

Or need a good amount of ram. Which should be really cheap these days.

My life on AWS the last five or so years really would have been a lot simpler if every new generation of EC2 servers didn't have the exact same ratio of RAM to cores.

At this point the memory:vcpu ratio is the defining characteristic of main general purpose C/M/R series, I'd think it would be pretty disrupting to change that significantly anymore. And they got also the special extra-high memory X series available. I would say ec2 is pretty flexible in this regard, you have options for 2/4/8/16/32 gigabytes per vcpu. It's mostly problem if you need even less memory than what C series provide, or need some special features.

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

#90

Pulumi is really a royal piece of shit. Why the f*ck am I writing code to do "deployment". In C# --> new Dictionary when dealing with a values.yaml for instance. The whole need to figure out when and when not to use Apply. Give me Terraform (as much as I hate it) any day.

Tried Pulumi thinking "it's gonna abstract all the k8s specifics". Welp no, still need to know and understand K8s so I still don't see the value from those kind of tools. In which case why not use something like Pkl to generate my yaml from some sensible code-like structures?
Post reply on HN