In job service, we can define service provider as nomad or consul.
Why do Nomad services exists if there already were consul services? Isn’t this putting more work on the maintainers, that now have to support two separate implementations of basically the same service?
Hey Kemilcuk,
You’re right that there is a lot of overlap between the two. In fact, we tried to make them as similar as possible without implementing all of Consul. And, you’re also right that this is more burden on the maintainers. But… even knowing all of that, we decided to add Nomad services and we’re really happy with the decision.
The main reason was that when we talked to people who tried Nomad but eventually dropped it, the consistent story we heard was that they didn’t like that they needed multiple tools to do what was in their mind, simple orchestration. So, we added service discovery in Nomad for people who were just adopting Nomad and had relatively simple SD needs. If you need mTLS, or anything service-meshy, or want to offload service calls to another tool as your Nomad cluster grows, Consul is there is (hopefully) easily adopt.
This was a somewhat risky bet just because the maintenance cost is real, but for what its worth, it has paid off. We’re seeing a lot more people use just Nomad SD and many of those have gone on to adopt Consul once their needs grew.
Hi Mike, thanks for your answer.
I am sorry, this is still confusing. Thank you for explaining the reason. From the architectural point of view, what is planned for the future?
Last Nomad releases brought key-value store to Nomad, which is also a feature in Consul. Will more features of Consul be integrated in Nomad? If only DNS service will be integrated in Nomad, I could remove Consul altogether (ugh, I would have to replace fabio), and I would be happy to. Are there plans to do so? Go takes a lot of memory, and both Consul and Nomad services constantly keep over 1GB of the machine. I see consul is used for DNS and to forward labels to fabio.