Honestly my turn off was seeing Google Cloud and later DigitalOcean providing managed versions of it. If they see value in doing that I assume it's gonna be a pain in the arse to solo sysadmin it.

I later realised my blog and little side projects do not need a cluster but that's another story. I was mainly looking at it to learn than to properly utilize

Completely off topic, sorry. Whatever happened to Flynn.io? That was my favorite of the clustery things but it just sort of fell off the internet

e: oh. Answered by visiting the site just now. "Flynn is no longer being developed." that is a shame.

I just started using CapRover (https://caprover.com/) for hosting some side projects, it was extremely easy to set up and appears to work similar to how Flynn.io used to.

It's really only in the last couple years that kubernetes has started to get tamed and be more approachable. For the longest time the only way to get a simple dev cluster up on your laptop was to make a VM with like 8-16GB of RAM and four cores dedicated to it--it was pretty outrageous. Nowadays kind, k3s, etc. make it a simple one line install and sip resources. But I agree, there is definitely a misperception that k8s is too complex.

I wouldn't call it a misperception. It does orchestration, service discovery, resilience, secrets management (which is a joke, but still) and whatnot. That's definitely a lot of complexity. Mixing it all together doesn't help with making it easier to manage, on the contrary.

Is it? If GCP are launching an even more managed version of their managed Kubernetes because the current one is too complex for some, i'd say it isn't that hands off, even with a managed service.

It's gotten drastically better, but updates are still serious work ( point in case, all cloud providers bar Scaleway are usually multiple versions late)

It's a thing of personal preference and requirements. I can easily see that there are requirements where Nomad is a better fit. However, I also have to say that Kubernetes has clearly won the battle a will be the safe choice for most companies for the years to come. It will be much easier to find knowledgeable DevOps and SRE workforce for k8s, than any other orchestrator alternative.

Any engineer worth his salt will be able to hit the ground running on both systems pretty quickly. The concepts are pretty similar.

> Any engineer worth his salt

... will build deep understanding and accumulate knowledge over the years. I won't deny that you could learn Nomad fast, but becoming an expert in some domain really takes some time.

It's the old Douglas Adams joke. The difference between a thing that can break and a thing that cannot break is that when a thing that cannot break breaks, there's no way to fix it.

I don't entirely know if this joke matches the reality of Nomad vs K8S, but that's probably the general sentiment. Bigger usually implies harder to fix.

> I don't get why people are so afraid of kubernetes, the thing is pretty much hands off.

To be fair, this time around the ones afraid of Kubernetes are the companies trying to sell a Kubernetes competitor.

To be clear, i ( the author of the article) am not affiliated with Hashicorp in any way besides using some of their ( free, open source versions) products.

I just used Kubernetes at work, inherited a poorly maintained cluster, and when time came to change, due to very limited time available, we opted for Nomad. Few years in, i'm telling what i've learned ( while still running a k8s cluster for home use, so i'm not entirely disconnected from the k8s ecosystem)

I see, I apologize for the unintended misrepresentation.

However one of the things I jumped into the assumption that the blog post was stealth advertising for Nomad was a few exaggerated claims that feel quite a stretch to be able to come up with anything in favour of Nomad over Kubernetes.

One of them, for example, is that

Nomad is supposed to be "significantly easier than microk8s or minikube or kind" to run locally as a dev environment. Well, anyone familiar with minikube is well aware that to get it up and running you only need to install it and kubectl, and quite literally just run 'minikube start'. Nomad agent is not only far more convoluted to get up and running according to Nomad's official documentation, but it is also explicitly stated that it's use is highly discouraged. Don't you feel that you're misrepresenting Nomad's selling points?

I see.

> Nomad is supposed to be "significantly easier than microk8s or minikube or kind" to run locally as a dev environment. Well, anyone familiar with minikube is well aware that to get it up and running you only need to install it and kubectl, and quite literally just run 'minikube start'

It would appear that i wasn't up to date on minikube - last time i installed it ( it was a few years back, and since then i've switched to microk8s for local stuff), it required a VM intermediary and driver, but that's no longer the case, direct Docker being supported. That's drastically easier than it was before, but there's still a slight advantage to Nomad (see below).

> Nomad agent is not only far more convoluted to get up and running according to Nomad's official documentation, but it is also explicitly stated that it's use is highly discouraged

How so? Download a binary, run `nomad agent -dev` and that's it, there's nothing convoluted. It's highly discouraged the same way minikube is - for production use. With `nomad agent -dev` you get a local ephemeral Nomad instance you can do whatever you want with, but should never use it for production use.

The small advantage i talked about is that minikube is a separate thing you have to download ( and there's minikube vs microk8s vs kind); with nomad, it's the same one as the CLI you need to interact with the cluster. So i'd be like there was `kubectl minikube start`, and that's it - you can go from working with a cluster to having a local one for testing in a command. Very slight advantage, indeed, but still one IMHO.

I think you have to ask yourself - why are you running Nomad locally as a dev environment? It's indeed very useful to test running jobs on Nomad just to learn it, but to develop using Nomad would be defeating the purpose. Just develop your own code as usual, e.g. with a Python stack you end up with a docker container and on Java you end up with a JAR file you can run from Nomad.