Use-cases into which eureka can be useful as a JVM local DNS service provider:
1- a three-tier application (ELB, Tomcat, mysql cluster with multiple read replicas). Eureka gets used by the tomcat application to dynamically lookup mysql read replicas within the cluster. The mysql read replicas can come can go (possibly using an ASG). The standard JDBC driver would normally resolve an eureka-specific DNS entry (say "read.myslcluster.eureka"). This DNS resolution would in turn be handed to Eureka local JVM DNS resolver that would lookup a corresponding eureka application, and on round-robin maneer return the next InstanceInfo available.
On the mysql replica-side, an eureka client is installed and actively register with the eureka cluster for the "read.myslcluster.eureka" application. A mini http server is started up to publish a health url as an HTTP endpoint (unless if the health url format at
http://netflix.github.com/eureka/javadoc/eureka-client/com/netflix/appinfo/EurekaInstanceConfig.html#getHealthCheckUrl() supports other protocols than http such as TCP:3306 or mysql:)
This way the tomcat layer benefits from automatic fail over (within read replicas or across AWS AZ or regions) through the DNS resolution delegating to Eureka cluster.
2- an SOA-based application, relying on SOAP webservice backends.
Instead of adapting the SOAP stack (e.g. CXF) to integrate with eureka for performing mid-tier load-balancing (similar to what netflix done with the jersey REST client stack), legacy applications could run unmodified CXF stack, and only configure eureka local JVM DNS provider to resolve DNS entries (e.g. "service1.eureka") to benefit from automatic fail over, and possibly in the future additional value added features such as geo resolution (e.g. resolving to the closest application instance in terms of AZ or network latency)
this is either apps for which I have no control over source code (e.g. apps that I instanciate through standard binaries, such as a maven client) that I would like to benefit from Eureka-based mid-tier load balancing and fail over. Those apps would currently be deployed to leverage hardware-based level 4 load balancers such as bigIp.
Or this may be apps that I compile from source code but I wish no yet to deserve more precise lookup than a simple instance host/port resolution. Not requiring to perform source-level changes to use eureka-based mid-tier load balancing allows the same app to run unmodified with a TCP-level load balancer, or with eureka. Only the JVM configuration is changed to configure Eureka as a DNS resolution provider, and the host name to match one of the eureka-register application name.
Having these app directly
DiscoveryClient.getApplication(java.lang.String appName)
just to select the first returned ApplicationInstance.getHost() would be more of a burden in some cases than just performing a simple implicit DNS resolution from a well known host name such as "service.eureka".
Guillaume.