> Picking Terraform over Cloudformation: Endorse

I, too, prefer McDonald's cheeseburgers to ground glass mixed with rusty nails. It's not so much that I love Terraform (spelled OpenTofu) as that it's far and away the least bad tool I've used in the space.

▲

orwin 7 hours ago | parent | next [-]

Terraform/openTofu is more than OK. The fact that you can use to to configure your Cisco products as well as AWS is honestly great for us. It's also a bit like ansible: if you don't manage it carefully and try to separate as much as possible early, it starts bloating, so you have to curate early.

Terragrunt is the only sane way to deploy terraform/openTofu in a professional environment though.

	▲	xorcist 2 hours ago \| parent \| next [-]
		I never understood this. Why not use Ansible instead, especially if you already use it? Doubly so when you have Cisco config to manage. The experience is generally so much better it's not comparable, and it is much easier to infer running state.
	▲	kstrauser 4 hours ago \| parent \| prev \| next [-]
		I curse at Terraform at least once a week, usually right after I’ve discovered some weird arbitrary limitation surprising misfeature. It’s still what I reach for when I need to manage a whole organization. And compared to CloudFormation, it’s the freaking Cistine Chapel of IaC.
	▲	MrDarcy 5 hours ago \| parent \| prev [-]
		We can also use expect to configure Cisco routers and AWS infrastructure, doesn’t mean we should.

▲

walt_grata 7 hours ago | parent | prev | next [-]

I've been very happy using cdk for interacting with aws. Much better than terraform and the like.

	▲	etothet 5 hours ago \| parent [-]
		I second this. I do use some terraform, but for most of our stacks, CDK has been fantastic.

▲

MrDarcy 5 hours ago | parent | prev | next [-]

CDK is far better than Terraform.

▲

jauntywundrkind 4 hours ago | parent [-]

If you're any good at all at CDK, it's cdk8s is also a very solid clear & clean way to do kubernetes too. https://cdk8s.io/

I'm trying to make the decision for where to go with my home lab, and while Pulumi and Cue look neat, cdk8s seems so predictable & has such clear structure & form to it.

That's said the l1/l2/l3 distinction can be a brute to deal with. There's significant hidden complexity there.

	▲	shepherdjerred 4 hours ago \| parent [-]
		I use cdk8s for my homelab and absolutely love it. 100% recommend. Homelab CDKs: https://github.com/shepherdjerred/monorepo/tree/main/package... Script I wrote to generate types from Helm charts: https://github.com/shepherdjerred/monorepo/tree/main/package...

▲

nine_k 7 hours ago | parent | prev | next [-]

Any opinion on Pulumi?

▲

gouggoug 7 hours ago | parent | next [-]

Not an opinion on Pulumi specifically, but an opinion on using imperative programming languages for infrastructure configuration: don't do it. (This includes using things like CDKTF)

Infrastructure needs to be consistent, intuitive and reproducible. Imperative languages are too unconstrained. Particularly, they allow you to write code whose output is unpredictable (for example, it'd be easy to write code that creates a resources based on the current time of day...).

With infrastructure, you want predictability and reproducibility. You want to focus more on writing _what_ your infra should look like, less _how_ to get there.

▲

nothrabannosir 3 hours ago | parent | next [-]

Couldn't disagree more.

I have written both TF and then CDKTF extensively (!), and I am absolutely never going back to raw TF. TF vs CDKTF isn't declarative vs imperative, it's "anemic untyped slow feedback mess" vs "strong typesystem, expressive builtins and LSP". You can build things in CDKTF that are humanly intractable in raw TF and it requires far less discipline, not more, to keep it from becoming an unmaintainable mess. Having a typechecker for your providers is a "cannot unsee" experience. As is being able to use for loops and defining functions.

That being said, would I have preferred a CDKTF in Haskell, or a typed Nix dialect? Hell yes. CDKTF was awful, it was just the least bad thing around. Just like TF itself, in a way.

But I have little problems with HCL as a compilation target. Rich ecosystem and the abstractions seem sensible. Maybe that's Stockholm syndrome? Ironically, CDKTF has made me stop hating TF :)

Now that Hashicorp put the kibosh on CDKTF though, the question is: where next...

▲

kstrauser 4 hours ago | parent | prev | next [-]

Thanks for saving me the trouble of writing exactly that. I want my IaC to be roughly as Turing complete as JSOJ. It’s sooo tempting to say “if only I could write this part with a for loop…” and down that path lies madness.

There are things I think Terraform could do to improve its declarative specs without violating the spirit. Yet, I still prefer it as-is to any imperative alternatives.

▲

vanviegen 4 hours ago | parent | prev | next [-]

> Particularly, they allow you to write code whose output is unpredictable

Is that an easy mistake to make and a hard one to recover from, in your experience?

The way you have to bend over backwards in Terraform just to instantiate a thing multiple times based on some data really annoys me..

	▲	gouggoug 2 hours ago \| parent [-]
		> Is that an easy mistake to make and a hard one to recover from, in your experience? If you're alone in a codebase? Probably not. In a company with many contributors of varying degrees of competence (from your new grad to your incompetent senior staff), yes. In large repositories, without extremely diligent reviewers, it's impossible to prevent developers from creating the most convoluted anti-patterny spaghetti code, that will get copy/pasted ad nauseam across your codebase. Terraform as a tool and HCL as a programming language leave a lot to be desire (in hindsight only, because, let's be honest, it's been a boon for automation), but their constrained nature makes it easier to reign in the zealous junior developer who just discovered OOP and insists on trying it everywhere...

▲

popalchemist 6 hours ago | parent | prev [-]

yes. IaC is a misnomer. IaC implementations should have a spec (some kind of document) as the source of truth; not code.

▲

x3n0ph3n3 6 hours ago | parent | prev | next [-]

My opinion is there are not enough good software developers doing DevOps, and HCL is simple enough and can have pretty good guardrails on it. My biggest concern is people shooting themselves in the foot because the static analysis tools available for HCL don't work with Pulumi.

	▲	SlightlyLeftPad 5 hours ago \| parent [-]
		It’s an unfortunate truth that good software developers aren’t crazy enough to want to do it.

▲

orthecreedence 4 hours ago | parent | prev [-]

Pulumi is superior to Terraform for my use cases. It's actually Infrastructure as Code. Terraform pretends to be, but uses a horrible config language that tries to skirt the line between programming language and config spec, and skirts it horribly. Reorganizing modules is a huge pain. I dreaded using Terraform and I spin things up and down in Pulumi all day. No contest.

Granted, I'm a programmer, have been for a long time, so using programming tools is a no brainer for me. If someone wants to manage infra but doesn't have programming skills, then learning the Terraform config language is a great idea. Just kidding, it's going to be just as confusing and obnoxious as learning the basic skills you need in python/js to get up and running with Pulumi.

	▲	kstrauser 4 hours ago \| parent [-]
		I disagree with that. I think it’s satisfying to find a way to express my intent in HCL, and I don’t think I could do it as well without a strong programming background.

▲

easterncalculus 7 hours ago | parent | prev [-]

You can honestly do a lot of what people do with Terraform now just using Docker and Ansible. I'm surprised more people don't try to. Most clouds are supported, even private clouds and stuff like MAAS.

▲

x3n0ph3n3 6 hours ago | parent [-]

Yeah, but ansible is one of the nine circles of hell and its support for various AWS services beyond EC2 and S3 is near nonexistant.

▲

Tostino 4 hours ago | parent [-]

I have mixed feelings about it. On my first startup, I used ansible to automate all of the manual workflows and server setup that we had done. Everything was just completely manual and in people's heads before, and translating it to ansible was a pain in the ass to say the least. I don't think it would have been any easier to translate it to something else though. It ended up working fine and we had a solid system that I could reset up our environment from scratch on a set of VPS provided by some terraform scripts. We were originally on digitalocean, and had to migrate to Azure because of acquisition BS.

For my current startup I ended up not going a direction where I needed ansible. I've now got everything in helm charts and deployable to K8S clusters, and packaged with Dockerfiles. Not really missing ansible, but not exactly in love with K8S either. It works well enough I guess.

	▲	SkiFire13 3 hours ago \| parent [-]
		> on a set of VPS provided by some terraform scripts You ended up needing Terraform too for the infrastructure though. At that point why not just use Terraform?