Integrating with the HTTP interface starts to add value for things like:
* Service self-registration (Nomad and Vault do this)
* Bootstrapping and built-in watching for peer nodes (Nomad does this)
* Built-in coordination using Consul's KV store (Vault does this)
* Built-in KV store integration for app configuration
(https://github.com/mitchellh/consulstructure)
Many of these are possible with DNS + consul-template + envconsul but
if an app natively integrates with Consul you can basically just start
it up and have it talk to the local Consul agent to do all these
things on its own.
-- James
On Tue, Sep 27, 2016 at 5:34 AM, Finn Tran <fina...@gmail.com> wrote:
> Consul supports both. Since just about any client supports DNS already, what is the value proposition of integrating with the HTTP interface?
>
You do not have permission to delete messages in this group
Copy link
Report message
Show original message
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to Consul
Just reviving this older thread about HTTP vs. DNS to see if there are any other perspectives to consider.
One of other advantages of HTTP is that it allows future pluggability, extensibility (example plugging in your own scheduling algorithm) and control. Another consideration is of course that with DNS you need to become knowledgeable with DNS if you are running Consul on AWS such as how it interacts with AWS's own DNS service, how it will work across VPC peering and so on.
Is HTTP api more actively worked on in opensource version?