Red Hat cloud leader defects to service mesh upstart

Kubernetes is now old news for enterprise IT, and the industry has begun to seek out its next frontier. For one veteran product strategy leader, that frontier lies in service mesh and cloud-native networking.

Brian Gracely served as director of product strategy for OpenShift at Red Hat beginning in 2016, two years after the OpenShift Linux container platform was first ported to Kubernetes, and during its establishment as the most widely adopted enterprise Kubernetes platform in the industry.

In 2019, following Red Hat's acquisition by IBM, Gracely was named senior director of product strategy for all Red Hat Open Hybrid Cloud products. This week, he surfaced as the new vice president of product strategy at Solo.io, an API gateway and Istio-based service mesh platform startup that reached a $1 billion valuation after a $135 million series C funding round in October.

SearchITOperations met with Gracely this week during the SoloCon 2022 virtual event to discuss the similarities between service mesh in 2022 and Kubernetes five years ago, along with the opportunities and challenges ahead for enterprise IT in cloud-native networking.

Would you say that service mesh is now where Kubernetes was two or three years ago?

Brian Gracely

Gracely: Yeah, I think so. When service mesh first came out, Kubernetes was in such a fervor -- it had been three or four years, so people had gone through the high of it, and saw the potential, and then there was a little bit of a lull in the hype when it hadn't really exploded in terms of usage. So when service mesh came out, for certain people, it was just like, 'Oh, cool, here's the new thing.' And it was new, 1.0 sort of stuff.

If you fast forward, now, four years from that, Kubernetes is now at the point where it's super stable, it's being released less often. You have a lot more companies who are deploying Kubernetes [that are] starting to build new applications. We saw a lot of companies [during] the pandemic build new applications at a faster rate than they did before. [Solo.io customer] Chick-fil-A is an example -- at their thousands of stores as a franchise, before, most people parked their car, went in the store, then came out. Nowadays, the first interaction everybody has with the store is, 'I go on the app, I place my order, I get my loyalty points.' You don't even go into stores anymore, you go in the drive-thru, and you just point them to your app. Well, all those interactions are all APIs. All of a sudden, this is a new interface to the customer, and those are all things that fall into our purview. The pandemic accelerated some of that for us, as terrible as it was for a lot of things.

You have a unique perspective, having come from a Kubernetes platform company to this service mesh and application networking platform company. What are the similarities and differences for you?

Gracely: In terms of the people that use the technology, it's kind of this blended thing. If I said, 'Who's the Kubernetes buyer or the Kubernetes user?' It was never one distinct group. It's sometimes infrastructure, sometimes security, sometimes application teams. The space we're in now is still this cross-functional thing. You have to understand who's prioritizing what they care about -- is it more networking-oriented, more security-oriented? Is it more self-service for application developers?

Service mesh is still a space in which there's a lot of innovation. For us this week, we've talked about service mesh, which is becoming more of a stable mainstream thing, but then we're also talking about GraphQL or Wasm or eBPF. Back in the Kubernetes days, that was Kubernetes CRDs, Kubernetes Operators, Open Policy Agent. There's this constant education that goes on with customers asking, 'Hey, is this a new way of doing an old thing? Is it stable enough? Should I care?' It's slightly different parts of the stack, but it has a lot of similarities.

Red Hat also has an OpenShift Service Mesh. These are cross-functional platforms that also have crossover with each other. How do customers navigate those choices?

Gracely: OpenShift started off as a Kubernetes platform, and then a bunch of other things came on top of it -- service mesh was one, and serverless, and developer experiences. They vertically build a stack. The challenge they had -- that I had a week ago -- we would get some customers where we would sell to a central IT group, and you told them, 'You have all these capabilities; they're all built in and they're all integrated into the user experience.' And they would say, 'Oh, that's awesome. I don't have to maintain those things.' The flip side was, their security team would come back with, 'Yeah, but we've also been exploring this other thing, like the Solo.io service mesh, or this other CI/CD system, and we like that one better.' Red Hat's challenge with OpenShift is there's going to be a set of customers who will take the stack the way you give it to them, and there's another set of customers who are less centralized in their architecture.

We're seeing more and more central IT groups not have as much power or as much authority to dictate everything as they did years ago. Lines of business make their own choices. When people go to the cloud, they buy things on a service-by-service basis, and that tends to trickle back down and influence enterprise teams.

Isn't Solo.io creating another type of vertical stack within the networking domain? It's putting together the API gateway and the Istio ingress and service mesh, plus eBPF and GraphQL. How do IT buyers navigate all these different packages?

That's probably the biggest shift that we've seen in the last five or six years. You have to be a lot more flexible than, 'This is our stack and you'll use it no matter what.'

Gracely: It's still fluid. The thing that I learned the most in the OpenShift space over those six years was that the profile of a buyer in 2015 or 2016 and the profile of a buyer in 2021 to 2022 was really different. They were becoming more disaggregated, whether it was a group that dealt with on premises versus the group that dealt with the public cloud, or a quote-unquote DevOps team, and that means they're sort of responsible for five or six things mashed together. We were seeing that more and more. Early on, it was a very centralized group, centralized service -- what ends up happening is you have to be really good at delivering something so that when you go to your applications team, you say, 'This will immediately solve problems for you.' If it doesn't, they have all sorts of options of going around that centralized group. That's probably the biggest shift that we've seen in the last five or six years. You have to be a lot more flexible than, 'This is our stack and you'll use it no matter what.'

What's the biggest challenge that you're facing as you start at Solo.io?

Gracely: From a company perspective, it's scaling the business. They've figured out a really good way to engage customers and make them successful really quickly -- it's much more of a product-led growth strategy. Like every smaller startup company, scaling that is the big challenge. And I think the other challenge -- and this isn't unique to Solo -- is we're selling a product that gets used by multiple groups, and making sure that we're very good at identifying whose problem we solve, what pain points they have, and not just sort of going 'Yeah, it's anything and everything.'

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