I think typical premium is about 20% for acquisitions.
The amount may have been negotiated prior to this month's downturn, which Hashicorp was hit pretty hard by (they had about a 10% fall based on what I'm seeing).
Yea, I think it often depends on where a company's stock has moved recently. IBM's offer is still below HashiCorp's 52-week high. That means there's probably a lot of current investors who likely wouldn't approve a deal at a 20% premium. If your stock is near its 52-week high, then a 20% premium looks a lot more reasonable.
April-August of last year, HashiCorp was regularly above a 20% premium over Monday's close. Many investors might think it would get back there without a merger - and it had been higher. IBM is offering $35/share which is close to the $36.39 52-week high. In some cases, investors are delusional and just bought in at the peak. In other cases, a company's shares have been under-valued and the company shouldn't sell itself cheaply.
I don't think one can really have a fixed percent premium for acquisitions because it really depends. Is their stock trading at a bargain price right now? Maybe people who believe in the stock own a lot of the company and don't have more capital to buy shares at the price they consider to be a bargain - but would vote against selling at that bargain price even if they can't buy more. They're confident other investors will come around. An acquiring company wants to make an offer they think will be accepted by the majority of investors, but also doesn't want to pay more than it has to. If the stock has been down and investors think it's a sinking ship, they don't have to offer much of a premium. If the stock is up a ton and investors sense a bubble, maybe they don't have to offer much of a premium. If the stock has been battered, but a lot of shareholders believe in it, then they might need to offer more of a premium.
Analyst consensus I've seen on long-term price has been floating around $32-34 per share. Take that with as much salt as you think it needs but it's at least interesting that it's within shouting distance of (but not over) the IBM offer.
"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 bet they'll organize it under Red Hat, and Red Hat will apply their open source policy to it, and that will involve reverting to OSI approved licenses
I mean, they bought Red Hat, and killed CentOS; I can say after 25 years in enterprise IT, I have zero trust in IBM to keep any open source licensing "open".
They where under IBM ownership at the time, so IBM did kill it. The software now branded as CentOS is basically Fedora, which is fine for desktops, but never felt good on servers. CentOS was perfect for a lot of us SysAdmins back in the day to use on our own servers etc, while using Red Hat at work. We also used it for anything PoC or servers that did not require support. These days licensing is easier using models like AWS Subscriptions, but we used to buy licenses in bulk, and if there where not enough licenses, we had to do the whole procurement dance.
Side note, in the 12 years that I used Red Hat at work, we used the support 2 times, and both times they forwarded some articles that we had already found and implemented. However, enterprise always demands some support contract behind critical systems to blame in case of disaster.
Honestly, who knows what would have happened if Red Hat was left as an independent entity, but we do know for sure that they did make the changes after the acquisition.
I work at Red Hat. IBM was not involved in the decision to kill CentOS.
>The software now branded as CentOS is basically Fedora
CentOS Stream (what replaced CentOS) is vastly more similar to CentOS than Fedora.
It's CentOS with rolling patches instead of bundling those same patches into minor releases every 6 months. Only the release model is different from RHEL / CentOS, otherwise it's built the same and holds to the same policies in terms of testing, how updates are handled and compatibility.
Fedora on the other hand is very, very different. Packages are built with different flags, different defaults (e.g. filesystems), very different package versions, a different package update policy (even within one major release Fedora is much more aggressive than CentOS Stream / RHEL / CentOS), etc.
I understand that not having an near-exact replica of RHEL supported for 10 years was very convenient and the way the EOL was announced, and the timelines, sucked massively. But CentOS Stream is suitable for a large number of the use cases where CentOS was used previously, it is not "basically Fedora". It's more like 98% RHEL-like wheras Fedora is doing something else entirely.
That doesn’t seem like what’s happening from first appearances. Looks like it’ll remain separate for now which means no RH influence to fix the licensing boondoggle.
Yes. I did this a while back: https://github.com/radekg/terraform-provisioner-ansible. That received some contributions from IBM. Unfortunately, HC never wanted to maintain it, then in 0.15 they replaced provisioners with providers or plugins (can’t remember anymore). I had a couple of discussions with their OSS head for TF at the time but the bottom line from them was „why don’t you rewrite it in your spare time”. The problem was their replacement didn’t give access to the underlying communicator (your SSH or winrm). So I hung the towel.
I worked at a startup that got acquired by a big company and we switched our custom proprietary license back to Apache 2 after acquisition. The reason we switched in the first place was because it's what we thought was best when we were out on our own. Being owned by a hardware company, you can have the software for free. (We still sell licenses and have a cute little license key validator, though.)
Once again, thank you 'mitchellh for Vagrant, I'm sure you have heard this many times before but it really changed the way we worked for the better in every way.
The good news is, you no longer need Dhall or some crazy scripts to generate your Terraform files. Just a bit more XML and an XSLT stylesheet oughta do it!
Not unexpected, I saw a comment a ways back when they started with the BSL stuff that it had nothing to do with terraform, but was a response to IBM selling Vault.
"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.
Exactly. Now that they own it, they can just roll back the license change and tap into the rest of the world doing the heavy lifting in terms of development. Hashicorp retired from that role when they changed the license.
Win win for IBM. They offer stability to their big corporate clients and they get to resell the work done by third parties. The BSL license is an obstacle to that because it means they have to reinvent wheels internally. Changing the license back means they can gut the R&D department at the price of a simple license change and focus instead on sales, support, and consulting.
Nomad has a remarkably strong community for it's size. I'm almost positive it will continue to live in some format, even if completely hard-forked.
I know if nobody else does anything I will do something myself, personally.
I love Kubernetes, however I feel like things like Nomad and Mesos have a space to exist in as well. Nomad especially holds a special place in my tech-heart. :)
> Nomad especially holds a special place in my tech-heart.
Same. I'm not a fan of the recent licensing changes and probably won't use it for any new installations, but Nomad enabled me to be an entire ops team AND do all my other startupy engineer duties as well with minimal babysitting. It really just works, and works fantastically for what it is. Nomad is like the perfect mix of functional and easy to manage.
There doesn't seem to be enough forces to create a MPL fork but at the same time we have a gap between "Docker Compose is enough" and running Kubernetes. Because there are many situations where going Kubernetes (or even lighter k0s, k3s type setups) does not make any sense.
My guess is no organisation which can afford to dedicate resources to contribute or create a fork need Nomad. So we end up with a big gap in the ecosystem.
Here's hoping they don't run great tools like Consul and Nomad into the ground somehow. If I'm ever forced to ditch Nomad and work with a pile of strung-together components like k8s I might just quit tech altogether.
Oh if only - it seems like somehow the shittiest culture manages to out survive the other and entrench itself inside the business. I know HN likes to blame this on the stock market forcing short term revenues but I think it goes deeper - the good "culture" employees actively flee these environments.
Boeing acquiring McDonald Douglas is a classic example of this exact scenario: "McDonald Douglas bought Boeing with Boeings money."
I wonder how this will work with Red Hat. Traditionally, Red Hat and HashiCorp competed more directly than other IBM portfolio products, fighting over the same customer dollars.
12x multiple for a Cloud SaaS company is not overpriced typically. I was surprised at this low multiple. Could be due to the current economic situation. And also the licensing changes, lack of product moat contributing in the wrong time.
Ugh, and have you actually looked at IBM’e share price? Or is it this because IBM isn’t cool to you? A bit rich for a community that’ll go work for shares in some dinky web app startup.
This type of comment appears here every time the name IBM shows up, but it is more symptomatic, of the bubble a part of HN lives on.
Think every core IT infra of most of the developed world countries, most of the ebanking and core messaging infra of your large banks and insurance companies, plus billions per year in consulting services revenue.
It is more than IBM used to be a big name in areas where hackers would be expected to be. They have left all those behind though. there are lots of other companies that none of us would recognize that are big, but IBM is a name that we all know as once somewhat important who now are not.
Right. If you are in the HN bubble, then 30 years ago IBM was a big name in computing as the inventor of the PC, OS/2, maker of a great keyboard, and a bunch of weird systems we never touched. They sold their PC and keyboard businesses, and let OS/2 die. We think some of those weird systems still exist, but those never were very relevant unless you had to work on them.
HN users are trendy. If you didn't grow up in the 1990s or before though you may not remember just how picked on this type of crowd was. Now while we are never exactly the "in" crowd, we are respected, being a "nerd" or "geek" is now an acceptable thing. We have come a long way and that is enough trendy enough for us.
Indeed, there's also a whole world of B2B software which you may be almost entirely unaware of if you've spent your whole career in consumer-facing web/app development.
IBM is essentially a large bank with a side business of tech. IBM is known for financially complex deals that are highly lucrative. They make their money by taking advantage of inefficiencies in the largest enterprises purchasing and technology teams.
As far as I can tell, the vast majority of the universe is completely incompetent with IT, but needs a lot of boring things done.
If you're a shipyard, an oil company, a bank, an automaker, etc. you still need software to manage things like inventory, employees, logistics, and similar, and you have zero expertise to do it in-house. They also have zero expertise to find a qualified vendor.
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.
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.
(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.
> Caveat: the HCP hosted vault is reasonably priced and works well.
HCP hosted Vault starts at ~$1200/month, you'd have to use a metric shit ton of secrets in AWS or GCP to come close to that amount. Yes Vault does more than just secrets, but claiming anything HC sells as reasonably priced is a reach.
Ah, they have changed the public pricing page. Maybe we were on a grandfathered in deal. They had a starter package between free and enterprise with configurable cluster options that was $60ish a month. We heavily used the policies, certs and organization features that made it a no brainer for that price point for things outside AWS like Heroku.
We were running about $12/mo in aws secrets with no caching and no usage outside our aws services. I taught the team how to cache the secrets in the lambda function and it dropped to a buck a month or less.
If they killed off the starter package then you are right, there are only outrageous options and HCP would not be worth considering for small orgs.
> 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.
Thanks for the detailed explanation - some of what you say sounds familiar, but this was nearly 5 years ago so my fuzzy recollection of their reasoning - I recall it being something like they didn't trust etcd being compromised on kubernetes. My counterargument to that internally was "if your etcd cluster is compromised by a threat actor you have way bigger problems to worry about than secrets"
My vague recollection is that that concern was that the etcd store (specifically the keys pertaining to the Vault pod spec) could be modified in some way that would compromise the security of the encrypted Vault store when a Vault pod was restarted. It's been a long time since I remember that being a live concern though, so I've mostly recycled those neurons...
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.
Hashicorp does so much more than terraform, but I don’t think OpenTofu is better than terraform. I’m not sure that was ever really an interesting issue, however, I think the main competition to terraform was/is things like Bicep.
I know the decision makers in our shop spent quite a lot of time deciding between the two. Finally decided on bicep after a number of what has probably been the most boring workshops I’ve ever attended. I’m fairly certain they are very happy with that decision now though. Not so much because big blue is evil, but because now we’re only beholden to one evil (Microsoft) and not two.
I don’t actually think Microsoft or IBM are evil. They are just not ideal from an European enterprise perspective because they are subject to an increasing amount of anti-non-eu legalisation and national/internal security issues.
Vagrant has fallen by the wayside supplanted by Docker and K8S.
Vagrant was the origin, but quickly went from FOSS to FOSS-washed when it reneged on VMware support as a premium-only, closed-source option.
IBM is indistinguishable from Progress and Broadcom... it buys things and milks them while they decline.
Microsoft just lacks taste and any sense of accountability for all of the vulnerabilities and exploit damage it has, and continues to, inflict on the world.
390 comments
[ 2.7 ms ] story [ 170 ms ] threadIs that an insane premium or what?
The amount may have been negotiated prior to this month's downturn, which Hashicorp was hit pretty hard by (they had about a 10% fall based on what I'm seeing).
April-August of last year, HashiCorp was regularly above a 20% premium over Monday's close. Many investors might think it would get back there without a merger - and it had been higher. IBM is offering $35/share which is close to the $36.39 52-week high. In some cases, investors are delusional and just bought in at the peak. In other cases, a company's shares have been under-valued and the company shouldn't sell itself cheaply.
I don't think one can really have a fixed percent premium for acquisitions because it really depends. Is their stock trading at a bargain price right now? Maybe people who believe in the stock own a lot of the company and don't have more capital to buy shares at the price they consider to be a bargain - but would vote against selling at that bargain price even if they can't buy more. They're confident other investors will come around. An acquiring company wants to make an offer they think will be accepted by the majority of investors, but also doesn't want to pay more than it has to. If the stock has been down and investors think it's a sinking ship, they don't have to offer much of a premium. If the stock is up a ton and investors sense a bubble, maybe they don't have to offer much of a premium. If the stock has been battered, but a lot of shareholders believe in it, then they might need to offer more of a premium.
Confirming what everybody knows, IBM views HashiCorp's products as Terraform, Vault, and some other shit.
Side note, in the 12 years that I used Red Hat at work, we used the support 2 times, and both times they forwarded some articles that we had already found and implemented. However, enterprise always demands some support contract behind critical systems to blame in case of disaster.
Honestly, who knows what would have happened if Red Hat was left as an independent entity, but we do know for sure that they did make the changes after the acquisition.
>The software now branded as CentOS is basically Fedora
CentOS Stream (what replaced CentOS) is vastly more similar to CentOS than Fedora.
It's CentOS with rolling patches instead of bundling those same patches into minor releases every 6 months. Only the release model is different from RHEL / CentOS, otherwise it's built the same and holds to the same policies in terms of testing, how updates are handled and compatibility.
Fedora on the other hand is very, very different. Packages are built with different flags, different defaults (e.g. filesystems), very different package versions, a different package update policy (even within one major release Fedora is much more aggressive than CentOS Stream / RHEL / CentOS), etc.
I understand that not having an near-exact replica of RHEL supported for 10 years was very convenient and the way the EOL was announced, and the timelines, sucked massively. But CentOS Stream is suitable for a large number of the use cases where CentOS was used previously, it is not "basically Fedora". It's more like 98% RHEL-like wheras Fedora is doing something else entirely.
5 years is less than 10, but it's a lot less different than 10 vs 1
But I could be totally off-base.
https://news.ycombinator.com/item?id=40149230
Now we know why!
https://www.ibm.com/docs/en/datapower-gateway/10.5.x?topic=2...
"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.
Win win for IBM. They offer stability to their big corporate clients and they get to resell the work done by third parties. The BSL license is an obstacle to that because it means they have to reinvent wheels internally. Changing the license back means they can gut the R&D department at the price of a simple license change and focus instead on sales, support, and consulting.
I know if nobody else does anything I will do something myself, personally.
I love Kubernetes, however I feel like things like Nomad and Mesos have a space to exist in as well. Nomad especially holds a special place in my tech-heart. :)
Same. I'm not a fan of the recent licensing changes and probably won't use it for any new installations, but Nomad enabled me to be an entire ops team AND do all my other startupy engineer duties as well with minimal babysitting. It really just works, and works fantastically for what it is. Nomad is like the perfect mix of functional and easy to manage.
There doesn't seem to be enough forces to create a MPL fork but at the same time we have a gap between "Docker Compose is enough" and running Kubernetes. Because there are many situations where going Kubernetes (or even lighter k0s, k3s type setups) does not make any sense.
My guess is no organisation which can afford to dedicate resources to contribute or create a fork need Nomad. So we end up with a big gap in the ecosystem.
Boeing acquiring McDonald Douglas is a classic example of this exact scenario: "McDonald Douglas bought Boeing with Boeings money."
IBM nearing a buyout deal for HashiCorp, source says - https://news.ycombinator.com/item?id=40135303 - April 2024 (170 comments)
Accelerate! Multi-cloud! Automation!
Additionally, you don't need the full purchase price in cash to buy the company. You can do leveraged buyouts, etc.
Hopefully someone at HashiCorp: "Hell no, cash please"
Think every core IT infra of most of the developed world countries, most of the ebanking and core messaging infra of your large banks and insurance companies, plus billions per year in consulting services revenue.
https://www.ibm.com/products
https://en.wikipedia.org/wiki/List_of_IBM_products
Again, HN users are in a bubble, and HN users think that they’re very trendy.
HN users are trendy. If you didn't grow up in the 1990s or before though you may not remember just how picked on this type of crowd was. Now while we are never exactly the "in" crowd, we are respected, being a "nerd" or "geek" is now an acceptable thing. We have come a long way and that is enough trendy enough for us.
https://en.wikipedia.org/wiki/List_of_mergers_and_acquisitio...
https://finance.yahoo.com/news/ibm-releases-first-quarter-re...
https://www.redhat.com/en/about/press-releases/ibm-closes-la...
I think they can find a few billions lying around, without having to turn the sofa cushions.
If you're a shipyard, an oil company, a bank, an automaker, etc. you still need software to manage things like inventory, employees, logistics, and similar, and you have zero expertise to do it in-house. They also have zero expertise to find a qualified vendor.
IBM is a safe bet.
That's a huge market.
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.
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.
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.
However, strong agree on using your home cloud's service.
We used Vault with Heroku and were happy.
HCP hosted Vault starts at ~$1200/month, you'd have to use a metric shit ton of secrets in AWS or GCP to come close to that amount. Yes Vault does more than just secrets, but claiming anything HC sells as reasonably priced is a reach.
We were running about $12/mo in aws secrets with no caching and no usage outside our aws services. I taught the team how to cache the secrets in the lambda function and it dropped to a buck a month or less.
If they killed off the starter package then you are right, there are only outrageous options and HCP would not be worth considering for small orgs.
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.
There's probably an alternate reality where something like HashiStack became this generation's vSphere, and HashiCorp stayed independent and profitable.
I know the decision makers in our shop spent quite a lot of time deciding between the two. Finally decided on bicep after a number of what has probably been the most boring workshops I’ve ever attended. I’m fairly certain they are very happy with that decision now though. Not so much because big blue is evil, but because now we’re only beholden to one evil (Microsoft) and not two.
I don’t actually think Microsoft or IBM are evil. They are just not ideal from an European enterprise perspective because they are subject to an increasing amount of anti-non-eu legalisation and national/internal security issues.
Waypoint and Boundary don't seem all that useful.
Vagrant has fallen by the wayside supplanted by Docker and K8S. Vagrant was the origin, but quickly went from FOSS to FOSS-washed when it reneged on VMware support as a premium-only, closed-source option.
IBM is indistinguishable from Progress and Broadcom... it buys things and milks them while they decline.
Microsoft just lacks taste and any sense of accountability for all of the vulnerabilities and exploit damage it has, and continues to, inflict on the world.