Nomad Service Discovery Feedback

The Nomad team would like your feedback on the new service discovery feature launched in Nomad 1.3 Beta!

From the Nomad Team:

With the launch of Nomad 1.3 Beta, we’ve added simple native service discovery to Nomad.

We’re quite excited about the addition as is, especially for simple architectures and small workloads, but we plan to continue iterating on our current work. We won’t replace Consul as a full service mesh, but we do want to make sure native service discovery can work for more users with real services in prod.

We’ve already identified some smaller improvements, such as advertising arbitrary addresses on Nomad services and adding template stanza helpers for load balancing and selecting single services, some mid-sized improvements like better readiness checks, and some larger-sized improvements like DNS support.

We would love to hear what else is most important to you though!

What would you want from Native Nomad Service Discovery? What would be the simplest UX and workflow that we could enable? What features or tweaks could we add to get you using this for real production workloads?

Please let us know!

Drop your feedback below OR on Github

3 Likes

My initial reaction is: “Why is this even a consideration as a feature when we have Consul?”

If I understand correction, this is for smaller setups where Consul would be overkill. I can see use cases that could benefit from that.

On the other hand, is this outside the scope of the core purpose of Nomad? Does this fall outside the adage, “do one thing and do it well”? Or is this a natural progression of the course Nomad has already been on?

Just some thoughts. From the overview in the blog post it looks pretty nifty.

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.

3 Likes

@mnomitch, well spoken. I can certainly see the value proposition here. As long as these SD and Secrets feature are able to stay minimal and guide users along the path to Consul and Vault, if their needs grow that way, then these enhancements seem reasonable. Thank you for taking the time to share the extra background on this topic. :slight_smile:

1 Like

I know I am imagining, but could there be a single HashiStack binary, which could run in various modes; consul-server, consul-client, nomad-server, nomad-client, vault-server, vault-client, etc.?

Maybe it could then be way simpler, not only from deployment, but also configuration!?

Just-a-thought :man_shrugging: