Increasingly, modern enterprises are deploying applications using a microservice-based infrastructure where each service performs a specific function within the application. This design allows developers to make changes to specific segment or service of the application without having to redeploy everything. Often, a service may need to request data from other services within the application in order to perform its unique function. Therefore, service-to-service communication is a critical component for these types of architectures.
While microservice architectures promote high-availability and dynamic scaling, there are certain challenges that arise from the indirect communications taking place between services. Whereas, in a monolithic system, subsystems are directly connected to each other and can pass data quickly and securely. Distributed architectures introduce a level of infrastructural complexity and latency.
Consul is a service networking tool that allows users to discover services and secure network traffic. When an application endpoint—a VM, bare metal server, or container—is created or removed on the network, a local Consul client registers available services with the Consul server.
Consul is a service registry, and DNS is a canonical way to discover services. The integration with NS1 allows for service discovery to occur over DNS. Users can specify service-level policies that control service-to-service communication, connecting services that are authenticated via mutual TLS. This makes it easy to scale dynamic configurations without having to implement firewalls for specific service IPs. Using the NS1 Filter Chain, users can apply custom routing traffic logic—for example, to “round-robin” load balancing between services.
This article provides an overview of the NS1 + Consul integration. To implement the integration, contact the NS1 support team by submitting a ticket or emailing firstname.lastname@example.org.
How it works
Consul maintains a list of endpoints (IPs and ports) for each registered service. When an application endpoint—a VM, bare metal server, or container—is created or removed on the network, a local Consul client registers available services with the Consul server. NS1 queries the Consul services (including all instances of the service) to identify when a service is created or removed.
For each Consul service, two records (A and SRV) are created within the NS1 platform, along with an answer for every instance of that service. The A record contains the IPs of the instances and the SRV records contain the IP addresses and ports that are being used per instance.
As such, NS1 works in conjunction with Consul to provides a single source of truth for all connected Consul service. The integration creates a backup registry within the NS1 portal, supporting service discovery via DNS which supports dynamic scaling and simplifies deployment in complex network environments—Including hybrid-cloud, on-premise, and cloud-based architectures. Additionally, users can leverage the NS1 Filter Chain to apply advanced routing policies for granular control over service-to-service communication.
Key terms & definitions
- Service discovery is the automatic detection of devices and services. It is the way in which applications and microservices locate each other on a network—aiming to simplify service configuration management within a microservices architecture where the volume and frequency of service-to-service communications is high. Service discovery implementations include a central server (or servers) that maintain a global view of addresses, as well as clients that connect to the central server to update and retrieve addresses.
- A service mesh is a configurable, low-latency infrastructure layer designed to handle a high volume of network-based interprocess communication between services that make up an application. In other words, it is a way to control how different parts of an application share data with one another. Instead of using discrete appliances, service meshes provide a scalable way to implement highly-available services within modern applications through API. This makes it easy to make infrastructural improvements while avoiding downtime.