4 ms·

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

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.

nodesocket 5y ago
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.
- antoinealb 5y ago
  Which FAANG is public about using one of those?
  - 1991g 5y ago
    Apple, mentioning Vagrant: https://jobs.apple.com/en-us/details/200251910/site-reliability-engineer-sre 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.
- nuker 5y ago
  > 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 5y ago
    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.
- throwdbaaway 5y ago
  Judging by https://github.com/hashicorp/vagrant/issues/7263 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.
t_sawyer 5y ago
Vault is only replaceable in cloud. Idk of any on-prem products that have anywhere near Vaults functionality.
viewfromafar 5y ago
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.
jhugo 5y ago
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 5y ago
  What's slow in your opinion? I assume it's either config evaluation or the state refresh?
  - bklyn11201 5y ago
    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.

nodesocket 5y ago

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.

antoinealb 5y ago
Which FAANG is public about using one of those?
- 1991g 5y ago
  Apple, mentioning Vagrant: https://jobs.apple.com/en-us/details/200251910/site-reliability-engineer-sre 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.
nuker 5y ago
> 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 5y ago
  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.
throwdbaaway 5y ago
Judging by https://github.com/hashicorp/vagrant/issues/7263 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.

t_sawyer 5y ago

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

viewfromafar 5y ago

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.

jhugo 5y ago

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 5y ago
What's slow in your opinion? I assume it's either config evaluation or the state refresh?
- bklyn11201 5y ago
  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.