Brendan: Hello everyone and welcome to PodRocket. I'm Brendan, I'm on the engineering team at LogRocket. And joining me today is Brian Gracely from Solo.io and The Cloud Cast. Brian, thanks for being here. Brian: Hey, thanks for having me. Good to be on the side of the microphone. Brendan: Awesome. Well, we'll put you through your paces today. I guess maybe a good place to start is just to talk a little bit about what you're currently doing. So Solo.io, tell us what it is, what you guys are building, and maybe we can talk a little bit about that. Brian: Yeah, absolutely. So Solo is a venture back company. We're about four years old. We're mostly in the sort of two spaces that are relevant to developers. We're in the API gateway space. So lots of folks will use the APA gateway for sort of what they'll call north and south facing traffic or outbound facing APIs. And then the service mesh space is a little bit newer technology, but it's kind of there when you're building sort of modern microservices applications. And all of a sudden everything has to communicate over the network as opposed to internal IPC calls. And it helps you with security and service discovery, and east wests APIs, and those sort of things. So we're very much sort of in the connecting and making APIs and applications available to people around the world. Brendan: And it seems like these products are both in the sort of Kubernetes space, right? Brian: Yeah, very much. You know, they build on a couple of technologies that people have probably, or maybe heard of. One is Isto. Isto the service mesh technology, and then ENVO proxy, which is a technology that sometimes is used by itself. It originated out of Lyft. And it's also become sort of the proxy technology that's most frequently used in the Kubernetes container space these days. Brendan: Yeah. So at LogRocket, we're running all of our sort services on Kubernetes and thinking a lot about, there's this whole ecosystem of services that are doing something along the lines of taking a problem that Kubernetes kind of makes hard to solve on its own, and abstracting that and managing it. And I think sort of your product falls into that space as well. How do you see that sort of evolving over the longer term? Is there going to continue to be a lot of space for those products that are solving a problem that's kind of distinct to Kubernetes? Do you eventually see Kubernetes absorbing some of those problems and providing more native APIs that do the kind of things that Solo does? What is the future of that space? Brian: Yeah, it's a great question. So prior to Solo, I was at Red Hat for about six years. So kind of going back time wise to Ron's origination when Kubernetes first came out. And what was interesting in that evolution was, Kubernetes is maybe for a lot of people sort of the first, Cloud native technology they might have played around with. There was another four or five years before Kubernetes, that was what was called platform as a service. So you'll sometimes hear the term PaaS kicked around. And the reason I bring those two things up is what people tried to do in the PaaS days was abstract things for developers, make it super simple to deploy stuff, hide a lot of complexity. Brian: And those are all really good goals to still have, and they're things that we want to do. The reason those PaaS things struggled was because they kind of built everything in for the system. So the system had everything from load balancers to API gateways, to service discovery, to the developer experience, all that sort of stuff. And the struggle it had was everything was sort of built in. And so it was great when it was great. And then when it wasn't, when it wasn't for what you wanted to do, you were like, "I can't," right? I can't build this application the way I want to, or I can't deploy it the way I want to. Brian: So what Kubernetes ended up doing was it kind of replaced the same goal as PaaS, right? It was like here, how do I package applications in the same way? How do I deploy them at scale? And what the Kubernetes community sort of did was they said, we're going to sort of stop at some point, and we're going to let other things fill in those gaps. And operations teams, app dev teams, dev south ops teams, whatever can kind of pick and choose what they want that lives north of Kubernetes. And so that's where things like what's Solo does, fill a void and they fill a void partially from, like you said, it sort of abstracts things, but it's also kind of a modular attempt at how to do some things. So if you like parts of it, cool. You use that. If you like a bunch of it, you can do those things as well. But I think that's the lesson we sort of learn from around Kubernetes is make it more modular. Brendan: Yeah. And this is kind of, I would imagine with the all in PaaS solutions, you're thinking about like Heroku is the one- Brian: Heroku yeah. Heroku- Brendan: That comes to mind. Brian: Pivotal cloud Foundry. Yeah. There's a bunch of them that were out there. Brendan: Yeah. Another question is kind of what type of teams is Solo for? Are these sort of something that a small startup would use? Is this something that a larger enterprise team would need? Is this something that all teams need? Brian: Yeah. I think what we've found in the market is there's a mix of companies that'll talk to us or are interested in the technology. You know, some of it is a mix of your sort of classic Silicon valley startup types of companies, so born in the Cloud, their tech stack lives in AWS or Azure. And then there's a set of sort of Fortune 500 Fortune 2000 types of companies who are solving some sort of problem of, I have some legacy or heritage stuff, and then I need to modernize and deploy new things. Brian: So, we've been fortunate that we've had a mix of them. I think what we find is it's going to be companies that kind of bias towards more modern technologies. So things like Envoy and others are kind of a next generation of what maybe was there when it was Nginx or HAProxy or something or another. And then it's customers who really value scale, they really value security. They value that it can run on Kubernetes natively. So those types of things kind of flesh out what our customer base tends to look like. Brendan: Yeah. And I guess by way of closing this bit, I'm curious what's next for you guys? Are there any big or exciting sort of roadmap items that you're looking at for 2022 that you want to share or talk about a little bit? Brian: Yeah. So we're lucky in when you're small, you get a lot of feedback from customers. They tell you exactly what they want, and they're not afraid to say, "Look, I'd love to shape your roadmap." So in our case, it falls into probably three or four big buckets. One of them is a lot of how do we use these technologies when we have these cross teams? So, you'll have an organization that one team is focused on this set of services, another one's focused on that set of services. And then sometimes there's a group that does centralized types of services. Maybe it's billing, or maybe it's account management or whatever it might be. So we've always been very good at being great to people do their outbound facing APIs, or scaling the system up to millions of calls. Brian: So there's a lot of work going on around how do we create multi-tenancy or sort of workspaces type of capabilities? So teams can share best practices, they can share kind of deterministically, what is this environment look like? They can use get ops and some things like that. So that's a big space for us. It allows us to work with larger customers with more complex environments. One of the areas that would probably pretty interesting to your audience is we've always been very good at sort of HDP types of APIs. We're seeing a lot of demand for GraphQL. So we're moving more and more of what we do to be very compatible with GraphQL. So we see it as it's another API that has to be protected that has to be scalable, resilient and that sort of thing. Brian: So bringing GraphQL into the platform, both for customer facing APIs, but also internal types of APIs is a big area focus for us. And then just kind of getting into a lot of scalability things. So you'll keep seeing us trying to scale how to do resiliency, how to scale so you're not spending as many cycles on certain kinds of things that'll hold back how well it scales. So those areas are a lot of the focus areas. There's some fine grain nitty gritty in there about what kind of authentication we do and other stuff, but those are the big areas we're focused on right now. Brendan: Yeah. And I completely feel that sort of frustration of trying to get something to work with GraphQL that doesn't already work with GraphQL, where I think a lot of telemetry and tooling has sort of adapted to it now, but especially a few years ago, you would have it just bundling everything under a single endpoint. And so all of your metrics would just get eaten and it was very tough to sort of get a system that was thinking about HTDP, Rust APIs, where everything is nicely parted out as resources in the URL. Brian: Right. Brendan: To actually think GraphQL as this problem space to solve for. Brian: Yeah. And just even simple things, what you'd think might be simple things, is teams will start spinning up GraphQL servers, and then all of a sudden somebody's responsible for maintaining them. And it's like, "Okay, that's separate infrastructure, separate sort of problem space than what they do for other APIs." And so how do you make policies consistent? How do you do resource controls? And so the feedback we've gotten from a lot of people is like, "Yes, the GraphQL kind of space is different in terms of how you aggregate data and how you build them. But like, we'd like to protect them same way we do other APIs. And is there kind of an overlapping space there?" Brendan: Yeah. And I guess there's a common thread there with the other thing you brought up around sort of providing more best practices and control within organizations that, especially as you build out these big Kubernetes architectures, software tends toward entropy, it becomes its own task to sort of maintain a well-architected system over time. Right? You get your migration done, everything's running on Kubernetes. What do the next five years look like? Brian: Yeah. And I think a lot of companies are sort of learning if you go back a few years, part of the reason the Cloud got so popular wasn't because it was necessarily cheaper, but it was, "Hey, I can, I can get the things at the speed I want without having to ask people for it." Or I wasn't bumping into these things where your IT team would go, oh, I can't that in whatever time you want, or, we don't know how to do that new technology. Brian: And so I think there's this new sort of concern that people have of like, we don't want to build these once again, build these sort of monolithic stacks, even if they're with new cloud native technologies, because at some point they become hard to maintain. You don't keep up the pace of it and all of a sudden your user base, your internal teams or your third party partners are like, "Okay, well I can't work with you anymore. I'm going to go somewhere else." So I think there's a little bit of scar tissue built up of how do we get here? Let's not repeat those same mistakes again. Or at least that same pattern again. Brendan: Your title is VP of product strategy. And I think that's something that might be interesting to talk a little bit about because it's not necessarily a role that exists in every organization. And I'm curious, for somebody who's never worked with a product strategist title before, what's your sort of pitch for the role and why it exists and what you do? Brian: Yeah. It's a good question. It's sort of one of these overlapping kind of titles, sometimes oxymoronic sort of titles. I think in reality, what you find sometimes at least in smaller organizations, maybe not so much in big organizations, is sometimes strategy is a thing that falls between product management, product marketing, how you engage age with your customers, how you engage with the marketplace in terms of communications and a bunch of things like that. So it tends to be one of those things where you go well, good enough at communication to a bunch of different kinds of people. So like I always joke around. I'm pretty good at talking to people if they're wearing t-shirts and I'm pretty good at talking if they're wearing suits and somewhere in between there, they both tend to be in meetings, right? Brian: One cares about the business and budgets and stuff, and the others care about protocols and CLIs and automation. And so there's a little bit of that. There's a little bit of being responsible for what's going on in the market today. Where does it look like it's going over the next couple of years? Because if you're a product manager, for example, you're focused on sprints, you're focused on the next release, maybe the next couple of releases. You're dealing with trade offs all the time of, do we do these features for this customer? Do we build some stuff new that nobody has necessarily asked us for, but we know we have to get there? So I spend a lot of time kind of living between these different teams. And you're right, it's not necessarily a role that you'll always see maybe early, early on because you're like, look, you run the product, you run sales, you run marketing, whatever. Brian: And then sometimes you'll see them in larger organizations when things get kind of complicated when you market has matured, and there's a lot of different options that people can choose in the marketplace. And if you sort of go look, we're betting the next two years or three years on these two or three big ideas. We want to have a pretty good sense of are they going to pay off? Right? What are the odds they're going to pay off? And so it's living a little bit between all those worlds from day to day, switching hats a few times from day to day. But yeah, you're right. It is sort of one of those things where you're like, I'm not really sure exactly what that means. And for me, I have to just be okay with the idea of on any given day, my job might be a little bit different than it was yesterday or the day before or the week before. Brendan: Yeah. So maybe as someone who has scar tissue from living through the JavaScript framework wars of 2014 to 2016, how do you figure out what the market's going to be doing in two years for your sort of space in technology? When that's your job, what does your process look like for sort of knowing the answer to that question? Brian: Yeah. Unfortunately, we don't get any crystal balls. So it's a combination of a lot of things. Typically, you spend time sort of outside the mainstream, so you're going to events. I can just give you some simple examples. So if you go to events, for example, let's say you went to AWS Reinvent, just as an example. You're probably going to go spend time on the show floor in the little tiny booths that are around the edge, because those are companies that right now, nobody buys their product. Most people haven't heard of what their technology is, and you're kind of going, why is there a hundred million dollars invested and sprinkled around these little companies? Right? So you're doing stuff like that. You're out talking to people, kind of asking questions about, well, why is anybody buying your product? Brian: What problem is your thing solving? It seems like it's the exact replica of the way something else exists. What's new? So you're asking a lot of questions. In my case, I get a chance to talk to venture capitalists, I get a chance to talk to startup founders, I get a chance to talk... Sometimes you'll talk to a large organization, let's say you're talking to a bank, and they have an organization within them that's called Center of Excellence, or Office of the CTO. And you go, well, what are you guys working on? Where are you kind of poking around and seeing what's going on? You explore what's happening in university research. So it's a weird thing because you're out there kind of looking at this new stuff and you're trying to find some way to bring it back to reality because you're like, I know that we're not sure where that's going in a couple years. Or maybe it's as simple as you're watching meetings and you're reading, meeting notes or you're attending meetings for the JavaScript conferences, right? Brian: The steering committees and you're going like, okay, this feels like it's got momentum, but is there enough money behind it? Does it feel like there's enough developers who are downloading it off GitHub or where are the stars? And so you're kind of pulling all this disparate information together. You're trying to find if it looks like a pattern that you've seen before, because a lot of times in tech, the patterns will repeat themselves. You're trying to talk to people that live with this stuff and it's like, does this solve a problem? Does this really solve a problem for you? Is it buzz? And you're not really even sure why it's doing that. And somewhere in there you're trying to figure out like, okay, is there enough sort of concreteness, or at least it's going on the right path that you're like, okay, that feels like a pretty good, next couple steps that we should make. Brian: And then hopefully you've got some mechanisms if, for example, you put it into your product. So let's say for us, it's hey, we want to put GraphQL into our product. Do we have mechanisms to get feedback from customers? Do we have mechanisms to try out some of the stuff that maybe is alpha in that, and get feedback? And so then you're looking for once it becomes sort of like maybe it's in the product or it's in the product, then you're looking for your sort of classic fast iteration cycles, AB testing kind of stuff. Brendan: Yeah. So it sounds like as you're answering that, I'm thinking there's a lot on the business side and a lot on the technical side. Brian: Yeah. Brendan: What is your background that sort of lead you to this role and how do you balance that sort of technical and business experience? Brian: Yeah. So going back aways, I guess, so out of school, I was a finance and economics major. So I understood some of the business ways of things. At least before you have a job. Some of my early jobs were in sales and marketing before I kind of got into the technology. For some reason, I was then kind of drawn to technology. So, I wanted to learn how to be hands on. I wanted to learn what worked, so I did everything from tech support to what would be called systems engineering and design. I was lucky that I worked for a couple of companies who were in a lot of different markets. So at different periods of time, they would go, oh, you want to change jobs? Brian: That's fine, as long as you stay. And so I would bounce around from hands on technical. I did product management, I did product marketing. We would do acquisitions of companies, so I got to work with a venture capital groups. And for whatever reason, I was able to at least be knowledgeable enough to kind of switch, like you said, between technical and business. You sort of realize you don't have to be as deep in both of them all the time, but as long as you can kind of contact switch and you can learn how to learn. But yeah, I don't know. I think because I didn't come up and sort of classically trained engineering, I always sort of look at things first from the perspective of, where's the money come from? Where's the money going? What do people do? How do people actually use it to solve problems? And then I sort of work back into the technology, and sometimes that mindset tends to help for this kind of job. Brendan: Yeah. Do you feel like that's a pretty common story for people in product strategy roles? When you talk to other people doing a similar job, do more people come from the tech side, the business side? What is your sort of impression of product strategists? Brian: If you come from the tech side, I think it's a little bit easier. I think what I find a lot of times is you have these really strong technologists. At some point they've been hands on with the technology, they've built something. Oftentimes maybe they were a sort of startup founder or at some point they said, look, I understand this stuff really well. I'm out in front being asked to communicate about it. So that's often one of those things that happens is like, when you're working on new technologies, nobody understands what it is, and so you have to find somebody who can explain it to people, right? That's oftentimes one of the first kind of things that gets you out of purely doing technology, is can you explain it to people that aren't super techies? Because then at some point it's like, okay, we're going to associate money with it or go to market or whatever. Brian: And then at some point, once you're sort of doing that, then I find people either gravitate towards the business side of things. Right? They realize they like communicating about it, they like sort of dealing with the business side of it, whether it's how things are funded or starting companies. Or sometimes they'll go, look just all this talking stuff isn't right for my personality. I'm too introverted or it just doesn't satisfy me and they'll go back to engineering and they're super happy with it. In fact, they oftentimes double down because they're like, I don't need anymore of that. But yeah, that's more the typical path I'll see is people who started in engineering, weren't afraid to talk about it or were sort of forced to talk about it, and then at some point they realized like, okay, if I'm that close to the people using it, I should then figure out if there's a market for this stuff. Brendan: Yeah. I guess the obvious question to you then is sort of what do you like about it? What keeps you coming back for more every day when you wake up and, I was going to say go to work, but all of us are remote now. Brian: Yeah. I mean, for me, so I grew up playing sports, which is a little bit sometimes odd in the tech industry. You get a lot of, oh, it's sports ball or whatever. So I grew up playing sports. I enjoyed it for the competitiveness of it. And part of what drew me to the tech industry wasn't so much the technology. The technology to me is always interesting because it's always changing, but the competitive nature of it is really interesting. Sometimes the competitiveness of the companies building the technology, but even more so, how do companies use technology to be competitive, right? How does Domino's Pizza beat their competitors, even though people might say, well, their pizza's not the best, right? But their technology's really simple to use. Brendan: They've got the tracker with all the steps. Brian: They've got the tracker, they've got the steps, you know where it is. Or how are the automotive companies kind of switching from being all about horsepower and styling of the outer body to now it's basically a laptop on wheels, and how do you compete with Tesla. So all those things are really interesting to me, and I think just the fact that there's somehow a need to translate between what do I do with this technology and how does this technology work is always sort of an interesting problem to solve. Brendan: So in addition to doing product strategy, you are a fellow podcaster. You are one of the hosts of The Cloudcast. The Cloudcast is maybe not one of the OG engineering podcasts, but you guys have been around for quite a while. Brian: We're definitely old. Yeah, we've been doing it for 12 years, I think maybe now. Maybe a little longer. I don't know that we would completely fit your audience. We probably focus more on infrastructure and backend technologies, but yeah, we've been doing it for at least as long as people have been talking about cloud computing. So it's been a cool way to learn. Brendan: Yeah. And I guess I can see a connection between sort of your job day to day and needing to sort of keep an eye on the industry and the technologies and be seeing like what's new, what's interesting. What's driving buzz in the cloud world, but I'm curious, how do you come up with 12 year of podcasts? How do you keep that going week over week? Brian: Yeah. It's so we got started with it. I'm in Raleigh, North Carolina. So it got started because we didn't live in the valley, and we didn't live in Seattle. And we were just curious. We were basically like, we hear about a lot of interesting stuff on Twitter or wherever you get your news from, and we were like, I feel like I'm an outsider to the world. And so for a while it was purely kind of curiosity meet survival. We knew if we wanted to stay in tech, we had to get more into what was going on. And we needed to find a way to do that because every time we'd go to San Francisco, we'd go to Seattle, I mean, you have this luxury of every single night, there's five meetups somewhere. Brian: And you could go learn about JavaScript or you could go learn about a new program language or some backend scaling thing. And you were like, how do I replicate that? And so, yeah, I mean, some of it's just if you don't restrict yourself to one specific thing, what we found is the enjoyment is two things. One, it's getting to meet really smart people. Right? So our thing with the podcast is just, we're going to go find the smartest people we can find for any given topic, and we're going to give them a platform to hopefully teach us and maybe not teach us so much, but teach the audience. So that's always cool. You get to meet really smart people. Brian: And for us, I think just the process of spending 20 minutes, 30 minutes an hour, doing the background research to be like, what's interesting about this space? Why does anybody care? Why are these companies getting funded? Why are there a million developers using this tool? It's just a curiosity. And I guess we've been lucky that we've sort of haven't gotten UNC curious, but that's kind of our formula. There are a lot of times when I'm like, I have no idea what this person does and I'm going to try and ask some good questions and try and ask some follow ups, but that's part of the fun. It's always just been a learning experience for us. Brendan: And do you feel like that's sort of outsider perspective is part of what's made the podcast successful? Despite what Hacker News would, would have you believe the majority of developers in the world do not live in SF and Seattle? Brian: Yeah, I think so. I think we don't get wrapped up in some of the BS, some of the hype and some of the BS of things. And we're inside enough to where we know how to read press announcements the right way, and we know how to read when there's a lot of hype about something and then you kind of dig into it and you're like, it doesn't seem to be any companies using this stuff. And I think it's helped us, and I think to a certain extent, even the people in Silicon Valley, they reach out to us, which was really weird at first that anybody from Silicon Valley would talk to these two kind of rednecks out in North Carolina. But I think it helps us a little bit. It keeps us grounded. It keeps us not getting enamored with the latest whatever. But maybe it helps us a little bit. Brendan: Is there a dream guest who you haven't had on the podcast that you'd like to? Brian: I mean, we've never aspired to be like, I want to have Bill Gates or Steve Jobs, or Elon Musk, because we're like, they're never coming. I don't know. We've been lucky. When we ask for people for the most part, we can get them on the show. I mean, here's the trick of it I think. Everybody has an ego, and if you just simply say, look, we think you're really smart. We'd love to talk to you and we're going to put it on the internet and so lots of people are going to hear about it. Just that little bit of sort of ego stroking has played out pretty well for us. So, I'm sure there's some more main people that would help us grow the show, and there's plenty of people that cover the super big names. We like to deal with the people that build it and live with it every day. Brendan: All right. Well, Kate and I are taking notes here at PodRocket as we try and scale our show. Brian, what do you want to point our audience at? Where should we find you on the internet? What should they take a look at? Brian: Yeah. So if you're interested in any of the Solo stuff, Solo.io points you to how you can try out the technology. You can go to hands on workshops. All the ways you could learn about it in terms of our podcast, it's thecloudcast.net. And if you ever want to talk about technology, I'm easy to find on Twitter. It's @BGracely. Always happy to chat with people about technology or careers in tech, any of those sort of things. Brendan: All right. Well, we'll make sure we include links to all of those things. Thank you for coming on PodRocket. We'll see you around. Brian: Thanks for having me. Speaker 3: Thanks for listening to Pod rocket. You can find us at PodRocket pod on Twitter, and don't forget to subscribe, rate and review on Apple Podcast. Thanks.