Services upgrading their own DNS

This article is a continuation of investigations into service discovery, which started 3 days earlier with The world’s quickest demonstration of consul.

One side of DNS is the ability for clients to find backend services/web apps without knowing implementation details: the IP addresses of host machines.

The flipside is equally important: the ability for the backend services/web apps to migrate/heal/scale and change their internal implementation details: the IP addresses. The published hostname (and port, which defaults to 80/443 for HTTP/HTTPS services) is the sole contract with clients. A lovely abstraction.

But typically DNS is manually managed by someone with access to a DNS service. If a service changes, the DNS must be manually changed.

There is another option – to allow services to self-update their published DNS records.

One option for internal API-driven DNS management is consul (others include skydns2).

Here’s an example of a web app that uses a redis cluster. The redis master is stopped (simulating failure), and the redis slave is manually promoted as the new master. But consul then advertises the new IP location for the master.redis.service.consul hostname, and the web app continues working. The web app is never touched.

(click for full-screen)

There is an exciting future for services taking back responsibility for self-configuration from deploy-time configuration management tools!