SuperGloo Unifies Management of Multiple Service Meshes
As companies experiment with service meshes or different teams within a company adopt different meshes, the challenge of managing multiple versions becomes a reality. Or it will, according to Idit Levine, founder and CEO of Solo.io.
The company, based in Cambridge, Massachusetts, is originally known for the hybrid app gateway Gloo, and has come up with what Levine calls “multi-mesh” management called SuperGloo. Like Gloo, it uses functions as the common denominator across a range of mesh technologies, including Linkerd, Istio, AWS App Mesh, Hashicorp Consul and more.
“Maybe they’re using Istio on-prem, but going to AWS, they need to use App Mesh… Maybe on Google you use Istio, but on-prem you use Consul. Or you have different groups that chose different meshes. There is this trend of saying instead of installing one big mesh, you should install one big cluster in Kubernetes and make it multitenant and install a lot of small ones. It makes me believe there’s going to be more than one mesh and they’re going to run everywhere,” said Levine. “For organizations, it can be a problem to operate all this.”
Edwin Yuen, senior analyst at ESG, calls it a coming challenge, though he sees Solo well-positioned to take it on.
“There’s significant interest. It’s almost like pressure with so many options out there,” he said.
“It’s not so much managing multiple meshes, but that abstraction layer so you can mix those pieces. …We haven’t seen management at a level above where the meshes are.”
Open Source Project
“The service mesh became an essential ingredient in the cloud native computing architecture and has led to many competing players. Solo.io has seen how the this market is shaping out and created SuperGloo to provide an abstraction layer that allows developers to build out further the cloud native stack without needing to be constrained by which service mesh flavor is in use. It’s a clever positioning that benefits the cloud native computing community, as well as create a platform for Solo.io’s plug-ins for SuperGloo,” said Ovum analyst Michael Azoff.
Like Solo’s other projects, such as Gloo, which is built on the Envoy proxy, and Squash, a debugger for microservices and Kubernetes, SuperGloo is open source. The company’s plans are to commercialize features it builds on top — it recently released the enterprise version of its gateway GlooE.
Solo’s solution is a flat network between the different meshes used within an organization to treat them as a group for management and monitoring. It makes installation and configuration simple and controls third-party tools and plug-ins centrally.
A single API controls functionalities such as encryption, telemetry and tracing and unifies logging and tracing. SuperGloo automatically configures existing Prometheus, Grafana, and Jaeger installations to extract data from the meshes and eliminate the need to edit YAML files and Kubernetes configmaps.
It integrates with ingress controllers for combined management of north/south and east/west traffic, and allows users to pair any service mesh with any ingress with SuperGloo handling installation and configuration.
Customers want to adopt service mesh. They think the technology is very solid, but they don’t know which one to adopt, so they’re trying them different ones, Levine said.
“Today it’s all very complicated. If you want to do a retry in one of the services running on Istio, you have to create four different services, then create the retry,” she said.
“Once you install Supergloo, everything is a toggle. Do you want observability? Or you don’t want observability? Do you want certificate? Or you don’t want certificate? … It’s very simple out of the box in a very clear way; the user shouldn’t have to take care of anything.”
The company is building a suite of tools on top called Dr. Gloo, which it will open source soon, Levine said. The first one, GlooShot, is chaos engineering on top of mesh. It will give resilience to the application without having to change the application and will work with multiple programming languages.
“It will all be based on the notion that we need to take care of the health of the application running on top of those meshes,” she said.
The state of services meshes was the main topic during The New Stack Makers panel discussion at KubeCon + CloudNativeCon North America 2018.
Service meshes form the basis of giving identity to microservices and understanding what the interactions between them are and facilitate attaching policy, security and other controls to them, Pere Monclus, vice president and chief technology officer for network and security, VMware, told the group.
‘Safety Blanket’
Yuen foresees multi-mesh management becoming an issue similar to multicloud management.
“[For] those who are looking to do that migratory work from existing monolithic applications and, of course, all those trying to figure out what to do between microservices and serverless — just bringing all those functions together, the potentially replacing just parts of an application, I think it’s going to be very interesting,” he said.
“It literally gives a toe-in-the-water type of entry to a lot of companies that haven’t come along to adopting microservices or serverless yet or haven’t started the migration. As they go out and hire groups that are going to be advocates for certain meshes, I think that’s where SuperGloo comes together also.
“[It] answers a lot of questions that enterprises have about where they’re going to go in their app directions. It’s almost like a technical safety blanket. They can accomplish what they want to accomplish. But for those that are a little more conservative or gun-shy, they can do it in a very staged manner.”
KubeCon + CloudNativeCon and VMware are sponsors of The New Stack.
Feature Image: “CT_Mesh 13” by Swtiruty Rgbytw. Licensed under CC BY-SA 2.0.
