Solo.io Adds Support for Istio to Rebranded Gloo Portfolio
Solo.io announced today that it has added Gloo Mesh Enterprise, an enterprise version of the previously named Service Mesh Hub offering, which now includes support for the open source Istio service mesh.
In addition, the company is rebranding its entire portfolio around using the Gloo naming convention.
The first platform Solo.io created was Gloo, an application programming interface (API) gateway and ingress controller for Kubernetes environments, now called Gloo Edge.
The rest of the rebranded company portfolio includes Gloo Portal, previously known as Developer Portal, which provides a way to catalog and consume more easily running application APIs; and Gloo Extensions, a set of developer and operator tools to customize open source Envoy proxy software using modules written in WebAssembly.
All of these offerings are incorporated in the Gloo API Infrastructure Platform suite of tools for managing and securing application connectivity.
Solo.io CEO Idit Levine says the company decided to add support for Istio because organizations that were relying on Gloo Mesh as a management plane for Istio requested the company also provide support for the service mesh developed by Google, IBM and Lyft.
Competition among providers of service mesh platforms is now fierce, with the emergence of multiple alternatives based on the Envoy proxy software, which was also employed to build Istio. There are also options based on other proxy software from NGINX as well as Linkerd, an open source service mesh being developed under the auspices of the Cloud Native Computing Foundation (CNCF). Additonally, HashiCorp offers its Consul service mesh.
Levine believes Istio will ultimately prevail because of the level of industry support it has already garnered and the ability to extend the platform using WebAssembly. As service meshes continue to evolve they are providing a programmable layer of abstraction above network and security infrastructure that eliminates the need for developers to master multiple low-level networking APIs. 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.
The primary criticism of Istio has been its size, an issue Levine says members of the open source project have begun to address by streamlining the platform without sacrificing functionality. Rival lighter-weight service meshes have sacrificed functionality to reduce the size of those platforms, she contends.
It’s too early to say how the service mesh wars will play out, but it’s clear Solo.io is betting everything on Istio. Most IT organizations don’t generally employ a service mesh until they have deployed hundreds of microservices that have exposed APIs across a variety of networking underlays.
Service meshes will eventually have a profound impact on networking and security. Rather than relying on software-defined platforms from various vendors to make networking services programmable, a service mesh provides a single framework through which all the underlying APIs exposed by networking vendors become more accessible to developers. As that capability is employed more widely, the ability of any networking vendor to lock an IT organization into a specific architecture becomes substantially less.
