The concept of Service Discovery involves locating a network using automation and without manual intervention. Devices can skip the extended configuration and set-up processes, as services can connect using a common language on the network. More importantly, service discovery’s primary goal is to reduce its users’ and administrators’ efforts.
How Does Service Discovery Work?
Service discovery has been utilized in the past before it evolved as computer architectures. Long before interconnected networks, service discovery allowed connections between different computers. They can locate one another using a single global text file called HOSTS.TXT. Once the device is detected, users have to add the addresses manually, especially with hosts’ surplus in the past. This history is what made service discovery such a vital part of the configuration process.
Yet, the internet’s advancement changed the concept of service discovery altogether and the volume of hosts that manage networks.
Now, modern service discovery leverages automation to expedite the process. This expedited process leads to a widespread of people adopting this concept. Plus, this quick setup also leads to them working on making service discovery even more scalable and agile.
Without the tremendous contribution of microservice architectures, service discovery would not be as seamless today. Microservice architecture has made it possible to expand the lifespan of service in seconds and minutes. Addresses are integrated from time to time as new hosts get added, ports are changed, or services get terminated. Thus, a growing number of organizations began adapting their strategies.
To better understand the concept of service discovery, it is important to discuss two of its primary patterns: Client-side and Server-side.
Client‑Side Discovery Pattern
The Client-side discovery pertains to the responsibility of the client to locate the available services across the networks. They are the ones who create load balancing requests and services registry queries to carry out requests. The service registry is where they can find a plethora of services available. A load-balancing algorithm chooses any of the services available before sending a request.
An example of the client-side discovery pattern is Netflix OSS. Eureka is its service registry that showcases a REST API where clients can find available service instances and register for them. For load balance requests, Netflix Ribbon via IPC selects the proper service instances.
Advantages of Client-Side Discovery
The pattern is easy to manage. You only have to deal with the moving parts in the service registry.
Clients are well-informed of the service instances available, which allows them to make better decisions.
Disadvantages of Client-Side Discovery
Coupling clients with the service registry prompts them to implement different logic for each service clients’ framework.
Server‑Side Discovery Pattern
The second pattern in service discovery is server-side. This concept involves creating requests for service using a load balancer. The load balancer formulates queries to the service registry. These queries direct to any available service instance. In comparison to client-side discovery, the services are registered and then deregistered with the service registry.
One example of server-side discovery is the AWS Elastic Load Balancer (ELB). ELB is known for performing load balancing to be able to obtain traffic from the internet. Another way to utilize ELB is through a virtual private cloud (VPC). VPC enables internal load balancing to create requests using its DNS address. Additionally, the service registry does not separate, unlike on the client-side. Service instances (EC2 and ECS) are accessible within the ELB. This accessibility allows you to utilize ECS service discovery to automatically register with a DNS name in Amazon Route 53 all within the ELB.
AWS also offers Cloud Map which is a cloud resource discovery service. Cloud Map maintains updated locations for all of your application resources such as databases, queues, microservices, and other cloud resources. It constantly checks the health of these resources ensuring the location of the resource is up to date.
Users can also configure HTTP servers and other load balancers, including NGINX and Envoy, to balance servers. However, microservice architectures and Marathon run a proxy on every host in the cluster. The proxy serves as the load balancer on the server-side discovery. Users can carry out a service request through the proxy using the host’s IP address. You will also need the port assigned to the service before the proxy can send your request to any available service instance.
Advantages of Server-Side Discovery
Service-side discovery details can separate the process away from the client. In this way, they don’t need to incorporate a discovery logic for each service framework.
Requests and the code itself is often more straightforward. They only need to perform it via a load balancer, and some cloud environments provide a load balancer inherently.
Some deployment architectures are entirely free.
Disadvantages of Server-Side Discovery
Some deployment infrastructures cannot provide a built-in load balancer.
Without a load balancer, you need to spend time setting up the load balancing algorithm.
Examples of Service Registry
Service registry plays a fundamental role when it comes to service discovery. It is the database that makes up the complete list of service instances. Users look into this network to check the availability of services. They can also cache the locations of the network from the service registry. Here are some examples of the servers that can maintain the consistency of a service registry:
Etcd
Etcd is widely available for shared configuration as well as service discovery, and known for projects such as Cloud Foundry.
Consul
Consul is the go-to tool for configuration and discovery of services providing key-value storage, segmentation, and configuration. Using API, users can locate and register available service instances. It can also carry out health checks to be able to confirm the availability of services. Consul allows registered services and nodes to be queried using either a DNS interface or an HTTP interface.
Apache Zookeeper
As one of the most commonly used servers, apache zookeeper takes pride in coordinating services across applications.
Moreover, it is essential to note that there are systems that lack an explicit service registry. Systems like AWS have a built-in service registry within its deployment environment.
Service Discovery Implementation
Services often communicate with other available service instances. Microservice architectures and servers are vital to direct this connection and amplify its frequency.
To power service discovery implementation, HashiCorp paves the way to locate, register, and resolve services for application workloads across any cloud. This process eliminates manual intervention by automatically integrating and removing services after performing extensive health checks. The DNS-based approach can implement service discovery. In this way, you can manage service discovery using any language and with little to no code changes involved.
In conclusion, service discovery ensures the health of your applications by automatically locating, registering, and resolving services for your application workloads across any cloud. This automation significantly reduces the effort required by the users and administrators of your applications.
Comments