DNS GSLB & Service Mesh for Continuous Delivery

For users to access their applications, DNS resolution to determine the destination and IP routing to find the path are mandatory. The application modules and services should be exposed on the servers or facilitator equipment such as a load-balancer. For static installation of applications onto servers, DNS configuration and load-balancing are quite easy, but in modern software architecture based on decoupling and microservices, it is more dynamic and therefore far more complex. This is where service mesh and Edge DNS GSLB can help ensure the continuous deployment and scalability of the services.

Service mesh: a smart way for exposing microservices

A microservices architecture approach allows redundancy and scalability in addition to easy modular development and refactoring. The launch of an instance of a service follows rules and traffic patterns, but it is a different task to scale in and out the service and to make it available to the end user or a 3rd party application when required. Scaling of services is generally performed directly by the orchestrator or hypervisor system, but exposing the service requires involvement of external components. In order to expose a microservice, one tricky part is to know where the service is running – on which server for the IP address or the name – and on which port. The protocol (e.g. TCP, UDP…) is generally implemented at the application level, with TCP being the one most commonly used.

To help with the task of localizing services within a complex ecosystem, the service mesh solution is a smart approach. The Cloud Native Computing Foundation (CNCF) lists 10 of these services on its interactive landscape. A common and easy solution to start investigation and a lab is Hashicorp Consul. It proposes a key/value storage mainly for configuration storage, a health check service and a registration service, which is the interesting part in our case as we will rely on the service repository and dynamic updates to perform on-the-fly configuration of the DNS service.

Each service starting in our microservice architecture has to register itself with the Consul service, and also propose a way for the Consul to check when it is ready to serve. The service is then put online, and its health checked regularly. For higher level orchestrators, this is performed by the launcher of the microservice as a sidecar to the code container itself. So the health check and availability check are configured in the service description. When using a simple container system, this part can be embedded in the microservice code directly, allowing it to be able to be run on any kind of architecture, including VM and bare metal servers for high performances or access to specific GPIO.

Coupling DNS GSLB with a service mesh

For some services that are exposed to the outside world, information is in the service mesh directory and Consul proposes triggers and rich ways to interact with its dynamic repository of services. This is where the DNS, and more interestingly the Edge DNS GSLB service, can bring value when connected to a service mesh. With tight integration, GSLB and Consul can work together to make the exposed services available to the clients or other applications. The Edge DNS GSLB resolution will take advantage of information concerning the availability of a service and its presence on some servers for directing the clients towards the selected server.

By leveraging the tag feature in Consul that can be applied to any service, it is easy for the GSLB engine to filter on which service should be accessible and exposed. The exposed point can be either the service itself or a proxy service, for example a reverse proxy performing the mapping of the URL to the appropriate service (e.g. fabio). If the service is required to be launched several times for scalability purposes, multiple IP addresses are available and the GSLB will then construct a pool of server nodes for hosting this application. This will add a first level of load balancing and a very simple way through the DNS service to route traffic from the user to the application component without having to set up a complex central ADC solution.

The power of the Edge DNS GSLB is to be able to make a decision in the best interest of the user located near it. And since a DNS should be kept up to date in order for the service to be accessible, it does not cost any more to add a few parameters for the GSLB service to perform the selection of the best remote server to send the traffic to. Consul, like some other service mesh, already proposes a DNS service for localizing the endpoints for a microservice, but this solution requires specific delegation or forwarding as part of the DNS tree towards the Consul, exposing the entire internal service structure, which is not recommended.

Client access to best service using DNS GSLB

1. Each microservice registers its presence with IP endpoint information in the service mesh
2. Service mesh starts monitoring presence and health of the service
3. The DNS GSLB get information on the service and its IP endpoint information
4. GSLB starts health checks for end-to-end service validation
5. Client requests IP information for reaching the exposed service, GSLB provides best destination
6. IP communication can be established with best service endpoint

Two main use cases for coupling Edge DNS GSLB and service mesh

1. For testing purposes, this can allow the application instance to be made available directly with the name configured in the service tags without having to perform complex mapping. This is compatible with any continuous testing solution, even in full automated mode, for nightly tests for example.
2. For production purposes, this can allow a first level of application routing directly at the edge of the network, with the application services being started in multi-cloud environments at different locations.

The integration is straightforward and takes full advantage of already having a DNS resolver near the users at most locations of the corporate network. This is independent of the usage, the level of maturity for the application, and the number of users. We have developed a quick proof of concept with Hashicorp Consul and Nomad and will be happy to share our results with you.