HashiCorp Exploring Potential Sale(reuters.com)
reuters.com
HashiCorp Exploring Potential Sale
https://www.reuters.com/technology/cloud-software-company-hashicorp-exploring-potential-sale-bloomberg-news-reports-2024-03-15/
115 comments
IBM is backing OpenTofu and OpenBao AFAIK. They're supposedly one of the main reasons for the licensing change. Cisco was looking to buy HC years ago, I would bet they're still interested (wonder if it will be for less money...)
Could easily be leverage in the negotiation.
IBM is a good guess but it would probably be more accurate at this stage to point at anyone that missed the cloud wars and are claiming to be a “multi-cloud manager.”
Definitely IBM, maybe Nutanix, possibly Broadcom. Hell, maybe even Cisco.
Definitely IBM, maybe Nutanix, possibly Broadcom. Hell, maybe even Cisco.
> My guess is it'll be IBM.
Could have Cisco as well! They are a lot more engaged in transforming themselves and doing a lot of M&A
Could have Cisco as well! They are a lot more engaged in transforming themselves and doing a lot of M&A
Everything becomes clearer... Glad we already moved to OpenTofu
As the tech lead of the OpenTofu project, I can tell you that I'm positively surprised by how quick the uptake has been so far since the stable release! We're also seeing a ton of external contributors jumping in, which has been heartwarming!
I also invite anybody using OpenTofu (or considering it) to join our Slack[0], it's quite active there. It's also a great place to influence the shape of new OpenTofu features.
Now 1.7 is coming out soon as well, and this week we have OpenTofu Day at KubeCon happening :)
[0]: http://opentofu.org/slack
I also invite anybody using OpenTofu (or considering it) to join our Slack[0], it's quite active there. It's also a great place to influence the shape of new OpenTofu features.
Now 1.7 is coming out soon as well, and this week we have OpenTofu Day at KubeCon happening :)
[0]: http://opentofu.org/slack
Just started a new tiny greenfield infra project for a friend but was too cowardly to use OpenTF after I tried it and found that I needed Hashicorp providers etc, couldn’t be bothered to dig in and untangle. Gotta say, didn’t find opentf docs useful at all. But hoping things go well and one day I’ll be able to just fire things up and it’ll be frictionless.
Sorry to hear that, could you expand on the paint points? Esp. on the friction points, where it was different than just using `tofu` instead of `terraform` in your commands.
To answer some of your points:
There's no point in forking the providers, as they're still open-source, you're just fetching them from our registry - registry.opentofu.org.
Core docs are generally the same as Terraform docs, but we're still missing the registry UI to explore provider docs (and are currently working on a design for that).
To answer some of your points:
There's no point in forking the providers, as they're still open-source, you're just fetching them from our registry - registry.opentofu.org.
Core docs are generally the same as Terraform docs, but we're still missing the registry UI to explore provider docs (and are currently working on a design for that).
Mainly because I installed it and ran it on a sample base infra - vpc and subnets - and I noted that it was still picking up Hashicorp providers, fine, but doesn’t this mean I have to run through a large codebase and start switching every provider out? Essentially I wasn’t sure what to do next. Should I stick with my standard terraform setup or figure out shifting to OpenTF and risk getting hit with something not available? Wasn’t something I could figure out in advance, if that makes sense? So was safest to stick with TF.
You should just keep using hashicorp providers - there's no changes to your codebase required, generally, as long as you don't specify provider sources in long form (as in, you should specify the source as `hashicorp/aws`, not as `registry.terraform.io/hashicorp/aws`). All providers should be available in our registry, and if you're missing any, just submit it[0]. Though as I said, all should be available.
There's also the migration guide you could take a look at[1].
[0]: https://github.com/opentofu/registry/issues/new?assignees=&l...
[1]: https://opentofu.org/docs/intro/migration/
There's also the migration guide you could take a look at[1].
[0]: https://github.com/opentofu/registry/issues/new?assignees=&l...
[1]: https://opentofu.org/docs/intro/migration/
Still early, but don't forget OpenBao fork of Vault.
https://github.com/openbao
https://github.com/openbao
Happy to answer technical questions about OpenBao as people have, though some might be best directed at the Technical Steering Committee, which I do not represent. :-)
I owe you a PR review on the source IP lock, I haven't had time to test it yet. It's awesome that you address it though, thank you.
Thank you for the RFE! Looking at the X-Forwarded-For handling might be good, I wasn't able to add tests for that easily, though maybe the existing test could be used as a template if you get time. I think we depend on nginx or Caddy elsewhere, but the pkiext tests might also serve as a good reference. :-)
Why did you kill most storage plugins?
I hoped that I could move from vault to openbao , but it looks like that is not the case.
I can understand the removal of secrets engines and stuff but the storage plugins should’ve been kept at least for the first few releases and than dropped a few of them while giving people a way to migrate them to supported options.
I hoped that I could move from vault to openbao , but it looks like that is not the case.
I can understand the removal of secrets engines and stuff but the storage plugins should’ve been kept at least for the first few releases and than dropped a few of them while giving people a way to migrate them to supported options.
Maintainability and feature development mostly.
I have a few improvements I'd have liked to have see upstream, but couldn't land due to the vast storage plugin base. You're left writing to the lowest common denominator of 20 storage engines which isn't maintainable when HashiCorp only supports Raft and Consul.
Take paginated lists which I've proposed as a PR. If your backend engine of choice doesn't support efficient pagination aligning with the designated semantics, you're stuck implementing it from scratch. Now do that with transactional storage, which is another upstream requested feature... And so forth.
Additionally, the current contributor base is too small to support much more. Personally, I'd like to see Postgres as the only external storage engine. But I don't presently feel we have enough maintainers to justify multiple storage engines. Raft is easiest to support as it is what upstream is actively developing. It also eases migration for upstream-aligned users.
My 2c. But happy to take suggestions and contributions!
Edit to add: ideally I'd have liked to add an external storage plugin interface, but this would be a bit of a perf hit over native support and wouldn't be a stable target (as I'd like to see some of these things land).
I have a few improvements I'd have liked to have see upstream, but couldn't land due to the vast storage plugin base. You're left writing to the lowest common denominator of 20 storage engines which isn't maintainable when HashiCorp only supports Raft and Consul.
Take paginated lists which I've proposed as a PR. If your backend engine of choice doesn't support efficient pagination aligning with the designated semantics, you're stuck implementing it from scratch. Now do that with transactional storage, which is another upstream requested feature... And so forth.
Additionally, the current contributor base is too small to support much more. Personally, I'd like to see Postgres as the only external storage engine. But I don't presently feel we have enough maintainers to justify multiple storage engines. Raft is easiest to support as it is what upstream is actively developing. It also eases migration for upstream-aligned users.
My 2c. But happy to take suggestions and contributions!
Edit to add: ideally I'd have liked to add an external storage plugin interface, but this would be a bit of a perf hit over native support and wouldn't be a stable target (as I'd like to see some of these things land).
Well with these changes before the first version I would not consider openbao a fork of vault. More like a different product.
Yeah some of these proposed changes are nice. But they shouldn’t be done in the first release if you wanted to take over vault customers.
I will probably never migrate to openbao.
Especially if raft is the only storage option.
And don’t get me wrong you can do that stuff. You do the work, so you guys can do whatever you like.
Especially if raft is the only storage option.
And don’t get me wrong you can do that stuff. You do the work, so you guys can do whatever you like.
I think there's many counter examples to this: Jenkins & Hudson, Illumos & Solaris, LibreSSL & OpenSSL & BoringSSL, LibreOffice & OpenOffice, Spongy Castle & Bouncy Castle, and Webkit & KHTML to name a few.
A fork need not necessarily be 1:1, bug for bug, compatible.
We discussed this here: https://github.com/orgs/openbao/discussions/55 and here: https://github.com/orgs/openbao/discussions/64 -- you're welcome to give feedback there and contribute to the success of the project. :-)
But as noted here: https://developer.hashicorp.com/vault/docs/configuration/sto... -- upstream only supports the Raft backend. The other backends may have issues and don't see many commits as upstream has not delegated maintenance to external community members. Frequently, commentators (both employees and community members) suggest moving away from custom storage backends to Raft.
A storage migration only impacts one small category of users -- the operator -- but remains transparent to the consumers of secrets (whether humans or applications). This only occurs once. Yes, it requires planning. Yes, it is a lot of work to execute successfully. But it is also an approach upstream uses e.g., in FIPS 140-2 migrations: https://developer.hashicorp.com/vault/docs/enterprise/fips/f... -- as we get time, we'd like to make this type of cross-instance migration more automated if we can.
But our goal is to remain API compatible, so the vast majority of use cases require no changes to operate with the forked code. And we wish to remain as drop-in compatible with consumers using Raft as we can. So yes, I think OpenBao can still be called a fork of Vault. And IMO, even a 1:1 bug compatible fork is still a separate product, and that isn't necessarily a bad thing. :-)
OpenTofu has much the same approach, where they don't guarantee a 1:1 drop-in, bug-for-bug fork of upstream, but instead gives themselves some room to make changes for the best of their community: https://opentofu.org/docs/language/v1-compatibility-promises...
I think that every project needs to find their own balance, and this is what the OpenBao community has chosen. :-)
My 2c, views my own. But feel free to contact me via email if you have additional technical concerns to discuss.
A fork need not necessarily be 1:1, bug for bug, compatible.
We discussed this here: https://github.com/orgs/openbao/discussions/55 and here: https://github.com/orgs/openbao/discussions/64 -- you're welcome to give feedback there and contribute to the success of the project. :-)
But as noted here: https://developer.hashicorp.com/vault/docs/configuration/sto... -- upstream only supports the Raft backend. The other backends may have issues and don't see many commits as upstream has not delegated maintenance to external community members. Frequently, commentators (both employees and community members) suggest moving away from custom storage backends to Raft.
A storage migration only impacts one small category of users -- the operator -- but remains transparent to the consumers of secrets (whether humans or applications). This only occurs once. Yes, it requires planning. Yes, it is a lot of work to execute successfully. But it is also an approach upstream uses e.g., in FIPS 140-2 migrations: https://developer.hashicorp.com/vault/docs/enterprise/fips/f... -- as we get time, we'd like to make this type of cross-instance migration more automated if we can.
But our goal is to remain API compatible, so the vast majority of use cases require no changes to operate with the forked code. And we wish to remain as drop-in compatible with consumers using Raft as we can. So yes, I think OpenBao can still be called a fork of Vault. And IMO, even a 1:1 bug compatible fork is still a separate product, and that isn't necessarily a bad thing. :-)
OpenTofu has much the same approach, where they don't guarantee a 1:1 drop-in, bug-for-bug fork of upstream, but instead gives themselves some room to make changes for the best of their community: https://opentofu.org/docs/language/v1-compatibility-promises...
I think that every project needs to find their own balance, and this is what the OpenBao community has chosen. :-)
My 2c, views my own. But feel free to contact me via email if you have additional technical concerns to discuss.
We had some discussions about this before removing all storage plugins except Raft, In-Memory and File storage as cipherboy pointed out in the sibling comment. If you're currently not using Raft, this should not stop you from adopting OpenBao if you first migrate to the Raft storage backend. Hashicorp has a tutorial on this which you can follow:
https://developer.hashicorp.com/vault/tutorials/raft/raft-mi...
I've personally used the Raft storage backend in production for some years and can assure you it is rock solid.
https://developer.hashicorp.com/vault/tutorials/raft/raft-mi...
I've personally used the Raft storage backend in production for some years and can assure you it is rock solid.
What about OpenMao?
https://openmao.panchuang.net/#/
We're still on Terraform 1.5 (pre-license change) and Scalr. Things are still working, fingers crossed.
Was there any pain in preserving existing state files and large amounts of existing infrastructure (and terraform repos) when migrating to OpenTofu?
Was there any pain in preserving existing state files and large amounts of existing infrastructure (and terraform repos) when migrating to OpenTofu?
It's quite sad to think that Terraform might go the way of Hudson...
It's not the worst possible outcome.
Out of curiosity, and afaik HashiCorp is not one, how do sales of US-style benefit corporations [0] go?
It seems like irrevocable benefits enumerated in corporate bylaws + predecided public-friendly liquidation procedure (i.e. source code / copyright / trademark release) would help fight profit maximization at the expense of product quality.
HashiCorp's financials don't look terrible, so I'm assuming this sale is more about individual holders cashing out?
[0] https://en.m.wikipedia.org/wiki/Benefit_corporation
It seems like irrevocable benefits enumerated in corporate bylaws + predecided public-friendly liquidation procedure (i.e. source code / copyright / trademark release) would help fight profit maximization at the expense of product quality.
HashiCorp's financials don't look terrible, so I'm assuming this sale is more about individual holders cashing out?
[0] https://en.m.wikipedia.org/wiki/Benefit_corporation
> HashiCorp's financials don't look terrible, so I'm assuming this sale is more about individual holders cashing out?
They don't look terrible now. But otherwise their recent license change and loss of technical founder have caused a bit of a shift in their user base towards open source forks. Which over time might substantially devalue their growth perspective. Any new projects would default to open source tools and not their proprietary thing.
This is also what I see when consulting on Elasticsearch and Opensearch projects. Almost all my recent clients start out with Opensearch these days because it is the open source choice and they are (mostly) in AWS just a few short years after they announced their license change. I'm pretty sure that's going to happen with things like Terraform and Opentofu as well. Anyone considering making similar moves, there's a growing amount of cases where this ends with a fork.
So, yes, this is why they are selling now. Before it turns into a fire sale. To a buyer it might be attractive to milk existing accounts for a while. A smart buyer might even reverse the license change in order to get some prospect of growth and re-absorb the community. But barring that, it's going to be the usual deal of either companies like Oracle or some hedge fund squeezing this thing dry until there's nothing left.
They don't look terrible now. But otherwise their recent license change and loss of technical founder have caused a bit of a shift in their user base towards open source forks. Which over time might substantially devalue their growth perspective. Any new projects would default to open source tools and not their proprietary thing.
This is also what I see when consulting on Elasticsearch and Opensearch projects. Almost all my recent clients start out with Opensearch these days because it is the open source choice and they are (mostly) in AWS just a few short years after they announced their license change. I'm pretty sure that's going to happen with things like Terraform and Opentofu as well. Anyone considering making similar moves, there's a growing amount of cases where this ends with a fork.
So, yes, this is why they are selling now. Before it turns into a fire sale. To a buyer it might be attractive to milk existing accounts for a while. A smart buyer might even reverse the license change in order to get some prospect of growth and re-absorb the community. But barring that, it's going to be the usual deal of either companies like Oracle or some hedge fund squeezing this thing dry until there's nothing left.
> a shift in their user base towards open source forks
I wonder how we can verify this. If I look at HashiCorp's quarterly results,[1] revenue is up, and they're adding customers, but net dollar retention rate is trending down.
OpenTofu has 3k followers to HashiCorp's 6.9k on Github. The opentofu/opentofu repo has 18.8k stars to 40.9k for hashicorp/terraform. Sentiment on a recent r/TerraForm thread seems decidedly mixed.[2]
Are any of the (edit: other) forks of HashiCorp's viable yet?
[1] https://ir.hashicorp.com/financial-information/quarterly-res...
[2] https://old.reddit.com/r/Terraform/comments/19egjs3/thoughts...
I wonder how we can verify this. If I look at HashiCorp's quarterly results,[1] revenue is up, and they're adding customers, but net dollar retention rate is trending down.
OpenTofu has 3k followers to HashiCorp's 6.9k on Github. The opentofu/opentofu repo has 18.8k stars to 40.9k for hashicorp/terraform. Sentiment on a recent r/TerraForm thread seems decidedly mixed.[2]
Are any of the (edit: other) forks of HashiCorp's viable yet?
[1] https://ir.hashicorp.com/financial-information/quarterly-res...
[2] https://old.reddit.com/r/Terraform/comments/19egjs3/thoughts...
Revenue is up because a lot of their contracts will be over a 3-5 year term and they'll recognize the revenue each year of the contract.
It'll take 3 to 5 years for the pain to be felt and another 3 to 5 years from that point to collapse because most companies will just pay the renewal to buy time to let the rest of the space mature.
Source/bias: I see this happening all the time in the space. I gave a talk about why Terraform is dead and long live Pulumi.
It'll take 3 to 5 years for the pain to be felt and another 3 to 5 years from that point to collapse because most companies will just pay the renewal to buy time to let the rest of the space mature.
Source/bias: I see this happening all the time in the space. I gave a talk about why Terraform is dead and long live Pulumi.
This. Pulumi is to Terraform what Figma was to InVision.
What is your definition of viable? I know large F500 orgs using OpenTofu. A lot of orgs that offer services to other orgs within an umbrella org or within a holding company noped out of terraform due to the licensing change.
OpenTofu does seem to have reached a stable, usable release. I meant to ask whether any of the other forks are viable. OpenBao, e.g., doesn't seem there yet.
Per https://github.com/orgs/openbao/discussions/147#discussionco... the Alpha is slated for end of the month. No word on GA date yet.
If you read it as the fork having in 6 months around half the "reach" of the 9 years old Terraform; that's not exactly the best trend for them ...
> HashiCorp's financials don't look terrible
Uh, what?
2023 revenue was 475.89M, gross margin was certainly good with 381.47M gross profit, but then you look at 678.76M of SG&A and then operational losses are (274.3M). Everything else is horrible: -62% operating margin, -22% return on equity, -23% return on total capital, -21% return on invested capital.
And now due to bungling their license change, there are completely open source forks of their two biggest products. Given their pretty flat revenue since the license change they haven't even been able to successfully use the license change to do a short-term squeeze out of their existing customers. They had been growing 72% revenue year over year for the prior 4 years, but they're now only up 16% over the past 4 quarters.
This is currently a value destroying business. If you take the products and the R&D team and throw away the administrative and selling costs and plug it into some much bigger corporations administrative+selling THEN it might look better (but it is more likely to wind up like F-secure ssh vs. openssh and any purchaser is going to grossly overpay -- probably it'll be the best outcome for the shareholders though)
Uh, what?
2023 revenue was 475.89M, gross margin was certainly good with 381.47M gross profit, but then you look at 678.76M of SG&A and then operational losses are (274.3M). Everything else is horrible: -62% operating margin, -22% return on equity, -23% return on total capital, -21% return on invested capital.
And now due to bungling their license change, there are completely open source forks of their two biggest products. Given their pretty flat revenue since the license change they haven't even been able to successfully use the license change to do a short-term squeeze out of their existing customers. They had been growing 72% revenue year over year for the prior 4 years, but they're now only up 16% over the past 4 quarters.
This is currently a value destroying business. If you take the products and the R&D team and throw away the administrative and selling costs and plug it into some much bigger corporations administrative+selling THEN it might look better (but it is more likely to wind up like F-secure ssh vs. openssh and any purchaser is going to grossly overpay -- probably it'll be the best outcome for the shareholders though)
HashiCorp is a public company that is losing money [1]. They still aren’t sustainable financially.
[1] https://www.google.com/finance/quote/HCP:NASDAQ
[1] https://www.google.com/finance/quote/HCP:NASDAQ
They're making progress. Their last quarter shows them decreasing their loss in net income and at the same time increasing their revenue.
IMO they're a dying company. Selling is a smart move to push their existing customers a cross sale product to close the loss gap. They'll drop 15 to 30% of their staff.
They're not that far from profitability when you realize their staffing cost is high vs the yielding return per employee.
IMO they're a dying company. Selling is a smart move to push their existing customers a cross sale product to close the loss gap. They'll drop 15 to 30% of their staff.
They're not that far from profitability when you realize their staffing cost is high vs the yielding return per employee.
Makes sense, since with another product company you could collapse the sales orgs and drastically decrease the marketing+sales costs without impacting revenue.
I thought you should bleed money for the sake of unbounded growth.
Depending on how cheap the money is.
Is there any dev friendly company that buys companies like this?
Oracle would make it suck more.
Microsoft, Amazon, or Google would make it less portable and do they buy infrastructure projects like this?
Would Cisco maybe consider this infrastructure in all their customers stacks?
Or Facebook could buy as a vanity project to just get mindspace with developers?
Oracle would make it suck more.
Microsoft, Amazon, or Google would make it less portable and do they buy infrastructure projects like this?
Would Cisco maybe consider this infrastructure in all their customers stacks?
Or Facebook could buy as a vanity project to just get mindspace with developers?
Google support Kubernetes, so there's precedent there.
I could see Microsoft keeping things open too. So far they have done OK with GitHub and NPM.
I could see Microsoft keeping things open too. So far they have done OK with GitHub and NPM.
google more or less created k8s, they're no going to buy a competitor to it
Terraform is not really a competitor. Maybe Nomad is? I expect most K8s shops use a bit of Terraform, maybe Vault, etc.
I mean there’s always buying a competitor to kill it off…
Google also pushes Terraform as its core IaC so that would be a great fit actually!
Maybe Cloudflare? It would be weird, but it would probably not ruin HashiCorp. Or the Linux Foundation itself somehow?
That would be interesting given their sort-of fall out? (https://twitter.com/eastdakota/status/1522098889423163394)
Is there more context than the single tweet? Twitter doesn't display threads to non-users anymore and Nitter is dead, so I can't see if the follow up mentioned ever happened.
No, and I don't recall anything about that "#staytuned" materializing. IIRC this was related to a license renewal that got ugly.
No, not in that thread at least
Datadog? But I'm not sure you'll appreciate the pricing.
luckily i won’t be able to understand it either
I don’t really think Cloudflare is interested in these types of purchases.
My guess is on Microsoft. It fits within the GitHub MO.
My guess is on Microsoft. It fits within the GitHub MO.
I think so too, I think of Cloudflare as an infrastructure kind of company which is why they came to mind. It would be a buyout to keep the industry from seeing crucial tooling go down in flames when the wrong company acquires them. Microsoft might be a solid one, though no telling if this is even on their radar.
Does Microsoft even need Hashicorp? GitHub was valuable for the access to code repositories (probably for their AI master plan), but Hashicorp?
With Azure they have alternatives for stuff that Hashicorp offers and what for them in Terrafor considering that ARM and Bicep exists?
With Azure they have alternatives for stuff that Hashicorp offers and what for them in Terrafor considering that ARM and Bicep exists?
Hashicorp definitely fits the brand of meeting developers where they are.
A strategy that has worked well for them.
A strategy that has worked well for them.
Cloudflare is a very interesting idea from a user perspective
Actually given how Java has evolved since Java 7, MaximeVM evolution into GraalVM, J/Rockit integration into OpenJDK, versus the mess on Android side, I am glad Google didn't move a finger to acquire Sun after torpedoed it.
Software Company HashiCorp Is Weighing a Potential Sale (bloomberg.com)
65 points by MajimasEyepatch 1 day ago | 49 comments
https://news.ycombinator.com/item?id=39721381
65 points by MajimasEyepatch 1 day ago | 49 comments
https://news.ycombinator.com/item?id=39721381
I can’t wait to be forced to migrate off vault. Such a useful use of my time.
Checkout openbao, a Vault fork: https://github.com/openbao/openbao
Is there a good open source secret management abstraction that works for both containers and serverless? I’d love to use one library to connect to AWS SM and Vault and whatever we replace Vault with.
Oh god.
I chuckled when i saw your username. syslog producing "Oh god" for "vault condition".
I always thought Hashi's technologies would lose their lustres soon. My previous company used to use Terraform and Nomad. They are like Graphite 10 years ago: darling of the open source community, good for small companies, but eventually becoming a productivity nightmare. There are just so many bizarre decisions and the accidental complexity of Hashi's family bucket is just through the roof. The one that I hate most is its embedding of Jinja template to inject system configurations. I mean why in the world would someone separate the service configuration from a service itself and force engineers to take care of service configurations in a separate places while learning so many irrelevant details: Terraform, Jinja, string escaping, embedded language, integration with the deployment environment, and the official docs do not help that much. They seem contain everything, but it's just so hard to connect the dots.
Hashicorp gave away basically everything valuable they had, and charges extortionate prices for the few features they've paywalled. Only way they're going to survive is by becoming a feature of some bigger cloud offering.
We've been leaning into Terraform-based Crossplane providers recently and the out of the box experience is so much better than using terraform cloud once you get crossplane set up, I can't imagine ever going back to vanilla terraform pipelines, and certainly not paying for terraform cloud.
We've been leaning into Terraform-based Crossplane providers recently and the out of the box experience is so much better than using terraform cloud once you get crossplane set up, I can't imagine ever going back to vanilla terraform pipelines, and certainly not paying for terraform cloud.
The high price of Hashicorp doomed them in the end. I don’t know what their financials looked like internally but the quotes we got from sales reps got them laughed out of the room.
I had the same experience some years ago. When we told them they were out of their minds and they wouldn't budge on price, the sales rep came back after a few months pleading to get us back to the table because we would have been a gigantic sale and a foothold into the other orgs of the large company I worked for at the time. We told them we already had a different solution in flight because of their original failure to negotiate.
Thirded. Some of their products looked useful so we talked to a sales person, and it was exorbitant. Not "oof, that's a little more than I'd budgeted for", but "LOL does that include equity?" The upside is that it pushed us to check out the alternatives.
AWS Secrets Manager isn't as nice as Vault in a lot of ways, but at a starting price of $0.40/mo for 1 secret + as many clients as you'd want vs $1250/mo for a standard vault + 1 client, it's fine.
AWS Secrets Manager isn't as nice as Vault in a lot of ways, but at a starting price of $0.40/mo for 1 secret + as many clients as you'd want vs $1250/mo for a standard vault + 1 client, it's fine.
I worked in the HashiCorp sales org for a couple of years -- Vault's weird identity-based pricing model was by far the biggest issue with getting prospects to buy Enterprise. It's great if you're a large multinational with highly-consolidated infrastructure and application identity, but if you're operating on a smaller scale than that or are not highly-centralized it's totally infeasible. The sales segment that focused on the smallest deals was rarely able to sell Vault Enterprise at all -- both because the pricing was so high and because the pricing model itself didn't scale in a way prospects felt they could understand and budget predictably for as they grew. We heard "we love the features, but there's no way we can afford that price" all the time. Various people beat the drum on this internally for literally years right from the initial switch to the current pricing model, but other than minor "client counting" tweaks, nothing ever changed.
I see they have a SaaS product called Vault Secrets now and I bet that's exactly why that product exists.
I see they have a SaaS product called Vault Secrets now and I bet that's exactly why that product exists.
Okay but how much does that really say? All HN/startup advice says that when you sell to enterprises you have to charge enterprise prices. Meanwhile techies are notoriously for preferring to spend a month's worth of salary building an FTP server to replace Dropbox with.
Hashicorp's prices are not what i'd consider to be 'enterprise prices'. When we looked at buying "enterprise vault" a few years ago it was six figures a year for a relatively small install. It was basically "we don't want your business" pricing.
> six figures a year
So, they cost about 1 developer?
I mean, yes, it is a bit expensive. On the other hand, it also shows that it is nearly impossible to have an opensource product and be profitable at the same time, especially with dev/infra tooling like this.
So, they cost about 1 developer?
I mean, yes, it is a bit expensive. On the other hand, it also shows that it is nearly impossible to have an opensource product and be profitable at the same time, especially with dev/infra tooling like this.
> > six figures a year
> So, they cost about 1 developer?
Where lol. You live in a bubble.
> So, they cost about 1 developer?
Where lol. You live in a bubble.
> Where lol.
Not in the US, for that matter.
Not in the US, for that matter.
Where is it? UK? Ireland?
There are countries where English is not the main language, and these countries do in fact have software developers.
Yes, sure. Thanks, Captain Obvious. I’m asking WHERE is the country where a single dev costs $1m per year.
Six figures a year is from 100k to 999k.
1M is seven figures.
Counting is hard.
1M is seven figures.
Counting is hard.
Indeed, thanks.
> All HN/startup advice says that when you sell to enterprises you have to charge enterprise prices.
HN/founder culture is a bubble though.
And the original statement was Joel's and said you have to either charge something that the lowest level manager can approve on their own OR enterprise pricing. Basically you can charge $30 or $3000 but not $300.
HN/founder culture is a bubble though.
And the original statement was Joel's and said you have to either charge something that the lowest level manager can approve on their own OR enterprise pricing. Basically you can charge $30 or $3000 but not $300.
I remember seeing quotes for Hashicorp Vault Enterprise, the price for Vault dwarfed the entire cloud bill of the company. And yet the cloud bill (through the marketplace) included other third-parties that were being paid an "enterprise price".
I can tell you that I worked at a large company that was moving pieces like identity and secrets management to SaaS or open source solutions years after rolling their own and failing to keep up. I'm well versed in built vs buy vs opensource.
For the record, Hashicorp vault was 10x the cost of our fully managed Identity system for a million+ unique logins a month.
For the record, Hashicorp vault was 10x the cost of our fully managed Identity system for a million+ unique logins a month.
Was there still people buying Vault at that price? From my perspective it looks like Hashicorp has been overplaying its hand there, but maybe it worked somehow!?
Exactly. open source and free tiers in b2b are dead business models for the most part in the post ZIRP Era.
planetscale - https://news.ycombinator.com/item?id=39618815
planetscale - https://news.ycombinator.com/item?id=39618815
Can you share what provider you are referencing?
you still have to terraform the crossplane control plane no?
Believe it or not, no. We're using cluster-api.
I've got a github actions pipeline that stands up a kind cluster, installs cluster-api on it, uses cluster-api to stand up the control plane cluster and then copies over the cluster-api config to it along with argocd, and after that it's self-managing. We did have to do a little bit of terraform to get iam roles set up, but that's it.
Everything after that is pure argo cd, cluster-api and crossplane.
I work at something that's basically a startup incubator and we can stand up and manage the infrastructure for an entire enterprise, on either aws or azure (including stuff like SSO artifact storage and CICD pipelines), from a central control plane with just a few lines of yaml, and they can be deploying code within 30 minutes. And it's continuously reconciled, so there's no drift, and if we push out an update to something, it rolls out to everything within minutes.
I've got a github actions pipeline that stands up a kind cluster, installs cluster-api on it, uses cluster-api to stand up the control plane cluster and then copies over the cluster-api config to it along with argocd, and after that it's self-managing. We did have to do a little bit of terraform to get iam roles set up, but that's it.
Everything after that is pure argo cd, cluster-api and crossplane.
I work at something that's basically a startup incubator and we can stand up and manage the infrastructure for an entire enterprise, on either aws or azure (including stuff like SSO artifact storage and CICD pipelines), from a central control plane with just a few lines of yaml, and they can be deploying code within 30 minutes. And it's continuously reconciled, so there's no drift, and if we push out an update to something, it rolls out to everything within minutes.
God, please, not to Oracle.
In case one wants to switch from Hashicorp to alternatives that are similar enough or forks, what would that stack be?
Hashiternative stack:
- vault -> openbao (fork)
- terraform -> opentofu (fork)
- consul -> ?
- nomad -> slurm + something that runs/orchestrates windows jobs?
- hcl -> dhall + nix?
Hashiternative stack:
- vault -> openbao (fork)
- terraform -> opentofu (fork)
- consul -> ?
- nomad -> slurm + something that runs/orchestrates windows jobs?
- hcl -> dhall + nix?
[deleted]
So far I haven't seen any fork or alternative to Nomad emerge.
What is particularly worrisome when you need something lightweight and to support non containerized services...
What is particularly worrisome when you need something lightweight and to support non containerized services...
[dupe]
More discussion https://news.ycombinator.com/item?id=39721381
More discussion https://news.ycombinator.com/item?id=39721381
For teams using or considering Terraform as IaC, what are the implications if any?
For Terraform there should be none, since you have drop-in alternatives for both the base product and the commercial platform (disclosure: I’m involved in OpenTofu and Spacelift, respectively).
Other tooling may be more problematic. Vault has an open source fork in the works but nowhere near production readiness AFAIK.
Other tooling may be more problematic. Vault has an open source fork in the works but nowhere near production readiness AFAIK.
Whew, glad we moved away from vagrant already.
What happens to their stock if they sell?
As soon as it's formally announced, It moves to the price they agreed to sell for, and then you can either sell them on the open market for that price, or hold them and convert them to shares of the company acquiring. There may be a tax benefit to you doing one or the other, so I'd consult a tax advisor.
Personally, I lost a shitload of money on HashiCorp. I've "emotionally bought" 2 stocks in my life and Hashi is one of them. I like Mitchell and Armon very much, they're actually seriously great humans, both of them, but that's an awful reason to buy a stock. If I can break even and they sell for the IPO price I'll be very pleased, but that seems impossible heh. :)
Personally, I lost a shitload of money on HashiCorp. I've "emotionally bought" 2 stocks in my life and Hashi is one of them. I like Mitchell and Armon very much, they're actually seriously great humans, both of them, but that's an awful reason to buy a stock. If I can break even and they sell for the IPO price I'll be very pleased, but that seems impossible heh. :)
Depends on the deal, but you can look at other m&as to have rought idea.
[deleted]
considering taking an internship here... should this affect my thinking?
Cisco or Okta
Here is a free tip to fix terraform business model (no MBA required):
- Terraform is one of the most valuable tools for IaC - it's all free and it shouldn't - it is not a consumer product, it is not running ads and 99% of the users are business users with money.
- Keep Terraform SDK free and open source, close source plugins, charge per resource.
- Invest much more into Core and plugins.
all forks are doomed with the same destiny, business model is not sustainable with negative margin - as long as you have such a generous free tier and storage can run on S3 the price you can ask for a managed version is incredibly low.
You welcome :)
all forks are doomed with the same destiny, business model is not sustainable with negative margin - as long as you have such a generous free tier and storage can run on S3 the price you can ask for a managed version is incredibly low.
You welcome :)
Based upon some research into numbers...
They'll absorb the talent. Expand IBMs offering of Vault-ish product while basically reselling Vault as a line item addition to their existing line items.
Less pain for IBM from license drama and the selling of open source Vault with an IBM tweak to a MUCH larger user base with zero sales expense.
IBM gets all Vault talent Hashi gets massive market without sales
Hashi is $800MM revenue because of 80% sales and marketing.