Extends Framework for Managing Istio Service Mesh

At its online SoloCon event, announces updates to its Gloo Mesh Enterprise service mesh that add support for multi-tenant workspaces and improve support for virtual machines. In addition, announced a unified application programming interface (API) for managing the platform and a user interface to improve observability.

At the same time, reveals its Gloo Edge API gateway for edge computing platform now includes beta support for GraphQL-based APIs in beta and a natively embedded GraphQL server. CEO Idit Levine says the updates reflect the need for more robust tools for managing Istio as more organizations start to deploy the service mesh in production environments. reports it has seen a 390%+ year-over-year annual contract value (ACV) bookings growth, with a 95% gross retention rate. Overall, the company claims a more than 120% increase in new customers in the last year. Last year, also raised an additional $135 million in funding.

The Gloo Mesh Enterprise service mesh is based on the open source Istio project. It’s too early to say whether Istio is emerging as a de facto service mesh standard. However, within IT teams that have adopted Kubernetes, there is a tendency to embrace a service mesh that, like Kubernetes, was originally developed by Google. The challenge is that, compared to other service mesh platforms, Istio is more challenging to deploy and maintain. This complexity creates demand for frameworks such as Gloo Mesh to make Istio simpler to manage at scale. Gloo Mesh, for example, makes it easier to take advantage of Istio capabilities such as global service load balancing, end-to-end zero-trust security and federated traffic management.

It’s not clear when organizations might look to a service mesh to manage APIs in place of proxy software or a legacy API gateway. However, as organizations find themselves managing hundreds or thousands of external- and internal-facing APIs that provide access to both monolithic applications and microservices-based applications deployed on Kubernetes clusters. More challenging still, organizations are finding they need to manage a much wider range of API types as those based on GraphQL are deployed alongside REST APIs.

Regardless of the service mesh organizations choose, a programmable layer of abstraction is emerging that sits above network and security infrastructure and eliminates the need for developers to master multiple low-level networking APIs. In addition to making APIs simpler to manage, that abstraction layer is also extensible to the point where developers can create rules within a service mesh to create, for example, a firewall for a specific set of APIs. In the case of, the tools for creating those extensions are based on the WebAssembly programming framework.

It might be a while before services meshes are pervasively deployed across an enterprise. However, it’s already clear that service meshes will play a critical role in driving a level of conversion across DevOps, networking and security teams that has been difficult to achieve thus far. The next big challenge will then be fostering a level of cooperation among teams today that have radically different cultures.

Mike Vizard

Mike Vizard is a seasoned IT journalist with over 25 years of experience. He also contributed to IT Business Edge, Channel Insider, Baseline and a variety of other IT titles. Previously, Vizard was the editorial director for Ziff-Davis Enterprise as well as Editor-in-Chief for CRN and InfoWorld.

Mike Vizard has 1627 posts and counting. See all posts by Mike Vizard