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

IBM completes acquisition of HashiCorp

newsroom.ibm.com

Post reply on HN
Print view View original

81–90 of 407 posts

Re: IBM completes acquisition of HashiCorp

#81

Post by hiatus »

ghaff wrote: post #54
xyst wrote: post #50

Earlier quoted context omitted.

*retail investors Retail will always be holding the bag. This is known.

Eh. Lots of retail investors do well with the right stock. Lot's of Apple investors have done well over the years. Microsoft even with the right timing. They didn't with HashiCorp certainly. Bought some but not too much and were part of a housecleaning a few years back (which I'm glad I did).

How far away from IPO are Apple and Microsoft now? I think parent is lamenting the state of IPOs as cashing out, if anything.

Re: IBM completes acquisition of HashiCorp

#83

Post by gue5t »

ants_everywhere wrote: post #72

Hashicorp's stuff always struck me as pretty hacky with awkward design decisions. For Terraform (at least a few years ago) a badly reviewed PR could cause catastrophic data loss because resources are deleted without requiring an explicit tombstone. Then they did the license change, which didn't reflect well on them. Now it's being sold to IBM, which is essentially a consulting company trying to pivot to mostly undiff…

I concur. I looked pretty hard into adapting Serf as part of a custom service mesh and it had some bonkers designs such as a big "everything" interface used just to break a cyclic module dependency (perhaps between the CLI and the library? I don't recall exactly), as well as lots of stuff that only made sense if you wanted "something to run Consul on top of" rather than a carefully-designed tool of its own with limited but cohesive scope. It seemed like a lot of brittle "just-so" code, which to some extent is probably due to how Go discourages abstraction, but really rubbed me the wrong way.

Re: IBM completes acquisition of HashiCorp

#84

Post by nemo44x »

guelo wrote: post #33
redeux wrote: post #19

Earlier quoted context omitted.

Depends how you define insider. Employees were subject to a 6 month lockup and during that time the price dropped dramatically, but they still had to pay taxes on the $80 IPO price. Execs and institutional investors that were able to sell at IPO made out quite well though.

Execs are employees, were they really exempt from the lockout? Seems unethical.

Nearly certainly they were not. Any stock holder would be blacked out including existing investors.

Re: IBM completes acquisition of HashiCorp

#85

Post by ants_everywhere »

JohnMakin wrote: post #77
ants_everywhere wrote: post #72

Hashicorp's stuff always struck me as pretty hacky with awkward design decisions. For Terraform (at least a few years ago) a badly reviewed PR could cause catastrophic data loss because resources are deleted without requiring an explicit tombstone. Then they did the license change, which didn't reflect well on them. Now it's being sold to IBM, which is essentially a consulting company trying to pivot to mostly undiff…

> For Terraform (at least a few years ago) a badly reviewed PR could cause catastrophic data loss because resources are deleted without requiring an explicit tombstone. There have been lifecycle rules in place for as long as I can remember to prevent stuff like this. I'm not sure this is a "problem" unique to terraform.

What happens if you forget the lifecycle annotations or put them in the wrong place or you accidentally delete them? Last time I checked it was data loss, but that was a few years ago.

Re: IBM completes acquisition of HashiCorp

#86

Post by sepositus »

hiatus wrote: post #79
sepositus wrote: post #32

Earlier quoted context omitted.

This is probably inaccurate, but it seemed like they wrote it off as a safe move, with their main competitor, Pulumi, getting away with it. However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a de…

> However, to play devil's advocate, the number of Terraform resources is a (slightly weak) predictor for resource consumption. Every resource necessitates API calls that consume compute resources. So, if you're offering a "cloud" service that executes Terraform, it's probably a decent way to scale costs appropriately. That would make sense if you paid per API call to any of the cloud providers.

What happens when you run `terraform apply`? Arguably, a lot of things, but at its core it:

- Computes a list of resources and their expected state (where computation is generally proportional to the number of resources).

- Synchronizes the remote state by looking up each of these resources (where network ingress/egress is proportional to the number of resources).

- Compares the expected state to the remote state (again, where computation is generally proportional to the number of resources).

- Executes API calls to make the remote state match the expected state (again, where network ingress/egress is proportional to the number of resources).

- Stores the new state (where space is most certainly proportional to the number of resources)

This is a bit simplified, but my point is that in each of the five operations, the number of resources can be used as a predictor for the consumed compute resources (network/cpu/memory/disk). A customer with 10k resources is necessarily going to consume more compute resources than one with 10 resources.

Re: IBM completes acquisition of HashiCorp

#87

Post by cube2222 »

master_crab wrote: post #76

Do any Opentofu cloud providers (like spacelift) offer a managed migration tool to their cloud and opentofu from TFE or TFC? (Asking for a friend).

Here you go[0]! Docs are linked in the README, and there’s also a recent blog post about it[1].

In any case, make sure to reach out via the website chat widget / email / demo form, we’re happy to help!

The migration from Terraform to OpenTofu is pretty seamless right now, and documented in the OpenTofu docs[2].

[0]: https://github.com/spacelift-io/spacelift-migration-kit

[1]: https://spacelift.io/blog/how-to-migrate-from-terraform-clou...

[2]: https://opentofu.org/docs/intro/migration/

Disclaimer: work at Spacelift

Re: IBM completes acquisition of HashiCorp

#89

Post by anonfordays »

ants_everywhere wrote: post #85
JohnMakin wrote: post #77

Earlier quoted context omitted.

> For Terraform (at least a few years ago) a badly reviewed PR could cause catastrophic data loss because resources are deleted without requiring an explicit tombstone. There have been lifecycle rules in place for as long as I can remember to prevent stuff like this. I'm not sure this is a "problem" unique to terraform.

What happens if you forget the lifecycle annotations or put them in the wrong place or you accidentally delete them? Last time I checked it was data loss, but that was a few years ago.

"What happens if I turn a table saw on and start breakdancing on it?"

Of course you're going to hurt yourself. If you didn't put lifecycle blocks on your production resources, you weren't organizationally mature enough to be using Terraform in production. Take an associate Terraform course, this specific topic is covered in it.

Re: IBM completes acquisition of HashiCorp

#90

Post by cowgoesmoo »

ForHackernews wrote: post #27

Sad to see this, but I will again shill for HashiCorp's Nomad as a better alternative to Kubernetes.

Having worked with a very large Nomad cluster, I cannot disagree more.

For simple use cases, sure, but you could also just use AWS ECS or a similar cloud tool for an even easier experience.

Post reply on HN