With Gloo Enterprise 1.0, Solo.io Builds the Stepping Stones to Service Mesh

Portworx sponsored The New Stack’s coverage of KubeCon+CloudNativeCon North America 2019.
Solo.io has released the first production-ready version of Gloo, its enterprise-grade service mesh and API gateway. As its name would suggest, Gloo Enterprise 1.0 acts as the sticky link between traditional and modern distributed architectures.
The idea behind Solo.io is to help customers modernize their infrastructure. CEO and Founder Idit Levine told The New Stack that most of their customers are large-scale financial enterprises who over the last two years have been using Solo.io on their journey from monolithic to microservices architecture. The company debuted this technology at the KubeCon+CloudNativeCon North America 2019 conference, being held this week in San Diego.
Levine says her clients refer to Gloo 1.0 as the first stepping stone toward service mesh. It was created to solve a simple problem facing most large-scale enterprises with services distributed across environments, clouds, and regions. Microservices communicate via APIs which she said called for an API gateway. Levine argues it needed to be a simple one, that worked the same across legacy, serverless and Kubernetes-based services because no transition from a monolithic to many services is quick and all of these pieces have to communicate together.
Since most of Solo.io’s current customers are big players in the financial space, Levine calls this “serious business because basically we’re taking over all the networks.”
“If we’re doing something wrong, all the infrastructure is down,” she continued talking about how much responsibility she feels.
“Whatever you’re doing Gloo is making sure you’re on the network,” Levine said.
One long-time client is Internet giant Vonage. Vonage’s Chief Technology Officer Sagi Dudai said, in a statement:
“Gloo Enterprise’s robust technology, coupled with the collaborative Solo.io team, allows us to deploy these capabilities across regions and cloud providers, while integrating with our authentication mechanism to deliver business requirements for advanced usage plans and with our CICD pipelines to enable Vonage’s autonomous team.”
Gloo allows organizations to build in the same way, irrespective of cloud provider, environment or kind of service, all while running in production.
Gloo gets bonus points for preemptive coolness as it was built two years on top of Envoy, the now very popular high-performance proxy for traffic in and out of the service mesh.
Levine says that Solo.io is the only company so far to actually write an extension to Envoy, which includes a web application firewall, a web assembly engine, data loss protection and a way to delegate your domain. These are all bare minimums for regulated finance clients moving toward these more distributed architectures.
Solo.io also seamlessly runs atop Kubernetes, including the storing of custom resource definitions or CRDs.
Together with Microsoft, Solo.io developed Service Mesh Interface (SMI) to act as a translator between different meshes allowing them to look alike in production, communicate the same “language” across multiple service meshes, and to share the same root certificates. It allows you to manage and operate your service mesh, and it allows you to install service mesh on your cluster or to rediscover what was already installed.
Levine said they developed this because you’re never running just one instance of a mesh, but rather many across different clusters and cloud services.
She calls this “flattening the networking — every service mesh can react with another service mesh in the same cluster.”
Finally, earlier this week the company also released an open sourced Autopilot operator framework. It was created to tackle the problem of service mesh operation.
“If you give the wrong configuration to service mesh, seriously, your data center is down.” Levine said. “The best way to make sure people are not making a mistake is to make sure people don’t have to do anything.”
Developers will often make a change to their service mesh during progressive delivery, which can lead to large crashes.
Levine says that with Autopilot you create a threshold. Autopilot monitors your mesh, your environments, metrics and services including Github and Webhooks. And if something crosses that threshold, Autopilot will automatically stop that service and rollback to the previous version.
Levine described the company goals and process of tooling this way:
“First we are helping customers today to manage their microservices and APIs with a next-generation API gateway. Then we are helping them adopt the service mesh — no matter which type, no matter where, no matter which cloud or workflow. And then we have them extending on this service mesh to make sure their mesh is adaptive and we are doing this using Autopilot.”
You can join a demo on Gloo Enterprise Dec. 5, 2019.
KubeCon+CloudNativeCon is a sponsor of The New Stack.
Feature image by enriquelopezgarre from Pixabay.