HashiCorp Consul Enterprise Supports VMware NSX Service Mesh Federation

Recently at VMworld 2019 in San Francisco, VMware announced a new open specification for Service Mesh Federation. This specification defines a common standard to facilitate secure communication between different service mesh solutions.

Service mesh is quickly becoming a necessity for organizations embarking upon application modernization and transitioning to microservice architectures. Consul service mesh provides unified support across a heterogeneous environment: bare metal, virtual machines, Kubernetes, and other workloads. However, some organizations may choose to run different mesh technologies on different platforms. For these customers, federation becomes critical to enable secure connectivity across the boundaries of different mesh deployments.

We have partnered with VMware to support the Service Mesh Federation Specification. This blog will explain how services running in HashiCorp Consul service mesh can discover and connect with services in VMware NSX Service Mesh (NSX-SM).

»What is Service Mesh Federation

Service Mesh Federation is the ability for services running in separate meshes to communicate as if they were running in the same mesh. For example, a Consul service can communicate with an NSX-SM service running in a remote cluster in the same way it would communicate with another Consul service running in the same cluster.

»How Does Consul Enterprise Support Service Mesh Federation

»Service Sync

The first step towards supporting federation is Service Sync: sharing which services are running on each mesh. To accomplish this, Consul Enterprise implements the Service Mesh Federation Spec via the new Consul federation service. The Consul federation service communicates with NSX-SM’s federation service to keep the service lists in sync so that each mesh is aware of each other’s services.

First, Consul sends the foo service to the remote federation service and receives the bar service.

Next, Consul creates a Consul bar service to represent the remote bar service.

»Inter-Mesh Communication: Consul to NSX-SM

With services synced, Consul services can now talk to remote services as if they were running in the same cluster. To do this, they configure their upstreams to route to the remote service’s name.

In this example, the Consul foo service wants to call the NSX-SM bar service. We configure an upstream so that port 8080 routes to bar:

service {
  name = "foo"
  connect {
    sidecar_service {
      proxy {
        upstreams = [
          {
            destination_name = "bar"
            local_bind_port = 8080
          }
        ]
      }
    }
  }
}

Then from the foo service, we simply need to talk to http://localhost:8080:

$ curl http://localhost:8080
<response from bar service>

Under the hood, we’re using the Consul service mesh sidecar proxies to encrypt all the traffic using TLS.

»Inter-Mesh Communication: NSX-SM to Consul

From the bar service running in NSX-SM, we can use KubeDNS to talk to the foo service in Consul:

$ curl foo.default.svc.cluster.local
<response from foo service>

This request will route to the Consul Mesh Gateway and then to foo’s sidecar proxy. The sidecar proxy decrypts the traffic and then routes it to the foo service.

»Conclusion

Service mesh federation between Consul Enterprise and NSX-SM allows traffic to flow securely beyond the boundary of each individual mesh, enabling flexibility and interoperability. If you would like to learn more about Consul Enterprise’s integration with NSX-SM, please reach out to our sales representatives to schedule a demo.

For more information about this and other features of HashiCorp Consul, please visit: https://www.hashicorp.com/products/consul.