Everytime I try to clarify the concept of Service Discovery, the google endeavor gets way to technical, too fast. For example, what part of DNS handles Service Discovery? And how does that differ from the way like Consul handles it? The confusion is real.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (4)
Service Discovery = how your individual services know about each other and talk to each other to create a full solution that is a website, platform, saas.
If all your services run on a single machine (database, http server, server-side application), your service discovery is YOU typing
localhostin to all the configs.If you have two machines, your service discovery might be, you editing the /etc/hosts file and adding aliases like:
10.0.88.9 database
10.0.88.10 webserver
You do the service discovery by hand.
Hashi Consul, is an application that runs as a service. Consul has 2 modes, server and agent. Anything can register against the consul API to be a service. You can have services attached on each machine consul agent runs, then the consul agents will talk to consul servers, and let everything in the cluster know what services are running and where.
You can then ask any consul server via the api, for a service via the DNS name.
The standard pattern is something like
webserver.service.consulthis is the address you would "dig".. and consul would return an IP address.Consul is better, because consul will de-register dead services after some time, consul also, only sends requests to services that are UP.
Thank you for your reply! So, have I understood it correctly that when people say "Don't use DNS for Service Discovery", it's because of DNS cannot really determine if a service is dead? The domain name might be cached even though the service is gone?
To over-simplify - yes, DNS by design will resolve to IP addresses even if those IP addresses have not been used for 90 years. (assuming that the DNS servers are still there).
DNS in hashi consul is a matter of convenience, and also does routing to services that are available, or in a particular data-center.
If you like to live dangerously, you could implement very primitive service discovery with DNSmasq, but you should not.
DNS itself is not a bad or a good thing, it depends what you use it for, and the tolerances of caching, stale data, failures that your systems will put up with.
Service Discovery in a few word it's asking a centralized registry what what else is running and where (how I can reach it). The generic flow looks like:
1) Introduction yourself to registry: Hello I am a Bakery service with ip address x.x.x.x and port zzzz
2) Registry will create a record and perform a periodic check to ensure that this service is up and running
3) Some one else can ask I need to reach to the Bakery service and get reply with the address/ list of addresses from records
Consul uses DNS as mechanism to refer to specific service location but it has own tradeoffs like every system.