As microservices style architectures are becoming more common, new architectural patterns are emerging. Microservices style applications are highly distributed and dynamic, and a key architectural constraint for microservices applications is elasticity i.e. A microservice must be able to scale, up or down, independently of other services in the same application [1]. As a microservice scales up or down, other services need to be able to find it and communicate with its instances, resulting in requests being distributed across all instances of that service, and enabling the application to scale horizontally. There also needs to be some built in mid-tier load balancing (i.e. service-to-service) so that requests to a service get evenly distributed across its instances.

Existing approach

A common approach is to have a dedicated service registry with which application services can register their instances. A good example of this approach is Eureka from Netflix OSS [2]. Service instances can register with Eureka when they come up. The registration binds a service name to a list of IP addresses and ports, one for each registered service. Other services can then query Eureka to find an available instance. Using Ribbon, another Netflix OSS component, with Eureka client provides mid-tier load balancing for service requests. Zuul, yet another component, can be used to provide the edge tier load balancing for the application. While this approach works, there are some limitations:

• Eureka needs to be deployed and operated as a cluster
• Service Discovery requires code and application container changes. Currently the client is only available in Java with the side car approach recommended for other runtimes [3]
• Service-to-service flows cannot be filtered or managed in the same manner as requests at the gateway.

Nirmata’s approach

Nirmata improves on the service registry approach by providing built-in service discovery for microservices style applications. When ‘service networking’ capability is enabled for an application, the services within that application can seamlessly find each other by using a fully qualified domain name (FQDN). There are no additional client-side requirements for service discovery – this works for any language and without changes required in the application container.

Nirmata also provides a gateway service which is integrated with the service discovery capability and can be used to load balance and dynamically route requests from outside the application.

Nirmata provides an additional level of control by allowing developers to control which services can communicate with each other, for both the gateway traffic as well as the service-to-service communication.  For example, this feature can be used to ensure that only the appropriate versions of services can communicate with each other, preventing any undesired behavior.

With Nirmata, distributed service discovery and request routing is tightly integrated with application orchestration resulting in high availability and near real time performance as changes are made.

Demo

Below is a short video of Nirmata’s service discovery and request routing capabilities.

For more updates and news follow us at:    

 

References

[1] Microservices: Five Architectural Constraints: https://nirmata.com/2015/02/microservices-five-architectural-constraints/

[2] Eureka at a glance: https://github.com/Netflix/eureka/wiki/Eureka-at-a-glance

[3] Netflix OSS Prana: https://github.com/Netflix/Prana/wiki