Nomad can do everything that K8s can
mrkaran.dev
mrkaran.dev
This is just a very weird comparison. Seems like the author doesn’t understand why people run K8s.
Of course they also “managed” several k8s clusters using… wait for it… AWS.
I’d say, when you are all in AWS, then fine don’t use k8s. But you also don’t need Nomad then in most cases.
And if you do need nomad on AWS then that’s fine as well, but it’s not comparable to k8s in general.
And if self-hosting Nomad on AWS is (allegedly) so much easier than operating managed k8s (EKS), isn't that more damning rather than less?
The all-in AWS answer I suppose would be ECS. I quite like it but I think for anything beyond small, more than a few services part of the same system, I can understand wanting to run Nomad (or use EKS) instead.
The problem with running databases yourself is that it's hard to run databases, and having dedicated physical hardware works, until it doesn't. Nomad make it easy to run dedicated physical hardware for it. As soon as you have a failed EBS volume with your DB on it. Failed EBS volumes still happen frequently, though we've mostly obviated the problem by using managed dbs.
Know a few people who run hundreds of them too.
And it's perfect for dev shit were colleges pull in their PostgreSQL themselves until later through helm dependencies
See for example you can write safe code in C therefore rust is pointless (yes but rust makes it much easier to write safe code)
Or you can do machine learning in JavaScript so python is useless (you can but it’s a much smaller ecosystem)
Etc etc.
You can pick whatever tools you want for whatever reason but please give me a better reason than it *can* be done.
Isn't it usually the other way around? "This would be safer if written in rust".
> Or you can do machine learning in JavaScript so python is useless
Said no one ever.
The author also elaborates why (according to him) X is preferable over Y (mainly simplicity), and even if he didn't there's value in comparing tools if one is on the fence of switching but afraid of loosing compatibility. Entire websites exist with that sole purpose.
> Said no one ever.
I want to reply to this point because I have some relevant & interesting experience here. I've done a fair amount of consulting for companies who have a scenario that goes like this:
- founder starts business in their free time, in a language they know well, as a monolith.
- founder gets a few customers and decides to scale the business
- founder decides they need to use "AI" to solve some business problem
- founder hires a person who is great at solving that particular problem.
- that person wants to use python (of course they do) but the monolith is not in python so various tensions ensue.
- the founder (or someone else on the engineer team) inevitably says "you can do ML in $LANGUAGE_WE_CHOSE, why use python? We didn't chose python because $REASONS_PYTHON_SUCKS.
You'd be surprised how often the language they chose is javascript and how often the reason not to use python is that they can't share code between the client and server. So unfortunately that example wasn't pulled out of nowhere
And if that criteria is good enough to justify its use then surely it's enough to justify the use of an alternative.
Frankly, the majority of software houses running K8s really don't need to.
People like k8s because it's fully open source and community driven.
Moving to another provider feels like the selling point of ORMs (moving to a different db engine), whereas most often it will never happen.
It's fine that you use k8s and it looks like it's the perfect fit for your case, but tech often thinks "my solution" equals "everyones solution".
To your point about this being like ORMs, though: I would argue building apps to deploy with Kubernetes or Ansible is less like using an ORM, and more like building them to compile for any OS rather than depending on Windows/Linux/macOS libraries. DB engines generally have much more similar costs than server hosting companies do (you could pay 2x as much to host an app on one vs the other depending on what you need), so it makes less sense to switch. (Also, back in the days when ORMs were created, Oracle was much more dominant than today so DB cost differentials were a bigger issue, but that’s not really today’s market. These days many engines just offer wire compatibility with Postgres/MySQL libraries anyway, so that aspect of ORMs is really not the selling point anymore, it’s the mapping of DB type systems to language type systems.)
Kubernetes has a lot of merits and open source community support which is attractive which means out of the box integrations are vast.
That said, Nomad builds in a lot of sensible default behaviors that are way way closer to production ready with significantly less effort. Many things in Nomad, with Consul and Vault “just work” like you’d expect. Some of it seems like magic.
Kubernetes on the other hand does almost nothing for you to make your custom app production ready out of the box. This means there’s a ton of room for error and incorrectly configured applications. CNIs, Ingress, PodAffinity, PodDisruptionBudgets, Services, HPAs, ServiceRoles, Secrets management are not defined for you and must be exactly correct or orchestrated in clunky and obscure ways, or a ton of effort needs to go into filling these gaps. “Just use EKS/GKE” quickly becomes a list of subsequent decision trees and you need to hope yoy made the right decision because if you don’t your choice will be deprecated in 6-9 months.
The two config options for Kubernetes are Helm/Kustomize Yaml. Both are great for quick POCs but at production scale are completely inferior to HCL and generally an absolute nightmare to work with on the day-to-day.
If I’m a team of one in a startup, I’d choose Nomad.
Putting down your competitor is a very fine art if you don't want to come across as a douche. Done correctly it can be hilarious though. But this is just a bull in the china shop.
As far as I can tell, the author of the article doesn't work for Hashicorp (Nomad) nor Google (Kubernetes) so not sure why you're giving this unsolicited advice?