Neptune DXP service discovery

In a distributed architecture a microservice can invoke another microservice to leverage its capabilities. Sophisticated cascading orchestrations can be implemented to organise complex transactions:

In the figure, a Neptune DXP order microservice orchestrates two synchronous API calls. First, to process the payment, second, to acknowledge with the customer the successful receipt of their order.

But how can it know the network location, that is, IP address and port, of the Payment and Notification Neptune DXP microservices? To address this in Neptune DXP, you can register, at design time, other Neptune DXP services as remote systems. As a trusted system you can then import their REST API to make it available for use within server scripts.

At runtime, the orchestrating service can make API calls to the target service, which in turn issues its responses. In our order management example, two remote systems are registered in the order service, listing the network location and authentication credentials of the Notification and Payment microservices. Their APIs can then be imported and made accessible via code without the server script having to worry about the network location of the service being called.

For dedicated, bare-metal or virtualized machines hosting Neptune DXP services, the network location is usually static and therefore straightforward to specify. In containerized cloud settings, such as Kubernetes, Neptune DXP service instances must be load balanced. They can be added or lost due to scale-out policies, failures or upgrades, with their network locations dynamically allocated making them impossible to identify. In this case, orchestrating services must list the load balancer placed in front of a group of microservice instances as the remote system to be discovered.

The use of an internal DNS service is strongly recommended in this case to mitigate ephemeral IP/Port addresses of Neptune DXP instances and the corresponding load balancer with logical and memorable names.