Solo.io stole the show at cloud field day 6

I attended Cloud Field Day 6 this September and my favorite presentation hands-down was from Solo.io. There were other strong contenders, but Idit and Christian stole the show with their laser-precise product focus, infectious enthusiasm, and high-quality demonstrations. I overhead someone say that it was a masterclass in how to do a Tech Field Day presentation, which is especially impressive for a first-time presenter. I wrote a post about what I thought of Solo.io’s various projects before I went to CFD, here are my updated thoughts on their offering and the team behind it.

The YouTube videos for Solo.io can be found on their Cloud Field Day page, and I have embedded the introduction video below.

Idit Levine, the Founder and CEO is a bit nervous, as are many presenters, but she is also clearly excited about the project. Words seems inadequate for the deluge of information she is trying to communicate, and I feel like she would rather open our heads and pour knowledge directly on our brains. Sadly that doesn’t appear to be possible today. Maybe that will be her next startup.

Idit and her Field CTO, Christian Posta, are both clearly excited with the solutions they have to offer. The larger question is whether others will find it equally compelling. What are their solutions and is there a product fit? The presentation focused on three main offerings:

• Gloo
• SuperGloo
• Dr. Gloo

Gloo is an API gateway using the Envoy proxy. It functions as a control plane layer on top of Envoy, to provide a more user friendly experience and integration with non-Envoy endpoints. There were two things that gelled with me after I noodled on it a bit. The first is that they are not trying to build a competitor to the proxy solutions already out there. The primary target is Envoy - you’ll get the best performance from containers leveraging it, but other targets are fine including Serverless and legacy applications. The demo showed an application that was composed of a legacy web server, a microservice for displaying table data, and an AWS lambda app providing a contact page for the website. All three were stitched together using Gloo. The process was simple, secure, and could be driven via UI or with YAML configs. The project itself is open-core with certain additional functions only available in the paid version.

SuperGloo is a service mesh orchestrator. Today many service meshes are not particularly simple to manage, and if you have multiple service meshes across your organization your problems increase exponentially. You may also have different teams choosing different service mesh solutions, with one using Linkerd and another using Istio. Each one has a different API and complicated settings. SuperGloo is meant to be the control plane of service meshes, abstracting their APIs and settings to a common framework in order to simplify operations. I wasn’t entirely sure how many companies are actually deploying a single service mesh, let alone multiple service meshes necessitating a service mesh hub. However, I was assured by my new friend cxi, for those companies that are using microservices and have not yet deployed a service mesh, they will very soon.

“Service Mesh is a hot topic, but not too many people are actually doing it.” #CFD6 @soloio_inc @christianposta - So true, Service Mesh is widely not used, but widely needed!

— Christopher Kusek (@cxi) September 27, 2019

SuperGloo seems to simplify the management of a even a single service mesh, and will help organizations as they grow to multiple service meshes in their environment.

Dr. Gloo is a solution meant to assist with the health of your application in a number of ways. It’s an extensible solution, with a number of extensions already provided by Solo.io. They chose to highlight two of those, Squash and Loop. Squash provides the ability to debug distributed applications across multiple services in order to determine what is causing an outage. Distributed apps are notorious hard to debug, since there is no longer a monolithic application on one or two servers to debug against. Squash is trying to provide that monolithic debugging experience on a distributed application. In a lower environment you might be able to run the debugging directly on the impacted systems, but in production that might not be feasible. Loop allows you to collect the state of a distributed application when an error occurs, and then reproduce that error and debug the state of the application with Squash on a non-production system.

Many of the solutions shown by Solo.io lean towards the developer side of the experience, but as with many things in the cloud, that line is becoming increasingly blurred. Who is responsible for setting up and managing an API gateway? Who should be making sure that the proper toolset is in place for deploying service meshes? While many of these objects are software-defined, I think at least some of these job functions fall squarely in the Ops category or at the very least sit on the fence between Dev and Ops.

There were two overriding concepts that Solo.io kept talking about in their presentation. The first is that they are customer driven. Product roadmaps and features are based off of real customer requests from large companies, and not the fanciful ideas dreamt up in a windowless room. I don’t mean that Solo.io is just giving customers a better buggy whip, I mean they are looking at the real problems customers are having and developing a novel solution to meet the customer and their challenges where they are today. The second big point was that they are developing solutions that are complimentary to existing solutions. SuperGloo is not trying to be a service mesh - an already crowded space - they are providing a service mesh agnostic solution to manage the service mesh sprawl that is surely coming.

Whether Solo.io gets picked up by a large company or continues to develop their solutions on their own, I have no doubt that they are a name to remember in the cloud-native market segment.