HashiCorp Extends Consul Service Mesh Capabilities
HashiCorp this week announced it has made available an update to its open source Consul service mesh that is more application-aware and easier to install using the Kubernetes application programming interface (API).
Version 1.9 of Consul also includes visualization tools that provide access to a topology map that make it easier for IT teams to track requests, error rates and timing metrics.
Raymond Austin, director of product marketing for HashiCorp, says Consul provides an alternative to more complex service meshes that makes it easier to declaratively apply policies across microservices. Those policies enable IT teams to express their intentions concerning what microservices are allowed to communicate with one another all the way up through Layer 7 constructs of an application, he notes.
Other new capabilities include being able to install Consul on the Red Hat OpenShift platform, which is based on Kubernetes, using a Helm Chart, as well as the ability to integrate Kubernetes health checks into Consul to ensure that traffic is not routed to pods that have known issues.
Finally, HashiCorp has reduced CPU and network bandwidth usage on Consul servers using a streaming capability to change how updated notifications for blocking queries are delivered.
As organizations start to deploy hundreds of microservices, the need for a service mesh to both govern microservices becomes more apparent. The service mesh also provides a layer of abstraction that masks the complexity of the network underlay that those microservices span. Developers can invoke network resources without having to master multiple low-level APIs that each provider of a networking platform has exposed.
HashiCorp is betting that rather than relying on more complex open source approaches, many IT organizations will prefer to rely on a platform supported by a vendor that also makes that capability available in the form of a managed service.
Austin also notes the decision regarding what service mesh to employ is starting to evolve as IT teams become more aware that service meshes represent a capability that needs to be horizontally made available across multiple application development and deployment projects. Today many service mesh decisions are being made by a small team that may have deployed only one or two large-scale applications based on microservices, he says.
It’s still early days as far as service mesh adoption in the enterprise is concerned. In fact, there may never be a single dominant service mesh platform. Interoperability standards will need to be ratified that enable organizations that have standardized on different service meshes to apply policies to microservices spanning hybrid cloud computing environments. Developers, networking and security teams will also need to achieve some sort of consensus on what types of service mesh to employ.
Of course, not every microservices-based application needs a service mesh right away. Many can get by using a traditional proxy server or Kubernetes Ingress controller for quite some time. Eventually, however, a more robust approach to managing microservices will be required, so IT teams would be well-advised to start exploring their options now.
