[shironandon]

I have actively used Vagrant, Consul, Terraform, and Vault and I really have never understood all the fanboyism for Hashicorp. Their products are OK but easily replaceable and often redundant in modern cloud providers. Wish them luck on their attempt to cash in but I for one do not intend to buy any stock.

[jhugo]

I actually tend to agree, and am surprised that the discussion in this post is so breathless. Having used (and continuing to use) multiple Hashicorp products fairly extensively, they tend to have a lot of warts, just fewer warts than the alternatives.

Terraform is a great example:

* It's slow, and new versions often get slower.

* Apart from the most serious ones, bugs often don't get fixed for years, and GitHub issues and pull requests (both for TF itself and the biggest providers) are a swamp of thousands of issues and hundreds of PRs dating back 4+ years. Issue triage is erratic and often fails to fully read or comprehend the reported issue.

* There are some design deficiencies that seem hard to fix. For example: first-class support for providers that are configured based on other resources in the same Terraform state. This usually doesn't work correctly without hacks like `-target`. The "right way" to do this is to have separate TF states for different "layers" of your infra, which is fine and ends up pretty tidy for large infra, but nobody really talks about this (not even the TF docs), so invariably things will not be architected that way at the start and by the time the TF config has grown, refactoring it to split out the layers will be a deeply unpleasant time-suck. (The awful experience that is refactoring large TF configs being another major negative all by itself.) This fundamental issue is the root cause of hundreds of TF GitHub issues.

* The major Hashicorp-maintained (or co-maintained) providers are often massively underresourced, leading to delays before new cloud features are supported, forcing users of TF to maintain those resources outside of Terraform, which is a mess. If a user of, say, the AWS provider tries to rectify the situation by sending a PR, it will just be lost in the sea of ~3000 open issues and ~500 open PRs unless they put in significant time and effort to get attention to it.

Despite all of this, we still use Terraform heavily because it's less crap than the alternatives, but I can hardly muster the love for it that is expressed elsewhere in these comments.

[kosinus]

What's slow in your opinion? I assume it's either config evaluation or the state refresh?

[jhugo]

No, state refresh is justifiably slow, it's a lot of API calls, which can only be done so quickly, and it can be skipped (with care) if desired.

Once you eliminate that with `-refresh=false` most of the time is taken building the graph. For our largest config that can take almost 5 minutes for each run, and throwing hardware at it doesn't really help; it doesn't seem to make much use of more than one core. Some TF version updates improve it, but more often the performance gets worse.

Recent relevant issues:

https://github.com/hashicorp/terraform/issues/27523 https://github.com/hashicorp/terraform/issues/26355

[bklyn11201]

terraform plan -out takes a few minutes with a few hundred AWS objects in place. I imagine it takes quite a bit longer for a complex organization.

[t_sawyer]

Vault is only replaceable in cloud. Idk of any on-prem products that have anywhere near Vaults functionality.

[nodesocket]

You are missing the point. They are the de-facto standard in DevOps tooling from one person startups to gigantic public tech FAANG companies.

My prediction, HashiCorp after IPO'ing will get acquired.

[throwdbaaway]

Judging by https://github.com/hashicorp/vagrant/issues/7263, I would say that they are the "GNOME" of devops tooling. The quickstart is great, and you feel empowered when your use cases are supported. Beyond that, good luck.

[nuker]

> They are the de-facto standard in DevOps tooling

Im in cloud automation 8+ years. No they are not de-facto standard. For AWS projects, I much prefer Cloudformation. App devs use venv or similar, not Vagrant.

I’d use their CI/CD if they had one, like GitLab, but looks like they don’t?

[stevekemp]

I've used terraform in 50% of my jobs over recent years.

But even in the companies where I've used AWS and cloudformation we still use Hashicorp tooling. For example we use cloudformation at the current company to handle our AWS infrastructure, but the AMIs launched are generated with packer.

[antoinealb]

Which FAANG is public about using one of those?

[1991g]

Apple, mentioning Vagrant: https://jobs.apple.com/en-us/details/200251910/site-reliabil...

I could probably find more, but many (most?) large tech companies use one or more of the Hashicorp suite. I don't think it's unfair to say that they are the standard toolset for certain roles.

[viewfromafar]

It is true that tools can be emulated (RedHat doing podman as a docker replacement, with same flags) but it is also work. I wonder whether in the Cloud world, the fan factor is a sign of credibility in a market that is looking for tooling that works across cloud providers.