Hey @SunSparc, we were wondering if that reaction would be common among Nomad users. Especially given the “do one thing and do it well” ethos around HashiCorp projects. I’m happy to shed some light on the decision making process.
For a while, we’ve avoided any native service discovery because we wanted to to just be a scheduler and not re-invent the wheel with service discovery. For users who are comfortable with Consul, or who can roll their own service discovery, or who don’t need service discovery, this is really nice because the mental overhead of understanding/running Nomad goes down. And we’ve heard feedback from those users along the lines of “I love that Nomad doesn’t have Service Discovery, because it simplifies things”.
At the same time, there’s another set of users who want a simple Scheduler/Orchestrator, but they don’t know Consul yet and/or they don’t want to roll their own SD on top of Nomad. For these users, the feedback was something like “I don’t like that Nomad has no Service Discovery because it is a table-stakes feature for scheduling, and now I have to learn/integrate another tool”. We wanted to be able to serve this set of users as well.
While I think our Consul integration story is good (and will get better!), for people who just want a few different services talking to each other, the overhead of learning, provisioning, and managing Consul is a lot. We’ve tried to make this integration easier with docs and tooling, but there’s just some inherent complexity that is hard to work around. So after some internal debate, we all agreed on adding basic SD to Nomad.
Our ideal flow for a user is to use Nomad Service Discovery initially, then migrate to Consul once their architecture/business needs demand it. This allows new users to ramp up quickly and see value from Nomad without having to immediately eat the cost of the Consul integration. If you never need anything complex (think a homelab or side project), then Nomad-only is fine and you can enjoy a super simple architecture.
Nomad will still try to be a great deal simpler than Kubernetes (we aren’t aiming to become the API for your whole datacenter). But we do want to be a “simple scheduler” and, for a lot of users, basic service discovery is table-stakes for that.
Just a heads up looking forward. You’ll likely see a similar story with very basic secrets management. Again, we don’t want to waste time reinventing the wheel, but we want to provide users with an incredibly simple architecture before eventually adopting a tool like Vault.
With both of these features, the end goal for medium to large deployments is that Nomad is an on-ramp to Consul/Vault, and eventually you run the full HahshiStack.
