Well, it was nice while it lasted! HashiCorp always felt like a company made by actual engineers, not "bean counters". Now it will just be another cog in the IBM machine, slowly grinding it down, removing everything attractive, just like RedHat and CentOS.
Hopefully this will create a new wave off innovation, and someone will create something to replace the monopoly on IaC that IBM now owns.
A lot of the people I respected from Heroku went there, glad they got a chance to use their skills to build something useful and profitable; glader still that they got their payout.
Sadly I echo your sentiment about the future, as someone who has heard second-hand about the quality of work at modern Redhat.
I am wondering how many more rounds of consolidation are left until there is no more space to innovate and we only have ossified rent-seeking entities in the IT space.
It always amazing me how people play telephone with Red Hat and how bad the quality of life is post IBM.
When they show the service awards they don’t even cover 5 years because they don’t have all day.
If it was so bad then you wouldn’t see engineers with 10, 15, or 20 years experience staying there. They already got their money from the IBM purchase so if it were bad then they would leave.
Oh but they don’t innovate anymore.
Summit is coming. Let’s see what gets announced and then a live demo.
our current economic model kind of depends on the idea that we can always disrupt the status quo with american free market ingenuity once it begins to stagnate but maybe we have reached the limits of what friedman's system can do or accounted for.
People's beef here with IBM is they don't make shiny phones and laptops and don't create hip jobs where you're paid 500k+ to "change the world" by selling ads or making the 69th messaging app.
They just focus on tried and tested boring SW that big businesses find useful and that's not popular on HN which is more startup and disruption focused.
IBM took away the ability of CentOS to be a free and trivial to swap-in alternative to the paid product RedHat Enterprise. That RedHat was already in financial trouble due to self-cannibalizing their own paid product is irrelevant; emotionally, “IBM” – not “RedHat” – made the decision to stop charging $0 for their custom enterprise patchsets and release trains, and so IBM will always be the focus of community ire about RedHat’s acquisition.
I expect, like RedHat, that the Hashicorp acquisition will result in a lot of startups that do not need enterprise-grade products shifting away from “anything Hashicorp offers that needs to charge money for Hashicorp to stay revenue-positive” and towards “any and all free alternatives that lower the opex of a business”, along with derogatory comments about IBM predictably assigning a non-$0 price for Hashicorp’s future work output.
IBM was taken over by bean counters years ago. There were researchers and others that would literally skip being in or find a way to avoid bean counters when they walked through IBM Research Labs (like Almaden Research Center) years ago (heard from multiple people years back that were working on contracts/etc there - mainly academics).
Also, IBM has been extremely ageist in their "layoff" policies. They also have declined in quality by outsourcing to low cost/low skill areas.
I never worked there, but I worked at a security company that hired a bunch of ex-IBM X-Force security guys, and they hated IBM with a passion.
Self selection, to be sure, but their beefs were mostly about the crushing bureaucracy that was imposed on what was supposed to be a nimble type domain; (network) security is, after all, mostly leapfrog with the black hats.
I just got to spin down a bunch of infra that was originally in Softlayer, which IBM acquired years ago. IBM were terrible to work with, they frequently crashed services by evacuating VMs from hosts and then not powering them back up, and only notifying us long after our own monitoring detected it. Won't miss that.
I have the "honor" of getting to use IBM $PRODUCT at $COMPANY.
- it uses some form of consensus algorithm between all nodes that somehow manages to randomly get the whole cluster into a non working state by simply existing, requiring manual reboots
- Patches randomly introduce new features, often times with breaking changes to current behaviour
- Patches tend to break random different things and even the patches for those patches often don't work
- For some reason the process how to apply updates randomly changes between every couple of patches, making automation all but impossible
- the support doesn't know how $PRODUCT works, which leads to us explaining to them how it actually does things
- It is ridiculously expensive, both in hardware and licensing costs
All of this has been going on for years without any signs of improvement for now, to the point that $COMPANY now avoids IBM if at all possible
Look at what they did with the Phoenix project for Canadian Government. They are not the same IBM they were 50 years ago. Now they are a consulting firm that employ cheap labor.
I had been wondering who would buy HCP, I sort of figured it was either going to be AWS, Google, or Azure and then I figured the other vendor were going to have support removed (maybe gradually, maybe not.)
You talk about beef, look at what they did with a project for Canadian Government. They are not the same IBM they were 50 years ago. Now they are a consulting firm and a shitty one.
Look at what they did with the Phoenix project for Canadian Government. They are not the same IBM they were 50 years ago. Now they are a consulting firm.
Hashi code, such as Terraform, was (is) an amazing example of a good reference Go codebase. It was very hard for me to get into Go because, outside of the language trivia and hype, it was hard to learn about the patterns and best practices needed for building even a mid-sized application.
Same. I wanted to pay them for their features, but the pricing was such that I actually thought it was a gag or a troll at first and laughed. When I realized they were serious, I was like Homer fading into the bushes.
Same. And I didn't feel like we were getting anything for that crazy money aside from than "support" (which management wanted, pre IPO, to make a bunch of security audits seem easier ). We preferred to stick with our own tooling and services that we built around Vault (for example) than use the official enterprise stuff. Same goes for terraform today: I don't feel like we need Terraform Cloud, when we've got other options in that space, including home grown tooling.
Usually during an acquisition like this, the key staff are paid out after two years on board the new company. So not a non-compete, but an incentive to stay and get their payout.
Most staff with no equity will leave quickly of course, so the invalidity of non compete will definitely help those souls.
I see this as an opportunity. Not to replace HashiCorp's products - OpenTofu and OpenBao are snapping up most of the mindshare for now - but to build another OSS-first developer darling company.
Btw. OpenTofu 1.7.0 is coming out next week, which is the first release that contains meaningful Tofu-exclusive features! We just released the release candidate today.
State encryption, provider-defined functions on steroids, removed blocks, and a bunch more things are coming, see our docs for all the details[0].
We've also had a fun live-stream today, covering the improvements we're bringing to provider-defined functions[1].
i can only speak to the early days (joined around 11 folks), but the engineers then were top tier and hungry to build cool shit. A few years later (as an outsider) seemed innovation had slowed substantially. i still know there are great folks there, but has felt like HashiCorp’s focus lately has been packaging up all their tools into a cohesive all-in-one solution (this was actually Atlas in the early days) and figuring out their story around service lifecycle with experiments like Waypoint (Otto in the early days). IBM acquisition is likely best outcome.
Isn't that how it always is as any company matures? In a big company, you don't need just 5-star devs. You also need a 3-star devs (and even 2-star devs) that work 9 to 3:30 (and maybe do emails/slack between 3:30 - 4; bonus points if they study from 4 to 5). You need people that can take basic requirements and turn them into code that your 5-star devs are too bored to write. You need people who look at customer bugs, can do debugging and submit a patch to fix a corner case your 5-star dev didn't think about 4 years when they were hopped up on caffeine, hopes and dreams.
Honestly, Mitchell should still be very proud of what he built and the legacy of Hashicorp. Sure, the corp has taken a different direction lately but thanks to the licenses of the Hashicorp family of software, it's almost entirely available for forking and re-homing by the community that helped build it up to this point. E.g. opentofu and openbao. I'm sure other projects may follow and the legacy will endure, minus (or maybe not, you never know) contributions from the company they built to try to monetize and support that vision.
Saltstack is IMO superior to Ansible. It uses ZMQ for command and control. You can write everything in python if you want but the default is YAML + JINJA2. And is desired state not procedural.
Not used it for about 5 years and I think they got bought by VMWare IIRC. The only downside is that Ansible won the mindshare so you're gonna be more on your own when it comes to writing esoteric formulas.
I wrote a tool similar to ansible in the old days. We both started about the same time, so wasn't really a goal to compete with it. Later I noticed they had some type of funding from Red Hat, which dulled my enthusiasm a bit. Then Docker/containers started hitting it big and I figured it would be the end of the niche and stopped.
Interesting that folks are still using it, though I'm not sure of the market share.
My personal opinion is it was a company for crack monkeys. Consul, Vault and Packer have been nothing but pain and misery for me over the last few years. The application of these technologies has been nothing but a loss of ROI and sanity on a promise.
And don't get me started on Terraform, which is a promise but rarely delivers. It's bad enough that a whole ecosystem appeared around it (like terragrunt) to patch up the holes in it.
It was this, but hasn’t been for a couple of years at least. The culture really shifted once it was clear the pivot to becoming a SaaS-forward company wasn’t taking off. As soon as the IPO happened and even a little bit before, it felt like the place was being groomed down from somewhere unique and innovative to a standardized widget that would be attractive to enterprise-scale buyers like VMware or IBM.
I think it's ok to tell this story now. Long long time ago when I was still at DO, I tried to buy HashiCorp. Well, I use "tried to buy" very loosely. It was when we were both pretty small startups, Joonas our Dir. Eng at the time was really into their tooling, thought it was very good plus Armon and Mitch are fantastic engineers. So I flew out from NYC to SF to meet with them "to talk". Well, I had no idea how to go about trying to buy a company and they didn't really seem that interested in joining us, so we stood around a grocery store parking lot shuffling our feet talking about how great Mitch and Armon are at building stuff and then I flew home. I think that's about as loosely as it gets when it comes to buying a company. Probably would have been a cool combo tho, who knows. Either way, they're great guys, super proud of them. <3
I was in a similar position in a company that _might_ have been able to make a good enough offer, but never could convince the brass how amazing a company it is and I never got any traction.
Disappointing to hear about this, Hashicorp was an amazing company. C’est la vie…
When I got back to NYC I said to my boss (our CEO) "we should probably buy HashiCorp" and he said "Yeah, probably" and then we never spoke of it again. We both knew the problem, even if we could have got it together to make an offer and had they been interested, we were growing considerably too quickly to integrate another business. It was a fun idea, and we had a good time entertaining it, but it wouldn't have worked.
My shopping list during those years was NPM, Deis, Hashi and BitBalloon (now Netlify). These days: I generally think startups should do more M&A!
Hashi never sold me on the integration of their products, which was my primary issue with not selecting them. Each is independently useful, and there is no nudge to combine them for a 1+1=3 feature set.
Kubernetes was the chasm. Owning the computing platform is the core of utilizing Vault and integrating it.
The primary issue was that there was never a "One Click" way to create an environment using Vagarent, Packer, Nomad, Vault, Waypoint, and Boundry for a local developer-to-prod setup. Because of this, everyone built bespoke, and each component was independently debated and selected. They could have standardized a pipeline and allowed new companies to get off the ground quickly. Existing companies could still pick and choose their pieces. On both, you sell support contracts.
I hope they do well at IBM. Their cloud services' strategy is creating a holistic platform. So, there is still a chance Hashi products will get the integration they deserve.
FWIW, "HashiStack" was a much discussed, much promised, but never delivered thing. I think the way HashiCorp siloed their products into mini-fiefdoms (see interactions between the Vault and Terraform teams over the Terraform Vault provider) prevented a lot of cross-product integration, which is ironic for how "anti-silo" their go to market is.
There's probably an alternate reality where something like HashiStack became this generation's vSphere, and HashiCorp stayed independent and profitable.
I was an extremely early user and owner of a very large-scale Vault deployment on Kubernetes. Worked with a few of their sales engineers closely on it - was always told early on that although they supported vault on kubernetes via a helm chart, they did not recommend using it on anything but EC2 instances (because of "security" which never really made sense their reasoning). During every meeting and conference I'd ask about Kubernetes support, gave many suggestions, feedback, showed the problems we encountered - don't know if the rep was blowing smoke up my ass but a few times he told me that we were doing things they hadn't thought of yet.
Fast forward several years, I saw a little while ago that they don't recommend the only method of vault running on EC2, fully support kubernetes, and I saw several of my ideas/feedback listed almost verbatim in the documentation I saw (note, I am not accusing them of plagiarism - these were very obvious complaints that I'm sure I wasn't the only one raising after a while).
It always surprised me how these conversations went. "Well we don't really recommend kubernetes so we won't support (feature)."
Me: "Well the majority of your customers will want to use it this way, so....."
Just was a very frustrating process, and a frustrating product - I love what it does, but there are an unbelievable amount of footguns laden in the enterprise version, not to mention it has a way of worming itself irrevocably into your infrastructure, and due to extremely weird/obfuscated pricing models I'm fairly certain people are waking up to surprise bills nowadays. They also rug pulled some OSS features, particularly MFA login, which kind of pissed me off. The product (in my view) is pretty much worthless to a company without that.
> was always told early on that although they supported vault on kubernetes via a helm chart, they did not recommend using it on anything but EC2 instances (because of "security" which never really made sense their reasoning).
The reasoning is basically that there are some security and isolation guarantees you don't get in Kubernetes that you do get on bare metal or (to a somewhat lesser extent) in VMs.
In particular for Kubernetes, Vault wants to run as a non-root user and set the IPC_LOCK capability when it starts to prevent its memory from being swapped to disk. While in Docker you can directly enable this by adding capabilities when you launch the container, Kubernetes has an issue because of the way it handles non-root container users specified in a pod manifest, detailed in a (long-dormant) KEP: https://github.com/kubernetes/enhancements/blob/master/keps/... (tl;dr: Kubernetes runs the container process as root, with the specified capabilities added, but then switches it to the non-root UID, which causes the explicitly-added capabilities to be dropped).
You can work around this by rebuilding the container and setting the capability directly on the binary, but the upstream build of the binary and the one in the container image don't come with that set (because the user should set it at runtime if running the container image directly, and the systemd unit sets it via systemd if running as a systemd service, so there's no need to do that except for working around Kubernetes' ambient-capability issue).
> It always surprised me how these conversations went. "Well we don't really recommend kubernetes so we won't support (feature)."
> Me: "Well the majority of your customers will want to use it this way, so....."
Ha, I had a similar conversation internally in the early days of Boundary. Something like "Hey, if I run Boundary in Kubernetes, X won't work because Y." And the initial response was "Why would you want to run Boundary in Kubernetes?" The Boundary team came around pretty quick though, and Kubernetes ended up being one of the flagship use cases for it.
(I have no idea what your infra is so don’t take this as prescriptive)
My feeling is that for the average company operating in a (single) cloud, there’s no reason to use vault when you can just used AWS Secret Manager or the equivalent in azure or GCE and not have to worry about fucking Etcd quorums and so forth. Just make simple api calls with the IAM creds you already have.
"Linux Foundation joins IBM to accelerate the mission of multi-cloud automation and bring the products to a broader audience of users and customers." ;)
I wouldn't bet on that, some Linux Foundation hosted projects like Zephyr, not only don't have anything to do with Linux, they are under licenses that are quite business friendly as well.
So yeah, one can always fork the last available version, if it then survives to the extent that actually matters beyond hobby coding is seldom the case.
How many Open Solaris forks are actually relevant outside the company that owns those forks?
Also IBM, Microsoft, Oracle,.... and others that HN loves to hate are already members.
Back in 2015 I discovered a security issue with some Dell software[1]. I remember vividly getting an email about a job opportunity based entirely on this from a company with a strange name, that after some googling made a thing called Vagrant. They seemed super nice but I was far too young and immature to properly evaluate the opportunity, so after a few emails I ghosted them out of fear of the unknown. In 2015 they had 50 employees and had just raised a 10 million series A[2].
Regardless of various things that have happened, or things that could have been, the company has pushed the envelope with some absolute bangers and we are all better for it, directly or indirectly.
Regardless of what the general opinion is of Hashicorp’s future post-IBM, they made an impact and that should be celebrated, not decried or sorrowed over for lack of a perceived picture perfect ending.
I guess you're not active in hacker news around 2013 because vagrant was absolutely popular here a long time ago. Mitchell Hashimoto showed up a lot too when we're talking about vagrant back then. If only you had procrastinated more you might ended up as employee #51 :)
"Additional products – Boundary for secure remote access; Consul for service-based networking; Nomad for workload orchestration; Packer for building and managing images as code; and Waypoint internal developer platform" - Vagrant doesn't even get a mention...
I expected this when the terraform license changed. Not IBM specifically but it was obvious they weren't interested/ able to continue with their founding vision.
Hashicorp had a $14 billion IPO in Dec 2021 and was trading at ~$4.7 billion right before the acquisition announcement. At that point it doesn't matter what the company or its founders want or what their long term vision is. Shareholders are in charge and heads are going to roll if the price doesn't get back up quick by any means necessary.
Yet another example of why I think it's a mistake to take your company public. If I put in the work to build up a successful business, no way would I ever let it be turned into a machine that ignores long term health for the sake of making the stock price go up.
Readit News
IBM nearing a buyout deal for HashiCorp, source says - https://news.ycombinator.com/item?id=40135303 - April 2024 (170 comments)
Hopefully this will create a new wave off innovation, and someone will create something to replace the monopoly on IaC that IBM now owns.
Sadly I echo your sentiment about the future, as someone who has heard second-hand about the quality of work at modern Redhat.
I am wondering how many more rounds of consolidation are left until there is no more space to innovate and we only have ossified rent-seeking entities in the IT space.
When they show the service awards they don’t even cover 5 years because they don’t have all day.
If it was so bad then you wouldn’t see engineers with 10, 15, or 20 years experience staying there. They already got their money from the IBM purchase so if it were bad then they would leave.
Oh but they don’t innovate anymore.
Summit is coming. Let’s see what gets announced and then a live demo.
HashiCorp had already been sold out since waaaay before this acquisition and I also don’t understand why their engineers are seen as “special”…
They just focus on tried and tested boring SW that big businesses find useful and that's not popular on HN which is more startup and disruption focused.
I expect, like RedHat, that the Hashicorp acquisition will result in a lot of startups that do not need enterprise-grade products shifting away from “anything Hashicorp offers that needs to charge money for Hashicorp to stay revenue-positive” and towards “any and all free alternatives that lower the opex of a business”, along with derogatory comments about IBM predictably assigning a non-$0 price for Hashicorp’s future work output.
Also, IBM has been extremely ageist in their "layoff" policies. They also have declined in quality by outsourcing to low cost/low skill areas.
Self selection, to be sure, but their beefs were mostly about the crushing bureaucracy that was imposed on what was supposed to be a nimble type domain; (network) security is, after all, mostly leapfrog with the black hats.
I will not be taking questions ;-)
- it uses some form of consensus algorithm between all nodes that somehow manages to randomly get the whole cluster into a non working state by simply existing, requiring manual reboots
- Patches randomly introduce new features, often times with breaking changes to current behaviour
- Patches tend to break random different things and even the patches for those patches often don't work
- For some reason the process how to apply updates randomly changes between every couple of patches, making automation all but impossible
- the support doesn't know how $PRODUCT works, which leads to us explaining to them how it actually does things
- It is ridiculously expensive, both in hardware and licensing costs
All of this has been going on for years without any signs of improvement for now, to the point that $COMPANY now avoids IBM if at all possible
https://news.ycombinator.com/item?id=15303555
I had been wondering who would buy HCP, I sort of figured it was either going to be AWS, Google, or Azure and then I figured the other vendor were going to have support removed (maybe gradually, maybe not.)
https://news.ycombinator.com/item?id=15303555
https://news.ycombinator.com/item?id=15303555
But I had a similar experience like yours with PHP, I just couldn't get into it.
IDK about this, in 2018 I was in a position to pay for their services. They asked for stupid amount of money and got none because they asked so much.
Can't remember what the exact numbers were but but it felt like ElasticSearch or Oracle.
Most staff with no equity will leave quickly of course, so the invalidity of non compete will definitely help those souls.
State encryption, provider-defined functions on steroids, removed blocks, and a bunch more things are coming, see our docs for all the details[0].
We've also had a fun live-stream today, covering the improvements we're bringing to provider-defined functions[1].
[0]: https://opentofu.org/docs/next/intro/whats-new/
[1]: https://www.youtube.com/watch?v=6OXBv0MYalY
https://onboardbase.com/
Not used it for about 5 years and I think they got bought by VMWare IIRC. The only downside is that Ansible won the mindshare so you're gonna be more on your own when it comes to writing esoteric formulas.
Interesting that folks are still using it, though I'm not sure of the market share.
We're just starting to implement it and we've only heard good things about it.
And don't get me started on Terraform, which is a promise but rarely delivers. It's bad enough that a whole ecosystem appeared around it (like terragrunt) to patch up the holes in it.
Disappointing to hear about this, Hashicorp was an amazing company. C’est la vie…
My shopping list during those years was NPM, Deis, Hashi and BitBalloon (now Netlify). These days: I generally think startups should do more M&A!
Kubernetes was the chasm. Owning the computing platform is the core of utilizing Vault and integrating it.
The primary issue was that there was never a "One Click" way to create an environment using Vagarent, Packer, Nomad, Vault, Waypoint, and Boundry for a local developer-to-prod setup. Because of this, everyone built bespoke, and each component was independently debated and selected. They could have standardized a pipeline and allowed new companies to get off the ground quickly. Existing companies could still pick and choose their pieces. On both, you sell support contracts.
I hope they do well at IBM. Their cloud services' strategy is creating a holistic platform. So, there is still a chance Hashi products will get the integration they deserve.
There's probably an alternate reality where something like HashiStack became this generation's vSphere, and HashiCorp stayed independent and profitable.
Fast forward several years, I saw a little while ago that they don't recommend the only method of vault running on EC2, fully support kubernetes, and I saw several of my ideas/feedback listed almost verbatim in the documentation I saw (note, I am not accusing them of plagiarism - these were very obvious complaints that I'm sure I wasn't the only one raising after a while).
It always surprised me how these conversations went. "Well we don't really recommend kubernetes so we won't support (feature)."
Me: "Well the majority of your customers will want to use it this way, so....."
Just was a very frustrating process, and a frustrating product - I love what it does, but there are an unbelievable amount of footguns laden in the enterprise version, not to mention it has a way of worming itself irrevocably into your infrastructure, and due to extremely weird/obfuscated pricing models I'm fairly certain people are waking up to surprise bills nowadays. They also rug pulled some OSS features, particularly MFA login, which kind of pissed me off. The product (in my view) is pretty much worthless to a company without that.
The reasoning is basically that there are some security and isolation guarantees you don't get in Kubernetes that you do get on bare metal or (to a somewhat lesser extent) in VMs.
In particular for Kubernetes, Vault wants to run as a non-root user and set the IPC_LOCK capability when it starts to prevent its memory from being swapped to disk. While in Docker you can directly enable this by adding capabilities when you launch the container, Kubernetes has an issue because of the way it handles non-root container users specified in a pod manifest, detailed in a (long-dormant) KEP: https://github.com/kubernetes/enhancements/blob/master/keps/... (tl;dr: Kubernetes runs the container process as root, with the specified capabilities added, but then switches it to the non-root UID, which causes the explicitly-added capabilities to be dropped).
You can work around this by rebuilding the container and setting the capability directly on the binary, but the upstream build of the binary and the one in the container image don't come with that set (because the user should set it at runtime if running the container image directly, and the systemd unit sets it via systemd if running as a systemd service, so there's no need to do that except for working around Kubernetes' ambient-capability issue).
> It always surprised me how these conversations went. "Well we don't really recommend kubernetes so we won't support (feature)."
> Me: "Well the majority of your customers will want to use it this way, so....."
Ha, I had a similar conversation internally in the early days of Boundary. Something like "Hey, if I run Boundary in Kubernetes, X won't work because Y." And the initial response was "Why would you want to run Boundary in Kubernetes?" The Boundary team came around pretty quick though, and Kubernetes ended up being one of the flagship use cases for it.
My feeling is that for the average company operating in a (single) cloud, there’s no reason to use vault when you can just used AWS Secret Manager or the equivalent in azure or GCE and not have to worry about fucking Etcd quorums and so forth. Just make simple api calls with the IAM creds you already have.
"Linux Foundation joins IBM to accelerate the mission of multi-cloud automation and bring the products to a broader audience of users and customers." ;)
So yeah, one can always fork the last available version, if it then survives to the extent that actually matters beyond hobby coding is seldom the case.
How many Open Solaris forks are actually relevant outside the company that owns those forks?
Also IBM, Microsoft, Oracle,.... and others that HN loves to hate are already members.
Regardless of various things that have happened, or things that could have been, the company has pushed the envelope with some absolute bangers and we are all better for it, directly or indirectly.
Regardless of what the general opinion is of Hashicorp’s future post-IBM, they made an impact and that should be celebrated, not decried or sorrowed over for lack of a perceived picture perfect ending.
Such is life.
1. https://tomforb.es/blog/dell-system-detect-rce-vulnerability...
2. https://www.hashicorp.com/about/origin-story
Confirming what everybody knows, IBM views HashiCorp's products as Terraform, Vault, and some other shit.