Hacker News Reader

Comment by t34543 | Hacker News Reader

I prefer cloudformation

My biggest issue with CloudFormation is that it absolutely refused to start managing any resource it didn't create. "terraform import" is clumsy but better than nothing.

I always thought CloudFormation was also less extensible, but it looks like they have Lambda-based macros now, which might actually be less hassle than writing gRPC plugin servers for Terraform.

Now I need to look up how to extend Pulumi. I'm reluctant to use anything that will require generating a lot of Go code.

If you create resources outside of terraform/CF your doing it wrong. This is a feature, not a bug.

That's a beautiful statement of purity, but my reality has been different. Even with the best of intensions sometimes resources are created outside of an IaC solution and you want to bring them in.

On the other hand I hear that CF's rollback is better at not leaving things in a busted state.

This. It takes years to learn good architecture, and Cloudformation nudges you to make it right. Thats why you need senior infrastructure engineers.

This is 100% unrelated to “senior infrastructure engineers” (most of whom I’ve seen end up building pure crap), and import is simply a matter of practicality.

If we followed the (patently poor) advice above, CF users would not have been able to use NAT Gateways - to take one of several prominent examples - for many months following their launch. Terraform was substantially faster to support them, but being able to import resources created outside the normal mechanism for _any_ reason is an essential part of any IaC tool.

> If you create resources outside of terraform/CF your doing it wrong.

But at least you're doing it!

There are sometimes holes in Terraform coverage.

We don't seem to have used Terraform for everything since day one. Even if we had, we can't migrate to CloudFormation without abandoning our Terraform-created datastores and live-migrating to new ones. (Not that we necessarily want to, at this point.)

Always Outnumbered, Never Outgunned. Respect, man.

And outside of AWS?

Terraform supports multiple vendors, but your templates are not vendor-neutral, you have to rewrite them all. I don't see it as that big a win over using each vendor's native tools, as long as they all support a config managed in git.

With terraform, I at least only have to learn one syntax, so there’s at least that, if noting else.

Which does little good if you still have to learn the provisioner, the terminology and the idiosyncrasies of the platform.

And good luck using your business support plan with AWS when something goes wonky and you’re using Terraform.

It does plenty of good. I have software that spans AWS, Azure, and GCP (don't ask me why). I can easily manage it as a cohesive whole, e.g. using an ip address provisioned in GCP as the target of a DNS record provisioned in AWS. I can spin it all up in a single call to a single tool.

Under the hood, terraform is just using the AWS APIs. If an error occurs with them, getting support isn't an issue.

Reply on news.ycombinator.com