Many HashiCorp Consul users see the value of extending the tool they already use for service discovery to include service mesh, but adopting the complex technology will be difficult.
A service mesh provides a central network management plane that orchestrates sidecar containers attached to each application service. It offers granular security, traffic management and observability advantages over traditional virtual networks. The service mesh approach has risen in popularity along with container-based microservices, as its fine-grained network visibility is better equipped to handle large numbers of network connections among diverse app programming languages and protocols.
HashiCorp Consul added service mesh capabilities with Consul Connect, first released in 2018. However, IT pros are only just getting used to managing container orchestration tools such as Kubernetes in production, and integrating a service mesh amid that transition only adds to the difficulty.
"The struggle of operations is widely [known] -- I myself come from an operations group in my previous position," said Nathan Bennett, cloud architect at HashiCorp partner Sterling Computers, a VAR in North Sioux City, S.D. "The problem of application uptime for our customers, application deployment time, as well as scaling, can still be painful, time-consuming processes."
HashiCorp doesn't expect users to move to Consul service mesh overnight, said software engineer Freddy Vallenilla in a HashiConf presentation this week.
Consul 1.8 gateways aim to ease service mesh transition
HashiCorp Consul software engineers acknowledged those challenges during a presentation at the vendor's HashiConf virtual event this week. They discussed features added in Consul version 1.8, released on June 18, that they said will help with a gradual move to the advanced network architecture.
Network and security teams will need time to adapt to this new way of operating, and this is something we've tried to enable with our new gateways.
Freddy VallenillaSoftware engineer, HashiCorp
"I would like to emphasize that we do not expect organizations to [immediately] drop their old model when transitioning to a service mesh," said Freddy Vallenilla, Consul software engineer at HashiCorp, in a presentation about Consul 1.8 at the event. "Network and security teams will need time to adapt to this new way of operating, and this is something we've tried to enable with our new gateways."
Consul 1.8 adds three new features, two of them additional types of network gateways, that Vallenilla said will facilitate network communication between traditional networks and service mesh environments. The first is a terminating gateway, which forms a logical boundary between traditional and service mesh environments and controls traffic as it flows from apps in the Consul Connect service mesh to external networks. The second is an ingress gateway that similarly routes traffic from outside the service mesh to services within it.
Finally, Consul 1.8 adds support in the Consul Connect mesh gateway for WAN federation, so that Consul control planes in different data centers can detect failures and route traffic without having to expose every service over a WAN (wide area network), which adds to security management overhead.
Service mesh evals account for competitors, third-party tie-ins
The new gateways in Consul 1.8 are appealing to users who already use Consul service discovery to facilitate API-based connections and monitoring for existing applications.
"[Adding Consul service mesh] would mean one less thing someone would have to run," said Connor Kelly, a site reliability engineer at an online job portal company. "The new ingress gateways look nice for connecting one data center to another."
Kelly said he's advocating for his engineering team to replace a homegrown service mesh equivalent with Consul Connect, but that team will also consider Istio as part of its due diligence. Istio dominated the industry conversation around service mesh after it was first introduced by vendor heavyweights IBM and Google in 2018, in part because of its powerful backing, especially from the company that created Kubernetes.
However, Istio has been challenged in the last six months, after Google indicated its reluctance to donate the service mesh project to an open source foundation for governance, and Istio 1.5 presented a potentially disruptive architecture change for the control plane. That version moved Istio's control plane from a distributed set of microservices to a monolith, leaving the sidecar data plane distributed, which is how the Consul service mesh has always worked. However, Istio was quicker to support edge gateways.
Consul users who prefer sidecar proxies other than Envoy also await full integration into Consul Connect. These users include Pierre Souchay, security team leader at Criteo, a marketing technology company based in Paris. Souchay manages service discovery in an environment with about 4,000 bare metal server nodes with Consul. Criteo would like to move to Consul Connect service mesh, but using HAProxy as a sidecar.
"We are working with HashiCorp on the HAProxy tech to develop it further, and only using Connect for now to add TLS between data centers, but we're mostly not using the ingress stuff," Souchay said.
Criteo engineers prefer HAProxy because they already have experience using it, and it is compatible with some legacy Linux operating system versions that don't work well with Envoy, he said.
The HAProxy update wasn't ready with the release of 1.8.0 and will have to wait for a later dot release, according to Souchay. However, Consul 1.8 also includes scalability optimizations, including the ability to send only differences between requests from nodes to Consul, which will help Criteo continue to scale beyond its current node count, Souchay said.
Other users will have to weigh potential overlap between Consul's new gateways and other existing tools such as the open source Traefik.
"Traefik works on Docker Swarm as well as Kubernetes… as we move more to Kubernetes, I'm keeping an eye on [Consul Connect]," said Phil Fenstermacher, systems engineer at the College of William & Mary in Williamsburg, Va. "We also use a lot of the HTTP middleware offered by Traefik 2.x, so we'll need that to match too… maybe one day [we'll switch], but we're very happy with Traefik, so we're not looking to have it pushed out anytime soon."
HashiConf attendees illuminated other potential service mesh integration hurdles in an online Q&A session that coincided with Vallenilla's virtual presentation. Consul admins must make changes to Consul service registry files and DNS to connect with sidecar proxies instead of existing application endpoints as they adopt service mesh. They must also self-manage high availability for the new gateways, HashiCorp officials acknowledged.
Nomad-Consul combo draws closer to Kubernetes
HashiCorp officials also confirmed in the HashiConf Q&A that the new Consul gateways offer a more "pod-like" experience, including IPtables support, for the Nomad container orchestration engine, drawing it closer to Kubernetes-like features.
Nomad 0.12, released this week in public beta, added advanced resource scheduling, promoted the autoscaling feature to tech preview from beta, improved support for open source container networking interfaces and now allows Nomad to connect to multiple networks at once.
HashiCorp co-founder Armon Dadgar touts new Nomad networking features in a HashiConf keynote presentation this week.
"Nomad since the 0.1 release has had support for multiple data centers and multiple regions and federation between all of them… but what we haven't had the ability to do was define a single job that simultaneously exists in multiple regions," added Armon Dadgar, co-founder of HashiCorp, in a keynote presentation this week.
Dadgar touted the Nomad 0.12 release as "federation made real." Such cluster federation remains a work in progress in the Kubernetes community.
"Now you can define a single job that spans multiple regions," Dadgar said.
