Hacker News Reader

Comment by scrollaway | Hacker News Reader

The one that springs to mind for me is terraform. We made the decision to use it in production and it is costing us a lot of time and money. It feels like it will continue costing us a lot of time and money for a long time. It 100% feels like alpha software, yet it's being hyped and overhyped by the tech community.

I personally think using it was the right call regardless (the alternatives are worse in the long run), but it's such a massive upfront investment, I couldn't recommend it.

One thing though:

> tools that change their behavior based on files in one of the parent directories

You mean like git? I agree with your general sentiment but you're backing it up very weakly, with essentially irrelevant things. Terminal interactivity is not a bad thing; TUI software is built for humans as well as machines and well behaved components will detect when they are not in a tty.

View on HN

I really want to use terraform but after dealing with the collection of hacks called vagrant I am not so excited to do so. (speaking of randomly merging up parent directories)

> > tools that change their behavior based on files in one of the parent directories

> You mean like git?

In case of interactive tools like git it is something you would expect. But it came to me as a rather huge surprise that if you type "npm install" in a directory where you just unpacked sources, what will actually happen depends on what exists in the PARENT directory. Not to mention writing to the parent directory.

I am not alone in being caught off-guard by this: https://github.com/npm/npm/issues/2896

I'd say this is unacceptable in case of tools that are "make-like".

what's make like about a package manager?

Do you really think that npm doesn't build software using dependency management?

It sure does "build software" but it's primary function is package management. We could call Emacs an email client by the same token. An equivalent of make in js world are Gulp, Grunt etc.

It's an npm convention according to the dependency resolution algorithm, not a flaw. If you have a .git folder in the parent directory you also get different/possibly unexpected behavior. It's not unacceptable if you have read how it works. Both cases are documented.

That seems pretty normal, if I'm in a subdirectory of my project and install a dependency, it makes sense that it would install it in the root of my project where the node_modules/ folder is.

When I use git in a subdirectory of my project, it looks for .git/ up the directory tree until it finds it.

What issues do you have with Terraform? A few people in my org are considering implementing it.

Oh where to start...

The state file is atrocious, a constant source of pain. It is hard to set up in the first place, it is hard to import resources into it, it is hard to rename resources within it.

Sometimes, resources don't canonicalize correctly and will always tell you there's something to modify, even though there isn't. Other times, resources don't destroy properly because you are using some untested settings within them.

"It's alpha software" is the best description I can give. It has a ton of rough edges.

The pros: It's decently fast, and a lot more workable than the alternatives (cloudformation or simply tracking stuff by hand). It supports more than just AWS, including fairly obscure stuff like Cloudflare DNS records. It's conceptually solid.

Don't say no to it outright, but you should know what you are getting into.

That's interesting. These guys tend to have pretty good luck with it - https://segment.com/blog/the-segment-aws-stack/

Seen the article before. It's not wrong - Terraform is pretty great. But it's leaving out the parts where a lot of stuff breaks, behaves in unexpected ways, is missing critical features etc. A lot of engineering time has to be dedicated to terraform if you're going to use it in a serious stack (and it's overkill as just a toy).

I'll keep that in mind. Thanks!

Been using Terraform in anger, and I agree with your statement. It is not for everyone, not yet anyway, but I love using it.

Btw, Terraform 0.7 comes with initial support for import and state manipulation commands.

Thanks for posting this. So it sounds like the main source of frustration is really just the state file? Is that accurate? I have heard this from someone else.

Also you mentioned that Terraform was better than the alternatives. Could I ask what other alternatives you looked at and why you ended up choosing Terraform over them?

The reason I ask is that I am also considering Terraform. However other providers also seem to support more than just AWS and are fast enough.

> and a lot more workable than the alternatives

That is pretty much it right there.

I've yet to see another solution that beats it. Warts and all, it's the best I've seen.

The syntax abstraction of cloud formation alone is worth using terraform for me. The state file I delegate to tearing the infrastructure down. No more.

Use the AWS API and your config management API ( chef ) to manage the state of the systems.

Reply on news.ycombinator.com