In recent years, Microservices have gained in popularity, since they come with various advantages, which are very useful for contemporary software development for example, in the era of containers, decentralization and cloud computing.
Microservices can be developed and deployed on different platforms, using different programming languages and development tools.
Additionally, the microservices architecture is an approach in which an application is broken down into a number of components, in which each component is responsible for a specific role. Different components communicate with each other using network protocols (e.g., HTTP) through connectors (e.g., APIs). A cloud platform is able to provide such services to the user. The term “cloud services“, as described in other blog posts, refers to a wide range of services delivered on-demand to companies and/or customers over the internet. These services are designed to provide easy, affordable access to applications and resources, without the need for internal infrastructure or hardware. Ranging from checking emails to collaborative document writing, most employees use cloud services throughout their workday, whether they’re aware of it or not. As a result, microservices are widespread and used by many expert or novice end-users.
In addition to that, microservices offer many functionalities that can be easily deployed or modified saving time and effort.
Nevertheless, the large variety and the number of available services make it difficult for a novice cloud developer to find and choose the right services for his/her application.
Luckily, all cloud providers as well as the research community have experimented with Service Discovery. Service Discovery refers to the process by which, on the one hand, an application-user learns (by search) what services are available on the network, and on the other hand, the network “learns” what services the application can provide.
How does Service Discovery Work?
There are three components to Service Discovery: the service registry, the service provider and the service consumer.
The Service Registry. The service registry is a key part of service discovery. A service registry needs to be highly available and up-to-date. Service instances must be registered with and deregistered from the service registry. The identification of services can rely on advanced search methods, and a search in public or private repositories, or on the internet. In a cloud platform, every service has many instances, and each instance is being used by an application or a user. In terms of adding a new service to the system, it is common to use the Self‑Registration Pattern in which the Service Provider adds a new service with its information on the system. The alternative to self-registration pattern is the existence of a system component to manage the registration of service instances: namely, the third‑party registration pattern. Both solutions are presented below:
The Self‑Registration Pattern. In the self‑registration pattern, a service instance is responsible for registering and deregistering itself with the service registry. Also, if required, a service instance sends heartbeat requests to prevent its registration from expiring.
The Third‑Party Registration Pattern. Third-party registration allows delegation of service registration/deregistration task to Third-party registrar (service manager) component. On service instance start-up, service manager is responsible for registering the service with the Service Registry. Similarly, it de-registers on service shutdown. With this option, service resilience can be better handled as Service Manager can handle these requests more elegantly than self-registration where a service can abruptly go down with Service Registry not being aware. The following diagram shows the structure of this pattern.
Service Discovery. Regardless of the Service Registry decision, there is a need for a predefined protocol (i.e., a specific way to describe the service) to enable discovery. A service description captures the functional and non-functional characteristics of a service in a format that can be machine-read and processed. This description helps the Service Discovery to find services based on search criteria. A service description can be an XML file as shown below.
The service discovery is a search process that aims at finding available services with specific requirements or finding instances of a service by performing queries on the service registry. There are two primary strategies for discovering services, via a service registry:
Client Side Discovery. The client contacts a service registry, receives details for available services, and contacts one of them using a load balancing algorithm. When the client requires a microservice, it finds a suitable service in the registry and connects to it directly. The assumption is that the registry tracks availability of services using a heartbeat mechanism.
Server Side Discovery. The client contacts a load balancer, making a request that indicates which type of service it needs. The load balancer consults the service registry, selects the optimal service and routes the request to it. Load balancing is commonly used as a service discovery mechanism; it provides health checks and can automatically register/unregister services when they fail. The load balancer works in tandem with the service registry.
Service Consumer. Finally, these applications are being used by some entity called Service Consumer. The service consumer could be an application, a service, or any other type of software module that requires a specific functionality, through a service. This entity uses the Service Discovery to find services within the system, binding to the service over a transport protocol and then executing the service function. The service consumer executes the service by sending a request formatted according to the service description. The most common example of a service consumer is a REST Web Service call like this one:
api.mycompany.io/v1/party/findById/12
This request invokes a service of the revision v1 that exists in the api.mycompany.io host. Specifically, it will try to find a party entity with id=12.
Examples of Service Discovery in Industry
- Google API Discovery Service: The Discovery API provides a list of Google APIs and a machine-readable “Discovery Document” for each API.
- Amazon ECS Service Discovery (AWS Cloud Map API): AWS Cloud Map is a fully managed service that can be used to create and maintain a map of the backend services and resources.
- IBM Service Discovery API: Service Discovery is a core service within a cloud microservices architecture that can be used to accelerate the development of applications in the cloud environment.
- Docker: Service discovery registers a service and publishes its connectivity information so that other services are aware of how to connect to the service. Some ways to achieve service discovery with docker are:
- Service Discovery with DNS
- Internal Load Balancing
- External Load Balancing (Swarm Mode Routing Mesh)
- The Swarm Layer 7 Routing (Interlock Proxy)
- Azure API Management with microservices: As a full-lifecycle API management solution, it provides additional capabilities including a self-service developer portal for API discovery, API lifecycle management, and API analytics.
References
- www.g2.com/categories/service-discovery
- www.nginx.com/blog/service-discovery-in-a-microservices-architecture/
- ns1.com/dns-service-discovery
- www.datawire.io/guide/traffic/service-discovery-microservices/
- avinetworks.com/glossary/service-discovery/
- medium.com/@jamesemyn/service-discovery-in-microsrvice-cbd54afb94f3
- auth0.com/blog/an-introduction-to-microservices-part-3-the-service-registry/
- www.magalix.com/blog/kubernetes-patterns-the-service-discovery-pattern
- cloud.google.com/service-infrastructure/docs/service-consumer-management/reference
- docs.aws.amazon.com/cloud-map/latest/dg/what-is-cloud-map.html
- developers.google.com/discovery
- developer.ibm.com/api/view/id-129:title-IBM_Service_Discovery_API#Overview
- success.docker.com/article/ucp-service-discovery-swarm
- docs.microsoft.com/en-us/azure/api-management/api-management-kubernetes
No responses yet