I'm genuinely not sure why they are trying to compete with the likes of Mesos or Kubernetes, or what they are really trying to achieve here. There is simply no way they'll build a community around nomad 1/2 as big as either of the aforementioned even if the software is really good.
This one is interesting to me. I've been a big proponent of Hashicorp's other tooling, but this seems like an area that other projects are already addressing (and doing well in). Choice is great, but I think I would have preferred if they joined up with Kubernetes/Mesos/etc.<p>Also, their messaging seems a little ingenious. Otto talks about how important it is to support microservice development and deployment, but Nomad lists as a con that Kubernetes has too many separately deployed and composed services.<p>PS, I do work for Red Hat, so maybe I'm a little biased.
No solution for persistent/statefull applications, which is a real disapointment, seeing as this is where I see orchestration systems currently breaking new ground and coming up with interesting solutions. The contraint systems also doesn't look too impressive; can I do the equiq of Marathon's GROUP_BY contraint (i.e. AZ GROUP_BY 2 -> ensure I have instances running on >=2 machines w/ different AZ values)?<p>Also no maintenance primitives, but that's just me being in love with Mesos.
I've been using Mesos with Aurora in production for almost a year and while its very stable (zero downtime so far with loss of hosts a couple of times) the setup process was quite tedious and not something I'm looking forward to doing again. It also has a lot of moving parts - understand and setup zookeeper to get mesos up, understand and setup Aurora, use something for service discovery (I use AirBnB's Synapse for this). Plus I prefer to use tools I can choose to look under the hood of and perhaps make some contributions, which is a bit intimidating with both Mesos and Aurora (C/C++ and Scala). Because of this, I'm keen to try out Nomad mostly because of the promise of no-other-dependency/single binary plus the use of a single language across the stack - Golang
Having looked at both Mesos (with its various frameworks) and Kubernetes, this immediately looks more attractive to me.<p>No external dependencies (which arguably simplifies ops), competetive feature set, a nice job language, the fact that Docker is optional, polished documentation, etc. Having used some of Hashicorp's other products, I've grown to expect a level of quality and pragmatism that seems to present here, too. Not being JVM-based is a big plus in my book, too.<p>How much production use has Nomad seen, I wonder?
><i>Nomad is designed to be a global state, optimistically concurrent scheduler. Global state means schedulers get access to the entire state of the cluster when making decisions enabling richer constraints, job priorities, resource preemption, and faster placements.</i><p>Can anyone shed light on how that's possible? I was under the impression that global state in distributed systems was not possible?
That's... no small release. If it indeed has everything they claim that's extraordinary. What's the catch? Why haven't they made more noise about this?
Side note to Hashicorp devs: The Products section of your homepage is virtually unreadable on Windows/Chrome: <a href="https://i.imgur.com/8st8HQk.png" rel="nofollow">https://i.imgur.com/8st8HQk.png</a>
Nomad appears to share some of Consul's internals, but it does not seem possible to use an existing Consul cluster as backing KV store/lock provider/etc. I'd like to understand why.
This might stray a bit from the core topic, but does anyone have resources (preferably free) about the theory behind what Nomad covers? Batch/job/task Scheduling, etc.