Best Service Discovery Software

Eureka is a REST-based service registry built at Netflix for the discovery, load balancing and failover of middle-tier servers running in the AWS cloud, where it plays a critical role in Netflix's own infrastructure. It is published as open source on GitHub, is community driven, and builds with Java 8 while keeping source and target compatibility at Java 7.

Its origin explains its design. Eureka was written for an environment where instances appear and disappear constantly and where the naming a traditional load balancer expects does not hold, so the registry is deliberately tolerant of stale information rather than strictly consistent. A client would rather have a slightly outdated list of servers than no list at all, which is the correct trade for a service that must keep serving during a partition.

Being embedded in the Spring Cloud ecosystem is how most teams meet it. Spring Cloud Netflix made Eureka the default registry for a generation of Java microservices, which is why the project appears in far more architectures than its own repository traffic would suggest.

Maintenance is community driven and the maintainers ask that non-trivial changes start with an issue. A team adopting it should read that as it is meant: this is proven infrastructure rather than actively expanding software.

AWS Cloud Map is a cloud resource discovery service. Applications register resources such as databases, queues, object stores and microservices under custom names, and the service maintains their current locations as those resources change, continually checking their health so the recorded location stays accurate. An application then queries the registry for what it needs, filtered by attributes such as version and deployment environment.

The problem it addresses is stated plainly by the vendor and will be familiar to anyone who has maintained a growing system. Resource names and locations are usually managed by hand inside application code, which becomes time consuming and error prone as dependencies multiply or as services scale up and down with traffic. The alternative has been to install and operate a third-party discovery product, which is infrastructure a team then owns.

Registering arbitrary resources rather than only services is the difference from a service registry. A queue or a table is a dependency in exactly the way another microservice is, and being able to look both up through one mechanism removes a category of configuration.

Pricing is metered rather than subscribed, at a rate per registered resource per month plus a rate per million discovery calls, so cost tracks the size of the estate and how often it is queried.

Apache ZooKeeper provides naming, configuration management, synchronisation and group services for distributed systems, presented through a hierarchical namespace modelled on a filesystem. It is replicated across an ensemble of servers, survives node failures without data loss, handles tens of thousands of requests per second with sub-millisecond in-memory messaging, and stamps every update with a monotonically increasing transaction identifier that gives clients a total ordering guarantee.

Being a coordination kernel rather than an application is the thing to understand first. Very few organisations set out to buy ZooKeeper; they adopt Kafka, Hadoop or HBase and inherit it, which makes it one of the most widely operated pieces of infrastructure that almost nobody chose deliberately.

Total ordering is the guarantee everything above it is built on. Because every update carries an increasing identifier, clients can reason about the sequence of changes rather than merely their content, which is what makes leader election and distributed locking implementable at all.

Operationally the ensemble is the thing to plan for. A quorum has to be maintained, which means an odd number of servers and enough separation that a single failure domain cannot take the majority, and getting that wrong is the usual cause of an outage attributed to the software.

Istio extends Kubernetes into a programmable, application-aware network, bringing traffic management, telemetry and security to workloads running both in Kubernetes and outside it. It deploys proxy infrastructure only for the features selected, offers a zero-trust tunnel for Layer 4 performance alongside a fuller Layer 7 path, and states that its ambient mode, which runs without sidecars, is now generally available.

Ambient mode is the significant recent change and it answers the standard objection to service mesh. Running a proxy container beside every workload doubles the number of containers and adds memory to every pod, which is a cost operators noticed immediately. Removing the sidecar for workloads that only need Layer 4 security keeps the security guarantee and drops most of the overhead.

Mutual TLS between services is the capability most organisations actually buy it for. Encrypting and authorising service-to-service traffic without changing application code is a compliance argument as much as a technical one, and it is far cheaper than asking every team to implement it themselves.

Installation is worth deciding deliberately. Istio can be self-managed, installed through a cloud provider's one-click option, or bought as a fully managed mesh from a provider, and the operational burden differs enormously between those three.