 Good morning and welcome back to Detroit, Michigan. My name is Savannah Peterson, and I'm here on set of theCUBE. My co-host, John Furrier. How are you doing this morning, John? Doing great, feeling fresh. Day two of three days of coverage. Feeling fresh. That is for being in the heat of the conference. I love that attitude. It's going to be a great day today. We'll see you at the end of the day. Yeah, we'll hold them to it. All right, everyone hold them accountable. Very excited to start the day off with an internet legend as well as a CUBE OG. We are joined this morning by Matt Klein. Matt, welcome to the show. Thanks for having me. Good to see you. So what's the vibe? Day two, everyone's buzzing. What's got you excited at the show? You've been here before, but it's been three years you mentioned. I was saying it's been three years since I've been to a conference. So it's been interesting for me to see what is the same and what is different pre and post COVID, but just really great to see everyone here again and nice to not be sitting in my home by myself. You know, Savannah said you're an OG and we were referring before we came on camera that your first came on theCUBE in 2017, second CUBECon event, but you were I think on the first wave of what I call the contributor moment and where CNCF really got the traction. You were at Lyft, Envoy was contributed and that was really hyped up. And I remember that vividly, it was day zero they called it back then. And you got so much traction, people were solely into it. Now we got a lot of that going on now. A lot of day zero events called co-located events. You got WebAssembly, a lot of other hype out there. What do you see out there that you like? How would you look at some of these other communities that are developing? What's the landscape look like to you as you look out? Cause Envoy set the table, what is now a standard practice? Yeah, what's been so interesting for me just to come here to the conference is, you know, we open source Envoy in 2016. We donated in 2017. And as you mentioned at that time, Envoy was, you know, everyone wanted to talk about Envoy. And, you know, much to my amazement, Envoy is now pervasive. I mean, it's used everywhere around the world. It's like never in my wildest dreams would I have imagined that it would be so widely used. And it's almost gotten to the point where it's become boring, you know? It's just assumed that Envoy is everywhere. And now we're hearing a lot about EBPF and WebAssembly and GitOps and, you know, AI and a bunch of other things. So it's actually great. It's made me very happy that it's become so pervasive, but it's also fun as you mentioned to look around at all other stuff. Well, I mean, congratulations. It's just a huge accomplishment. I think it's going to be a historical moment for the industry too. But I like how it progressed. I mean, I don't mind hype cycles as long as there's some vetting. Sure, of course. You know, use cases that are clearly defined. But you got to get that momentum in the community but then you start got to get down to business. So, so to speak, and get it deployed, get traction. What should projects look like? And give us the update on Envoy, because you guys have a great use case of how you got traction. Take us through some of the early days of what made Envoy successful in your opinion. Great question. Yeah, you know, I think Envoy is fairly unique around this conference in the sense that Envoy was developed by Lyft, which is an end user company. And many of the projects in this ecosystem, you know, no judgment for better or worse. They are vendor backed. And I think that's a different delivery mechanism when it's coming from an end user where you're solving a particular business case. So Envoy was really developed for Lyft in a very early scaling days and just trying to help Lyft solve its business problems. So I think when Envoy was developed, we were scaling, we were falling over and actually many other companies were having similar problems. So I think Envoy became very widely deployed because many companies were having similar issues. So Envoy just became pervasive among Lyft peer companies. And then we saw a lot of vendor uptake in the service mesh space and the API gateway space among large internet providers. So I think it's just, it's an interesting case because I think when you're solving real problems on the ground, in some ways it's easier to actually get adoption than if you're trying to develop it from a commercial backing. And that's the class. I mean, it's almost like open source product market fit in its own way because you have a problem. Absolutely, it's neat. Other people have the same problem. It's neat finding too. I mean, it's design thinking from a different perspective. When I talk to people about open source, I like to tell people that I do not think it's any different than starting a company. I actually think it's all the same problems. Finding product market fit, hiring, like finding contributors and maintainers, like doing PR, marketing and yeah, getting a team together. Get traction. Getting funding. I mean, you have to have money to do all these things. So I think a lot of people think of open source as I don't know, you know, this fantastic collaborative effort and it is that but there's a lot more to it. And it's a much more akin to starting a company. Let's just look at that for a second. I think that's a good point. I was having a conversation in the hallway two nights ago on this exact point. If the power dynamics or the startup in the open source as you point out is just different. It's sort of community based. So there are things just got to be mindful of. It's not top down. Not like, you know, go take that hill. It's really consensus based. But it is a startup. All those elements are in play. You need leadership. You got to have debates, alignment. You got to commit to a vision. You got to make adjustments. Build the trajectory. So based on that, I mean, do you see more end user traction? Because we were talking also about Intuit. They donated sort of their code, R goes out there, R goes CD, CD R goes to service. Where's the end user contribution these days? Do you feel like it's good, still healthy? I mean, I'm biased. I would like to see more. I think backstage out of Spotify is absolutely fantastic. That's an area just in terms of developer portals and developer efficiency that I think has been very underserved. So seeing backstage come out of Spotify where they've used it for years. And I think we've already seen they had a huge day one event and I think we're going to see a lot more out of that coming forward. And I'm going to end user, pretend I'm going to end user, pretend I have some code I want to. Oh man, I'm scared. If I don't, I'm going to lose my competitive edge. What's the, how do you talk to the Android's out there that might be thinking about putting their project out there for whether it's the benefit of the community, developing talent, developing the product? Sure, yeah. I would say that I would ask everyone to think through all of the pros and cons of doing that because it's not for free. I mean, doing open source is costly. It takes developer time, you know, it takes management time, it takes budgeting dollars, but the benefits if successful can be huge, right? I mean, it can be just in terms of, you know, getting people into your company, getting users, getting more features, all of that. So I would always encourage everyone to take a very pragmatic and realistic view of what is required to make that happen. What was that decision like at Lyft? I'm going to be honest, it was very naive. I think we really, no, just didn't know. I think a lot of us, myself included, had very minimal open source experience and had we known or had I known what would have happened, I still would have done it, but I'm going to be honest, the last seven years have aged me. What I feel like is like 70 or 100. It's been a big road. But like you said, you look out in the landscape, you got to take pride and look at what's happened. I mean, it's like you said, it's matured. Fantastic. I would not trade it for anything, but it has been a journey. What was the biggest surprise? What was the most eye-opening thing about the journey for you? I think actually just the recognition of all of the non-technical things that go into making these things a success. I think at a conference like this, people think a lot about technology. It is a technology conference, but open source is business. It really is. I mean, it takes money to keep it going. It takes people to keep it going. You got to sell people in the concepts. It takes leadership to keep it going. It takes marketing. So for me, what was most eye-opening is over the last five to seven years, I feel like I actually have not developed very many, if any technical skills, but my general leadership skills, that would be applicable, again, to running a business have applied so well to growing on board. You put it out there, you're driving the ship. It's good to do that. They need that. It really needs it. And the results speak for itself. And congratulations. What's the update on the project? Give us an update, because you're seeing a lot of infrastructure. People are having the same problem, but it's also the environments are a little bit different. Some people have different architectures, different more cloud, less cloud, edges are exploding. Where does Envoy fit into the landscape they've seen? And what's the updates? You've got some new things going on. Give the updates on what's going on with the project, and then how it sits in the ecosystem vis-a-vis what people may use it for. Yeah, so from a core project perspective, honestly, things have matured, things have stabilized a bit. So a lot of what we focus on now are less big bang features, but more table stakes. We spend a lot of time on security, spend a lot of time on software supply chain, a topic that you're probably hearing a lot about at this conference. We have a lot of software supply chain issues. We have shipped Quicken HTTP 3 over the last year. That's generally available. That's a new internet protocol. Still work happening on WebAssembly. We're doing a lot of work on our build and release pipeline. Again, you would think that's boring, but a lot of people want packages for their Fedora or their Ubuntu or their Docker images, and that takes a lot of effort. So a lot of what we're doing now is more table stakes, just realizing that the project is used around the world very widely. The thing that I'm most interested in is we announced in the last six months a project called Envoy Gateway, which is layered on top of Envoy, and the goal of Envoy Gateway is to make it easier for people to run Envoy within Kubernetes, so essentially as an ingress controller. And Envoy is a project, historically, it is a very sophisticated piece of software, very complicated piece of software. It's not for everyone, and we want to provide Envoy Gateway as a way of onboarding more users into the Envoy ecosystem and making Envoy the default API gateway or edge proxy within Kubernetes. But in terms of use cases, we see Envoy pervasively with service mesh, API gateway, other types of load balancing cases. I mean, honestly, it's all over the place. I'm curious because you mentioned it's expanded beyond your wildest dreams, and how could you have even imagined what Envoy was going to do. Is there a use case or an application that really surprised you? You know, I've been asked that before, and it's hard for me to answer that. It's more that, I mean, for example, Envoy is used by basically every major internet company in China. I mean, like, everyone in China uses Envoy, like TikTok, like Alibaba, I mean, like everyone. But all the large scale. And it's used in, it's not just even the U.S. So I think the thing that has surprised me more than individual use cases is just the worldwide adoption, that something could be everywhere. And that I think, when I open my phone and I'm opening all of these apps on my phone, 80 or 90% of them are going through Envoy in some form. You know, it's just that pervasive. It does blow your mind a little bit sometimes. That's why you say plumber on your Twitter handle as your title. Because you're working on all these things that are like really important, substrate issues for scale, stability, growth. And you know, I guess the only thing that I would add is my goal for Envoy has always been that it is that boring, transparent piece of technology kind of similar to Linux. Linux is everywhere. But no one really knows that they're using Linux. It's just there. It's like Intel inside. We're not paying attention to it. There's a core group working on it. They have pride. They understand the mission, the importance of it. And their job is to make it invisible. Exactly. And that's really ease of use. What's some of the ease of use ways and simplicity that you're working on, if you can talk about that? Because to be boring, you got to be zippler and easier. Not more complex. A goal to be boring is unique. Complex is not boring. Complex is stressful. I think we approach it in a couple of different ways. One of them is that because we view Envoy as a base technology in the ecosystem, we're starting to see not only vendors, but other open source projects that are being built on top of Envoy. So things like API gateway, sorry, Envoy gateway or projects like Istio or all the other projects that are out there. They use Envoy as a component, but in some sense, Envoy is a transparent piece of that system. So I'm a big believer in the ecosystem that we need to continue to make cloud native easier for end users. I still think it's too complicated. And so I think we're pushing up the stack a bit. Yeah, and that brings up a good point. When you start seeing people building on top of things, that's enabling. So as you look at the enablement of Envoy, what are some of the things you see out in the horizon? If you get the 20 mile stair out, as you check these boring boxes, making them more plumbing, stable, you'll have a disruptive enabling platform. What do you see out there? I am, you know, again, I'm not a big buzzword person, but so some people call it serverless, functions as a service, whatever. I'm a big believer in platforms, in the sense that I really believe in the next 10 to 15 years, developers, they want to provide code. You know, they want to call APIs. They want to use PubSub systems. They want to use caches and databases. And honestly, they don't care about container scheduling or networking or load balancing or any of these things. It handles in the OS. They just want it to be part of the operating system. So I really believe that whether it's an open source or in cloud provider package solutions, that we're going to be just moving increasingly towards systems like AWS, Lambda and Fargate and Google Cloud Run and Azure Functions and all those kinds of things. And I think that when you do that, much of the functionality that has historically powered this conference like Kubernetes and Envoy, these become critical but transparent components that people don't, they're not really aware of at that point. And I think that's a great call out because one of the things we're seeing is the market forces of this evolution. What you just said is what has to happen for digital transformation to get to its conclusion, which means that everything doesn't have to serve the business. It is the business, IT in the old days. Engineers, they serve the business. Like what does that even mean? Now developers are the business. So they need that coding environment. So for your statement to happen, that simplicity, invisibility, calling is an invisible OS has to happen. So it brings up the question. In open source, the trend is things always work itself out in the wash, as we say. So when you start having these debates and the alignment has to come at some point, you can't get to those that stay without some sort of de facto or consensus. And even standards, I'm not a big be able to run hardcore standards, but we can all agree and have consensus that will align behind, say, Kubernetes. Is Kubernetes a standard? It's not like an IEEE, but what's your reaction to this? Because this alignment has to come after debate, so all the process contending for, I am the this of that. Yeah, look, I mean, I totally see the value in IEEE standards, and there's a place for that. At the same time, for me personally, as a technologist, as an engineer, I prefer to let the market, as it were, sort out what are the de facto standards. So for example, at least with Envoy, Envoy has an API that we call XDS. XDS is now used beyond Envoy. It's used by GRBC. It's used by proprietary systems. And I'm a big believer that actually Envoy, in its form, is probably going to go away before XDS goes away. So in some ways, XDS has become a de facto standard. It's not an IEEE standard. We have been asked about whether we should do that. But I just, I think- It becomes a component in the- It becomes a component, and then I think people gravitate towards these things that become de facto standards. And I guess I would rather let the people on the show floor decide what are the standards, than have 10 people sitting in the room, and like, trying to figure it out. It's totally, I mean, it says the community defined standards versus organizational and institutional defined standards. And they both have places. And they're social proof in both of them, frankly. And we were saying on theCUBE that we believe that the developers will decide the standards. Because that's what you're basically saying. They're deciding what they do with their code. And over time, as people realize the trade, hey, if everyone's coding this, and makes my life easier to get to that state of Nirvana, and enlightenment, as we would say. Yeah. Starting strong this morning, John. I love this. I'm curious, you mentioned backstage, you talked about the enterprise Spotify wonderful example. Do you think that this is a trend we're going to see with more end users creating open source projects? Like, You know, I hope so. The flip side of that, and as we all know, we're entering an uncertain economic time. And it can be hard to justify the effort that it takes to do it well. And what I typically counsel people when they are about to open source something is don't do it unless you're ready to commit the resources. Because open sourcing something and not supporting it, I actually can be, I think it'd be worse than open sourcing. It's in itself the people you're asking to commit to something. Exactly. You need to have time, you need the money, investment. You got to go all in and push it. So I very much want to see it. And I want to encourage that here, but it's hard for me to look into the crystal ball and know whether it's going to happen more or less. At what point are there too many projects? You know, I mean, but I mean this in a negative way. I mean it more in the way of, you know, you mentioned supply chain. We were riffing on theCUBE about, at some point there's going to be so much code, open source is continuing to thunder away with the value that you're just gluing things, right? I don't need the code, there's code there. Okay, what's in the code? Okay, maybe automation can help out on supply chain. But ultimately, composability is the new... Right, it is, yeah. And I think that's always going to be the case. It is a good thing. And I think that's just the way of things, for sure. So no code will be the thing. I think we're seeing a lot of no code situations that are working great for people. And, but this is actually really no different than my server was arguing from before. Just as a slight digression, I'm building something new right now. And you know, we're using cloud native technologies and all this stuff. And it's still... What are you building? Even as a, I'm going to keep them. I'm going to keep that secret. I don't know, I'm hearing you. We'll find out, we're going to find out. Now that we know it. All right, you open that door. We're going down there and we'll see you in a couple of weeks, front page is still coningal. But I was just going to say that, and I consider myself, you know... You're building something. I see myself as an expert in the cloud native space. It's still difficult to pull together these technologies. And I think that we will continue to make it easier for people. What's the biggest difficulties? Can you give us some examples? Well, just, I mean, we still live in a big mess of YAML, right? There's a lot of YAML out there. And I think just wrangling all of that in these systems, there's still a lot of cobbling together where I think that there can be unified platforms that make it easier for us to focus on our application logic. I got to ask you a question because I've talked to college kids all the time, my son's a junior in CS, and he's coding away. What would you, how does a student or someone who's learning figure out who they are? Because there's now, you know, you're either into the infrastructure under the hood, or you're, because that's coding there. Ops are now coding away. You're interested in people working on, say the boring stuff, so everyone else can have ease of use. And then what is, I want to just code. There's two types of personas. How does someone know who they are? My, when I give people career advice, my biggest piece of advice to them is in the first five to seven to 10 years of their career. I encourage people to do different things, like every, say one to two to three years. And that doesn't mean like quitting companies and changing companies. It could mean, you know, within a company that they join doing different teams, you know, working on front end versus back end. Because honestly, I think people don't know. I think it's actually very, our industry is so broad that I think it's almost impossible to know. You got to get your hands dirty, jump in the water. To know what you like. And for me, in my career, you know, I've dabbled in different areas, but I've always come back to infrastructure. You know, that's what I enjoy the most. You got to taste everything, see what you like. Exactly. All right, last question for you, Matt. It's been three years since you were here. What do you hope that we're able to say next year that we can't say this year? Beyond the secrets of your project, which hopefully we will definitely be discussing then. You know, I don't have anything in particular. I would just say that I would like to see more movement towards projects that are synthesizing and making it easier to use a lot of the existing projects that we have today. So for example, I'm very bullish on backstage. Like I've always said that we need better developer UIs that are not CLIs. Like I know it's a general perception among many people that you're not a real systems engineer unless you type on the command line. I think better user interfaces are better for humans. So just for a project like backstage to be more integrated with the rest of the projects whether that be Envoy or Kubernetes or Argo or Flagr. I just, I think there's tremendous potential for further integration of some of these projects. If there's composability, that makes total sense. You're operating and composing. And there's no reason that user experience can't be better and then more people can create and build. So I think it's awesome. Thank you so much. Thank you. Yeah, this has been fantastic. Be sure and check out Matt on Twitter to find out what that next secret project is. John, thank you for joining me this morning. My name is Savannah Peterson and we'll be here all day live from theCUBE. We hope you'll be joining us throughout the evening until a happy hour today. Thanks for coming. Thanks for coming. Thanks for watching.