Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HashiCorp’s multi-product strategy

foundationinc.co

Post reply on HN
Print view View original

81–90 of 91 posts

Re: HashiCorp’s multi-product strategy

#81

Post by throwaway787544 »

jen20 wrote: post #17
truffdog wrote: post #10

Earlier quoted context omitted.

> The most popular tool in HashiCorp's ecosystem that wasn't written by them was written by a consulting firm who hated HashiCorp's UX Which tool is that? On a related note, Vault has a really excellent API. A joy.

I'm assuming this is Terragrunt, which itself perpetuates all kinds of horrific practices which are absolutely unnecessary if you apply basic software engineering principles to infrastructure as code/config.

Not disagreeing, but you have to create a shit ton of scaffolding to work around TF's lack of useful functionality and painful UX. Terragrunt exists because somebody had to do the same, and then kept adding on "smart" features making it even more overcomplicated.

Re: HashiCorp’s multi-product strategy

#82

Post by mountainriver »

hericium wrote: post #45

Vault is great. But if I were to start learning Terraform now, I'd probably ditch it in favor of Pulumi. Terraform was supposed to make writing DRY easy. It's often more reasonable to copy-paste parts of configuration than to try make it DRY. HashiCorp seems to have the approach of "if something can be hacked around, even in a very convoluted way, we can ignore any feature requests for that thing to be doable in a no…

100% - HCL just isn’t expressive enough to handle complex environments and you end up needing to do very strange things that would have been simple in a general purpose language.

I’ve been using Pulumi over the last year and it’s the best time I’ve ever had provisioning infrastructure. I actually enjoy it now. The automation API is also incredibly powerful, I don’t think the ecosystem has wrapped their heads around it yet.

Re: HashiCorp’s multi-product strategy

#83

Post by busterarm »

dilyevsky wrote: post #70
busterarm wrote: post #62

Earlier quoted context omitted.

Managing 10^5 servers right now with Terragrunt. Can confirm, it's the only way to stay sane. Getting to this point was a learning process though. Probably six solid years of investment now.

From experience terragrunt + atlantis has been much better experience than hashicorp's own terraform enterprise service.

not using terraform enterprise.

Re: HashiCorp’s multi-product strategy

#84

Post by tjr225 »

sidlls wrote: post #34
Axsuul wrote: post #22

Earlier quoted context omitted.

As a counterpoint I manage multiple HashiStack clusters in production with little overhead — it's not a nightmare. I am a Kubernetes refugee and Nomad is such a better experience with batteries included. Nomad now has its own service discovery (along with secure variables coming in 1.4.0) so you won't actually need Consul and Vault anymore. This is perfect for smaller deployments like on a Raspberry Pi.

Are your clusters at the same scale as Robinhood or Roblox? We’re talking many millions of inbound requests per second generating multiples of that on internal service calls. Nomad, Consul and Vault work find at small to medium scales. Sometimes. If things are working really well and there aren’t any real problems on the network. It’s very fragile, though, and tends to shit itself under the slightest bit of abnormal…

Exactly this; I would be knocking on all kinds of wood if you’ve had nothing but success with anything Consul/Vault/raft backed. Either that or beefing up your consul server ec2 instance types as soon as possible.

Re: HashiCorp’s multi-product strategy

#85

Post by EduardoRT »

hericium wrote: post #45

Vault is great. But if I were to start learning Terraform now, I'd probably ditch it in favor of Pulumi. Terraform was supposed to make writing DRY easy. It's often more reasonable to copy-paste parts of configuration than to try make it DRY. HashiCorp seems to have the approach of "if something can be hacked around, even in a very convoluted way, we can ignore any feature requests for that thing to be doable in a no…

I agree that Hashi's approach to Terraform is “if there's a workaround, we won't fix it” I don't see Terraform as hard to use for DRY stuff, we have fully adopted Terraform, we now have 100+ modules that are used in more than 20+ AWS accounts with no major issues, these modules are opinionated and are mostly just plug and play for the teams that use them.

Pulumi is great, but you need to really trust your people to write stuff with Pulumi, in our case most teams can just grab a module, submit a pull-request with the values they want and it gets reviewed by a member of the infrastructure team, if everything looks ok then it's merged and the infra gets deployed/changed.

Even with that simple workflow we have issues with devs misunderstanding some concepts, even devs that have been using Terraform for months, it's not a simple tool to use, I would be worried about them having to use Pulumi for the same things.

It might just be an issue of scale though, we have a gigantic dev team and are riddled with regulations, so Terraform is the perfect fit for us, and again, we don't have DRYness issues, nothing obvious at least.

Re: HashiCorp’s multi-product strategy

#86

Post by hericium »

EduardoRT wrote: post #85
hericium wrote: post #45

Vault is great. But if I were to start learning Terraform now, I'd probably ditch it in favor of Pulumi. Terraform was supposed to make writing DRY easy. It's often more reasonable to copy-paste parts of configuration than to try make it DRY. HashiCorp seems to have the approach of "if something can be hacked around, even in a very convoluted way, we can ignore any feature requests for that thing to be doable in a no…

I agree that Hashi's approach to Terraform is “if there's a workaround, we won't fix it” I don't see Terraform as hard to use for DRY stuff, we have fully adopted Terraform, we now have 100+ modules that are used in more than 20+ AWS accounts with no major issues, these modules are opinionated and are mostly just plug and play for the teams that use them. Pulumi is great, but you need to really trust your people to w…

AWS provider seems to be covering for some of Terraform's shortcomings. Until I was using just AWS, Cloudflare and other widely-used providers the problems weren't that much annoying. After switching to some niche services with not so extensively developed (yet not buggy to my knowledge) provider modules, the whole Terraform experience went sideways.

Those "let's just use silly count or for_each to enable/disable the block" suddenly not always worked for randomish weird reasons requiring digging into TF_LOG=trace logs. Other simple things that you are used to with AWS were not so simple anymore.

DRY writing wasn't an issue with AWS provider but I find it to be an issue with Terraform itself when provider module isn't covering for tf's shortcomings.

Re: HashiCorp’s multi-product strategy

#87

Post by EduardoRT »

hericium wrote: post #86
EduardoRT wrote: post #85

Earlier quoted context omitted.

I agree that Hashi's approach to Terraform is “if there's a workaround, we won't fix it” I don't see Terraform as hard to use for DRY stuff, we have fully adopted Terraform, we now have 100+ modules that are used in more than 20+ AWS accounts with no major issues, these modules are opinionated and are mostly just plug and play for the teams that use them. Pulumi is great, but you need to really trust your people to w…

AWS provider seems to be covering for some of Terraform's shortcomings. Until I was using just AWS, Cloudflare and other widely-used providers the problems weren't that much annoying. After switching to some niche services with not so extensively developed (yet not buggy to my knowledge) provider modules, the whole Terraform experience went sideways. Those "let's just use silly count or for_each to enable/disable the…

Agree, smaller providers are more difficult to work with, hard to draw the line between an issue with the tool or a developer introduced issue though, I do agree that smaller providers tend to be weird, so I think Terraform/Hashi could do a better job at making it easier for developers to create better/more reliable providers.

It baffles me that there's still no way of just disabling a block without having to introduce a count parameter, that should have been fixed ages ago.

Re: HashiCorp’s multi-product strategy

#88

Post by hericium »

EduardoRT wrote: post #87
hericium wrote: post #86

Earlier quoted context omitted.

AWS provider seems to be covering for some of Terraform's shortcomings. Until I was using just AWS, Cloudflare and other widely-used providers the problems weren't that much annoying. After switching to some niche services with not so extensively developed (yet not buggy to my knowledge) provider modules, the whole Terraform experience went sideways. Those "let's just use silly count or for_each to enable/disable the…

Agree, smaller providers are more difficult to work with, hard to draw the line between an issue with the tool or a developer introduced issue though, I do agree that smaller providers tend to be weird, so I think Terraform/Hashi could do a better job at making it easier for developers to create better/more reliable providers. It baffles me that there's still no way of just disabling a block without having to introdu…

> disabling a block without having to introduce a count parameter

for_each is (weird and unpleasant but) an option, too.

    for_each = var.enabled ? ["thing"] : []

Re: HashiCorp’s multi-product strategy

#89

Post by jillesvangurp »

austinjp wrote: post #61
jillesvangurp wrote: post #46

Open source rules the world. A lot of people use HashiCorp's OSS products; not a lot pay for them. I certainly haven't and I don't think I've ever met a paying Hashicorp customer even though I know lots of people that use their products. They are a consulting business ultimately. And like many such companies they thrive on complexity. They are doomed to become part of the problem they are trying to solve. If they suc…

> If they succeed in their mission, the result is OSS software that is so simple to use that nobody needs their consulting services. If that comes to pass I think that's okay, even admirable. Not every company needs to keep growing and growing, trying to take over the world. Not every company needs to continue in perpetuity.

> If that comes to pass I think that's okay, even admirable.

Just not very profitable. That's why devops is such a complex job.

Re: HashiCorp’s multi-product strategy

#90

Post by DannyBee »

jen20 wrote: post #18
DannyBee wrote: post #12

Earlier quoted context omitted.

The narrative is hard to buy into when they've lost >50% of their value since IPO so far. I can buy they are doing awesome in the abstract sense, but ...

> The narrative is hard to buy into when they've lost >50% of their value since IPO so far. Many companies on NASDAQ have lost 50% of their value in that time window. It just happened to co-incide with a global downturn.

Sure, but that's also kind of the point - they aren't special in any meaningful way.

If you look at their reports - they are going to have to massively cut costs somehow.

Post reply on HN