Istio service mesh doyen departs Google, touts Ambient Mesh

Google's cloud-native networking pioneer, who co-created prominent technologies such as gRPC and Istio service mesh, took on a new role this week as CTO of application networking platform vendor Solo.io.

Louis Ryan, principal engineer at Google since 2007, is the second prominent name from a large company to defect to Solo.io -- last year, Brian Gracely departed Red Hat, where he had worked for nearly six years as director of product strategy, to join Solo.io as head of marketing.

As Ryan joins the company, it's potentially a watershed year for the Istio service mesh open source project, which is preparing a new sidecarless version called Ambient Mesh for production readiness. Ambient Mesh is focused on easier deployment and management of mutual Transport Layer Security (mTLS) to boost its popularity among regulated enterprise customers, after earlier versions of Istio proved too difficult and complicated for many of them. Solo.io plans to make its own version of Ambient Mesh available to customers later this month during KubeCon Europe, according to Gracely; an early-access version is in preview now with a handful of large customers.

With security issues in the spotlight for IT pros, Ryan's first priority will be positioning Ambient Mesh for a major new wave of enterprise adoption, if Solo.io and its new CTO have their way. Ryan spoke with TechTarget Editorial last week, ahead of his first official day at Solo.io Monday.

Why now, and why Solo.io?

Louis Ryan

Louis Ryan: The first company I ever worked at was a startup -- if you don't count summer jobs, that is. I've worked in a lot of different things at Google, but the last seven years at Google, I worked on open source things -- first gRPC, and then Istio, turning those either into technologies or products, and driving market demand for them. I've been thinking about the startup thing for several years for a whole variety of reasons. Early last year, we were partnering with Solo.io at Google on developing Ambient Mesh, and I was impressed with how Solo went about its business, the technological capability of the team -- how quickly we were able to come to a melding of minds about how to drive the space forward.

I'm very invested in this application networking space. That's what I've been doing for about 10 to 12 of those 16 years at Google, and it's Solo's sole mission. Obviously, there's lots of other things going on at Google, and it can be sometimes a little distracting. So those two things together, plus the opportunity to work at a startup again, were ultimately what motivated me.

What is your answer to that question, about how to drive the space forward?

Ryan: We're going to talk about Ambient Mesh a bit more. Ambient Mesh had been an idea that had been kicking around as much as five years ago. But it's not always easy to bring ideas to market. It takes a lot of resources -- you have to take resources away from other things. Ambient Mesh is what I view as the next iteration of service mesh.

I have heard from users in the space that getting to that mTLS checkmark so they can meet some compliance requirements will motivate a larger market.

The pace of the progress of Ambient is impressive, but this is a complicated space. There's a complicated set of technologies. It takes a lot of work to get something like this right. But you're starting to see these posts coming out of the community about the effects that operators, cluster owners and various other roles will see from Ambient as it starts to get uptake.

Ambient splits transport security and that adoption phase from other features of the service mesh. We see customers very rapidly go and deploy that, and then more incrementally start to adopt the other features of service mesh. I have heard from users in the space that getting to that mTLS checkmark so they can meet some compliance requirements will motivate a larger market.

What stands between Ambient and beta or general availability versions? What kinds of things must be ironed out before it's ready?

Ryan: I think probably the right word to use is polish. There are some functional decisions to be made at the API level and configuration. Ambient will support the existing Istio API. There are some refinements to be made to it, but probably nothing that an existing Istio user would notice. [But] some aspects of the Istio API become a little bit less relevant. There was a feature in the Istio API to say, 'I want to incrementally turn on mTLS for these pods, and these pods and these pods.' That will make a lot less sense in Ambient because mTLS can just be on for everything all the time. So those types of features should start to fade away.

What is the biggest challenge to Istio and Solo.io in the coming year?

Ryan: For Istio, it's an execution thing, just making sure that Ambient lands well, has the quality documentation, support and tooling necessary to make it effective. We learned some painful lessons over the years about what does and does not constitute a good release process, and we're a lot more mature about that now, so I don't really expect to see a lot of problems there.

I think the other thing we'll see for Ambient is that it's cheaper to use, to deploy and to run. So existing Istio users for the most part will just convert over for cost and efficiency reasons. With the new Rust-based proxy for Layer 4, this will shift radically, actually. This proxy -- which we call Ztunnel -- its sole job is to do mTLS, encryption and Layer 4-based routing. It's incredibly simple and incredibly efficient.

For Solo, there's so much market opportunity in this space that's still untapped. So, coverage and reach.

Linkerd has been in the market for years, talking about an ease-of-use story with mTLS -- is that anything that you're willing to comment on?

Ryan: Istio is the clear market leader. Istio pioneered all these features. Other projects have tended to follow the features that Istio has added. Istio has gotten a lot more usable. It's important to remember these features exist because there's a need for them -- not because it was just like, throw a bunch of darts at the wall. And the fact that other projects have gradually added them after the fact is just pointing out the fact that they were useful in the first place, and Istio's ease of use has gotten considerably better. I don't think that's a major problem with the project anymore.

By shielding end users from the infrastructural machinations of the project -- sidecars expose application developers to infrastructure -- you're going to see a shift in the perception of service mesh from a thing that gets installed with your application everywhere to being a feature of the network that you get to use when you want to. And if you don't want to use it, you don't have to think about it.

Editor's note: This Q&A has been edited for clarity and conciseness.

Beth Pariseau, senior news writer at TechTarget Editorial, is an award-winning veteran of IT journalism. She can be reached at [email protected] or on Twitter @PariseauTT.