HashiCorp this week updated its Consul service mesh to make it easier to manage namespaces across multiple services.
Previously, DevOps teams would have to manually ensure each namespace assigned to a group of services did not conflict with each other. The release of 1.7 of Consul enables teams to restrict access to services residing in isolated environments on a shared cluster, eliminating the issue.
In addition, DevOps teams can now delegate administrative privileges for a given namespace to individual teams, which enables them to manage their own services in keeping with best DevOps practices, rather than having to rely on a cybersecurity team to manage that process for them.
With the rise of microservices based on containers, interest in service meshes to provide a means to discover and manage services is on the rise. However, services span both emerging microservices-based applications and legacy monolithic applications. Rather than adopting a service mesh that only runs on one platform, HashiCorp is opting for an open source service mesh that spans multiple platforms and is easier to deploy and manage than rival offerings such as Istio.
Amith Nair, vice president of product marketing at HashiCorp, said that approach also makes it easier to deploy a service mesh at scale across multiple clouds and on-premises IT environments. Because Consul is designed to deployed on top of proxy servers such as Envoy or NGNIX, it can be deployed almost anywhere to manage services sprawl across the extended enterprise, noted Nair.
As far as the adoption of service meshes are concerned, it is still early days. Many organizations are in the process of shifting away from managing applications to focusing on services that span multiple applications. Given all the dependencies that exist between various services, that shift represents a major challenge. A service mesh alleviates some of that challenge by providing a mechanism for both discovering and governing services that are increasingly interdependent.
That approach also provides the added benefit of allowing teams tasked with governing and auditing IT environments to focus more on higher levels of abstractions versus updates to every line of code on which those services are constructed.
For now, there are no standards, de facto or otherwise, in terms of service meshes. Many organizations may find themselves adopting multiple frameworks, which may lead to further advances in interoperability specifications such as the Service Mesh Interface between rival platforms.
Less clear for now is who inside an IT organization will be responsible for acquiring and managing a service mesh. In some organizations it might be a network operations or cybersecurity team. In other organizations, those roles may have already been incorporated within a larger DevOps team.
Regardless of the approach, the need for some type of service mesh is becoming more apparent. The good news is there is now no shortage of options. However, DevOps teams should note that in terms of overall complexity and amount of compute resources consumed, not all services meshes are the same.
