Hacker News Reader

Comment by tedivm | Hacker News Reader

It's important to note that they are holding off on deprecating dependents to see if they can swap in replacements. For example, programs that depend on Terraform will likely be able to use OpenTofu as a replacement.

Unfortunately it doesn't seem like there are going to be open source alternatives to Vault, Consul, or Nomad (that last one is hilarious to me: nomad was a good product until hashicorp stopped investing in it, now that it's closed source it basically has a snowballs chance in hell of being adopted).

View on HN

If anyone does start an open Vault fork, I'd be interested in contributing as I get time.

Edit to add: https://github.com/hashicorp/vault/graphs/contributors?from=...

I wish I had the time or energy for it- especially with someone like you willing to contribute. I really hope someone takes up this task.

I like Nomad a lot. It is even more lightweight than k3s and has served my low-budget projects very well. A little sad to see things are going this way.

Nomad was overly ambitious in running everything under the sun. Didn't catch on. Setting it up would also require Consul. Docker swarm is simpler and superior solution to Nomad and is built right into docker engine itself.

I would rather sink in an ocean of kubernetes YAML documents than having to deal with Docker swarm issues ever again. Thankfully Docker swarm is kinda dead so it’s unlikely to be relevant again. Kubernetes won.

I like what kube achieves, I don't like the power and memory hungry requirements of it, it seems ill optimized. A cluster with no pods uses 5%-15% CPU, that's a lot of electricity being used for nothing. It's really odd since Google claims to have green datacenters.

I'd bet you're running a "stacked" control plane and if you moved etcd off to its own machines you'd localize the churn to be that. Which, if correct, doesn't exactly refute your "kubernetes is power and memory hungry" claim but would more clearly distinguish why

I had high hopes back in my earlier days of them offering pluggable KV stores so folks could make tradeoffs if etcd doesn't align with their goals and risks but as best I can tell they've declared it a non-goal

That's part of what k3s does

Does Google use carbon swaps to conceal their emissions? Maybe that's how they reconcile the difference.

A quick search turned up this: https://www.greencentury.com/google-parent-alphabet-pledges-...

Looks like a possible case of greenwashing to me.

I got into an argument with someone at google who said they don't use carbon swaps and ended up pulling up a shareholder report that said they did. Google is real big on the greenwashing.

Google doesn’t use kubernetes to run anything production. They use Borg

I'm curious, are you seeing that on cloud instances, or what?

My experience with bare-metal Kubernetes hasn't been that bad. On my home cluster with very underpowered J4105 CPUs, I get about 5% CPU usage on the master node at idle, and 2% on workers.

People need to check their logs for any oddities more frequently. A lot of the setups I’ve seen have subtle misconfigurations that leak/busy loop resources needlessly

Google doesn’t run on Kubernetee.

Kubernetes won because of its composability. The API is the killer feature. The notion of objects, labels, pretty much an object oriented, declarative interface.

You'd have to do a lots of custom morphing if you want that kind of interface over docker swarm.

For smaller setups, simplicity of docker swarm might be useful but I am curious to know from people who are running clusters of 25 to 50 nodes.

I've actually been using docker swarm for an odroid cluster that runs a lot of services in my house. I really like it- it's extremely low overhead and the network mesh works way better than I was expecting considering I put no effort into configuring it.

That said this is a three node cluster running a handful of containers, with services accessed by my wife and I. So not exactly a large scale production experience.

As someone whose wife will immediately call me if the important services in our household (Plex, pihole, home assistant), I think those definitely count as production services!

Can you elaborate on its issues? I've never used it on production myself, but it looks like a simplified k8n, which is something I feel a lot of people desire

Last used it years ago, networking would just die randomly, requiring container restarts when using multiple nodes

I have heard (though haven't tried) that V2 of Compose/Swarm is significantly better.

Anything can and will break. Symptomatically similar thing happened to me with K8s with (IIRC) Calico. And I’ve had issues with Swarm too, although of a different kind (it quietly refused to run a data channel for me over an IPv6-only network, while control channel worked just fine).

It was all quite a while (3-4 years) ago, so I don’t remember much details, except that Swarm was then not exactly capable of working in IPv6-only environments. It was significantly easier to navigate Docker’s codebase than Kubernetes’.

(Ultimately, my solution was that I understood that I didn’t need any kind of orchestration there, just HA/failover. But that’s another story.)

I haven’t used it for many years but in short it just didn’t work reliably. I mostly encountered network iptables issues from memory.

I've been very happy with until now, though i must admit i'm using one node swarms. But i'd rather use that (1) than sticking together a custom solution using docker compose as i see it mentioned sometimes.

(1) https://dockerswarm.rocks/traefik/

Infinite issues with overlay networking once you scale past 30 nodes in a swarm. Weave aside, network drivers for anything not CNI are basically deprecated/dead.

With Nomad 1.3 and newer, you can run a Nomad cluster without Consul, there's support for built-in service discovery: https://www.hashicorp.com/blog/nomad-service-discovery

> Docker swarm is simpler and superior solution to Nomad

This is the voice of absolute delusion. Swarm is a mess. Nomad actually scales.

Having worked with Nomad, K8s and Docker Swarm at reasonable scale, Docker Swarm is the only one of those three that I would never use again under pain of death.

I am a happy swarm user for a long time now. It is pretty simple. The only complicated part was the reverse proxy, but traefik has been a solid solution.

You will spend quite some time figuring the labels out, but once you have them for one service, it works for many.

A new solution that might be even better is Kamal by 37 Signals. It runs all their production stuff, so it must be capable. Can’t wait for a version 2 where, I’d suspect, by then there will be more community contributions for some more diverse setups merged in.

Recent nomad versions replace lots of consul functionality. Consul is definitely not needed at small scale, even for service discovery.

Honestly, all Hashi products are generally really good. I do think they do suffer from moving too fast syndrome. They pushed to go public and most or all of their recent shortcomings can be traced back to trying to push stock prices.

Early Hashicorp was incredible. They were open source stewards and looked like an up-and-coming Redhat or Canonical. Their products were ground-breaking and truly huge value adds to the open-source eco system. But they got extremely popular (mostly thanks to Terraform, which took off and drew more attention to their other products).

But since going public it has been clear that they are trying to get money and enterprise customers at any cost.

Terraform itself has felt like it was in maintenance-mode since hitting version 1. Terraform providers frequently break. For production I have found you need to pin providers down to the patch level, because i've had multiple problems just in small patch-level updates over the recent years. They famously started rejecting any open-source contributions that didn't provide a business value for Hashicorp. Since TF hitting v1, almost all the attention seems to be towards Terraform Cloud and Terraform Enterprise. At Hashicon, it feels like every talk is just propaganda pushing these products. It is all they care about anymore.

Nomad was a product that Hashicorp was very excited about for a while and then they seemed to just abandon on the side of the road in their quest for enterprise dominance (probably after learning that most Enterprises are all-in on K8s and Nomad is more beneficial to fast-moving start-ups).

Vault was an incredible tool, especially in the Open-Source space. But in the past few years they have really split the open-source and licensed versions of Vault significantly which made the open-source version feel more like a burden to Hashicorp. The last time I talked to Hashicorp about Vault (we were deeply considering a switch to Vault at work last year), they treated the open-source self-hosted solution as a "trial" of the real Vault, and that is what it felt like. Almost everything we ran into during setup, they would respond back with "oh that's fine in the enterprise version".

Overall, they have peeled back on all but the absolute minimum efforts required to support their open source versions of products and have been an entirely enterprise focused company for a while. And I can't blame them, sure you need to make money. But I can't help but point to organizations like RedHat and Canonical as examples of what Hashicorp could have been.

At this point I feel like the parent that watches their kids, talking about how they missed out on reaching their potential, thanks mostly to what seems like greed or over-ambition. "I'm not mad, I'm just disappointed" comes to mind when I think of Hashi. I have high-hopes for OpenTofu to fill the Terraform void. I've moved past Vault and am using one of the big hyperscalers' secrets management tools (which I enjoy a lot less, but is cheaper and less complicated). I use kubernetes instead of Nomad, which again is fine, it has become the standard anyway. So i'll be just fine... but I'm dissapointed at you Hashicorp. That's all.

> But since going public it has been clear that they are trying to get money and enterprise customers at any cost.

And yet, as an enterprise customer, their sales team is terrible. Incredibly unhelpful with problems, not willing to discuss pricing, ultimately lost the deal due to how unresponsive they were, and how they basically told as that they wouldn’t be any more likely to fix all the bugs we were hitting if we paid.

The reason they had to go this route is they are getting trounced by their competitors and it’s all their own fault

I wonder if this downhill trend has been in the works for years. In early 2018 I wrote a post[1][2] about my frustrations with interviewing with HashiCorp.

TL;DR: they put me through an interview gauntlet, took my entire day, and ignored me for weeks until I aired my frustrations in their contact us form.

I haven’t used their products since but always heard great things about them. That enterprise push is fierce.

[1]: https://blog.webb.page/2018-01-11-why-the-job-search-sucks.t...

[2]: https://news.ycombinator.com/item?id=16127697

Not at HashiCorp, but I try to respect applicants' time in interviews, and my overall process is less than 3 hours total for interviewing, across 4 people (all of which are self-scheduled). That said, when you have hundreds or thousands of applicants, people inevitably fall through the cracks unless you have an internal recruiting team entirely focused on maintaining that experience.

Interviewing sucks for everyone on either side, and efforts to improve candidate experience on my end have often been met with resistance in the company. One thing I've done is try to be as clear as possible at the end of interviews where someone stands. If it doesn't go well, I try to relate what didn't go well and how it applies to the position we're hiring for. If it goes well, my interviewers and I try to send out invites for the candidate to schedule the next interview within 10 minutes of completion, and I tell them that during the call.

So many companies are so risk-averse though, that they act like interviews are a poker game. I've generally had nothing but positives with my approach, and yes, someone may sue us at some point for being blunt and upfront, but my experience so far is people appreciate honest feedback if you deliver it kindly on the spot.

> One thing I've done is try to be as clear as possible at the end of interviews where someone stands. If it doesn't go well, I try to relate what didn't go well and how it applies to the position we're hiring for.

I tried doing that last time I hired and I think generally speaking makes a good experience for candidates, BUT when you have those 2-3 individuals that have really high opinions of themselves it can get tiring for the hiring manager (myself), because they won't accept the answer anyway and will keep asking and ultimately give some bad review in Glassdoor etc

I don't have too much issue because when it's bad, it's usually because they've failed pretty hard on tech screens for questions that have absolute answers. I have on one occasion had to pull up my IDE and run code and prove my questions to an argumentative candidate, but generally people appreciate the explanations when they are wrong and tell me they've learned something.

I prefer bluntness as that's my personal style. I'm glad you're pushing through, even despite resistance.

Every person I interviewed with at Hashicorp seemed to enjoy the conversation and the live coding challenge wasn't particularly challenging. Ah well.

Rejection is protection and redirection.

The second comments section, could have been all from today. Nothing about hiring has changed in 5 years lol

Wish I could say I was surprised

The enterprise versions of their products are ridiculously expensive. They're always trying their best to charge you with mistakes (e.g. number of connecting clients). The pricing on the landing page is just a fraction of the real price. That's a big turn-off for me. It's true that I don't want to have the hassle of setting up a production-ready Vault, but seriously, if Hashicorp keeps charging like that I'd would really consider a different solution.

I appreciate Hashicorp, but early on I had a bad taste in my mouth. I paid for their first commercial offering, the VWWare adapter of Vagrant. I had a conversation with Mitchell (can't remember the exact context) around an issue I was encountering, and remember him being pretty dismissive toward what I was asking. Again, I'm sure there's a lot of context I'm not remembering, but I had the feeling that they used their early revenue as their launching pad and were more focused on the next big thing than giving treating their customers as the asset that they were.

Yeah, that was a waste of money. Didn’t work well at all

Wait is Nomad really closed source?

Nomad, along with the rest of Hashicorp's flagship products, transitioned to the BUSL-1.1: https://github.com/hashicorp/nomad/blob/main/LICENSE

Am I misunderstanding something? I thought BUSL means the source is still open, but not free as in freedom.

Perhaps a more apt term would be freeware.

The BUSL is not OSI approved and places restrictions around usage, in an effort to sell some product or service off of a project and prohibit competition. It is not free as in beer either, if you hit such usage.

The source is available (hence source available being another terminology) but even Hashicorp has dropped "open source" from nearly every relevant page in understanding that their products no longer have an open source core (see instead "Vault Community" or "Terraform Community").

The general consensus is that no, the BUSL is not OSS as OSI has not blessed it as such: https://opensource.org/licenses/

Thanks.

It's true that Hashicorp's source is still available, but you might not have permission to use it or modify it any more. Even if you can read it legally. Under their new license, Hashicorp can essentially revoke any commercial user's license to run Hashi software, and there is nothing the business can do except pay. They can do it at any time, if the business has any divisions that do anything close to competing with any Hashi product.

> Am I misunderstanding something?

Yes, source being available is not enough to be called open source.

It's worse in some ways because if you read the source and then work on another open source project in the same field you could end up in legal trouble.

Nomad looked like a good product until I used it. I was so looking forward to a simpler take on orchestration, having spent years in k8s-land and generally being a fan of Hashicorp in the past.

My tldr now is nomad should be considered harmful.

I’ve started playing with Nomad recently just to see what it’s all about. There are some annoying things with networking, but overall it’s been pretty fun so far. What made you consider it harmful?

The number one issue is that deployments are blocking, and scaling is a deployment. That means during a deployment, scaling is disabled. This makes safely deploying to thousands of containers during scale-in hours extremely dangerous. Combined with nomad-autoscaler being a SPOF and crash-happy, the always-be-deploying startup with a daily traffic pattern should not use Nomad.

It’s also nontrivial to get nomad to be resilient. For example, if your template uses keys from consul or vault, even with “noop” mode, and consul or vault are unreachable, Nomad will happily start killing running containers that had been rendered correctly in the past, because it can’t re-render the template. This pattern has only recently been addressed by “nomad_retry” but there have been several bugs with it, and 1.6.2 will currently kill all running containers if some template resource can’t be reached. Under the hood this uses consul-template, which does support infinite retry, but getting nomad to use consul template safely is non trivial. Eg: vault tokens expire so infinite retry for vault doesn’t work as-is.

Node_pools just landed (2023!), and are still broken when using Levant (another abandoned nomad tool - think kustomize with a much more horrifying DSL).

Bonus issues: they’re still trying to get cgroups v2 working, the current version finally doesn’t DOS your backend services in an infinite loop, the UI lies, deployments can get stuck forever because “progress_deadline” is more of a suggestion than a deadline, nomad-autoscaler is not highly available, crashes very easily, often scales faster than its “cooldown” window, and is simply stupid. AWS Karpenter feels a full decade into the future.

And all that so I can write my own Nomad specs instead of installing a vendors helm chart in a network isolated namespace. Boo.

To reiterate, I’ve liked Hashi for years and years, and I don’t have any ill will towards them. Just shocked at how poor nomad is compared to k8s. It’s definitely more fun than k8s when getting started, for sure.

Recent version of Nomad has introduced many QoL features like secrets and service discovery, though logging collection remains unsupported.

> though logging collection remains unsupported.

Do you happen to have a link to the issue (I guess or docs, if it's their official stance)? I'd enjoy reading how they ended up in that circumstance

Logcollection doesn't come out of the box, and you're kinda on your own to set it up, this article (although a bit dated) shows you what you must go through:

https://atodorov.me/2021/07/09/logging-on-nomad-and-log-aggr...

It also doesn't help that Nomad handles everything from Docker containers to managing regular applications.

Also worth noting that nomad’s closest competitor (Kubernetes) does not do this either. It’s a huge oversight in both ecosystems.

We may be talking about different things, but GP's comment said "unsupported" whereas in kubernetes it's just not part of the control plane offered by kubernetes itself, in exactly the same way that cloud load balancer or even cloud auto-scaling isn't provided by kubernetes itself

Having read the sibling's comment, I think I better understand the situation since Nomad isn't a container orchestrator and thus there isn't one homogeneous place from which _to_ collect the logs, but in any sane k8s setup that's not true since both dockerd and containerd have mechanisms to influence that behavior and k8s is perfectly able, and supports, scheduling per-Node utility plumbing stuff like that without drama

Yes k8s does not provide a out-of-box logging collection solution but since everything is in containers, we can piggyback on Docker or Containerd via deamonset to get all the logs.

Nomad on the other hand support various payload(native exec, exec via chroot, containers, even Firecracker VM by community support), so doing logging collection by end users is trickier. It worth noting that Nomad UI(a official web admin panel) has log tailing utility built-in so maybe partial work has already been done. The developers may have other concerns.

The related issue is https://github.com/hashicorp/nomad/issues/10220

All of the work has been done; not partial work.

Nomad has equivalent mechanisms for collecting logs to Kubernetes. None are built in, in either platform.

Would you like to provide a link? It would help me a lot. Thanks.

https://developer.hashicorp.com/nomad/docs/job-specification... covers much of it from the collection side

Reply on news.ycombinator.com