>> Announcer: theCUBE presents Kubecon and Cloudnativecon Europe, 2022. Brought to you by Red Hat, the cloud native computing foundation and its ecosystem partners. >> Welcome to Valencia, Spain in Kubecon, Cloudnativecon Europe 2022. I'm Keith Townsend and alongside Enrico senior IT analyst for (indistinct). Welcome back to the show Enrico. >> Thank you again for having me here. >> First impressions of Kubecon. >> Well, great show. As I mentioned before, I think that we are really in this very positive mood of talking with each other and people wanting to see the projects, people that build the projects and it's amazing. A lot of interesting conversation in the show floor and in the various sessions, very positive mood. >> So this is going to be a fun one, we have some amazing builders on the show this week and none other than William Morgan, CEO of Buoyant. What's your role in the Linkerd project? >> So I was one of the original creators of Linkerd, but at this point I'm just the beautiful face of the project. (all laughing) >> Speaking of beautiful face of the project Linkerd just graduated from as a CNCF project. >> Yeah, that's right so last year we became the first service mesh to graduate in the CNCF, very proud of that and that's thanks largely to the incredible community around Linkerd that is just excited about the project and wants to talk about it and wants to be involved. >> So let's talk about the significance of that. Linkerd not the only service mesh project out there. Talk to me about the level effort to get it to the point that it's graduated. You don't see too many projects graduating CNCF in general so let's talk about kind of the work needed to get Linkerd to this point. >> Yeah so the bar is high and it's mostly a measure, not necessarily of like the project being technically good or bad or anything but it's really a measure of maturity of the community around it so is it being adopted by organizations that are really relying on it in a critical way? Is it being adopted across industries? Is it having kind of a significant impact on the Cloudnative community? And so for us there was the work involved in that was really not any different from the work involved in kind of maintaining Linkerd and growing the community in the first place, which is you try and make it really useful. You try and make it really easy to get started with, you try and be supportive and to have a friendly and welcoming community. And if you do those things and you kind of naturally get yourself to the point where it's a really strong community full of people who are excited about it. >> So from the point of view of users adopting this technology, so we are talking about everybody or do you see really large organization, large Kubernetes clusters infrastructure adopting it? >> Yeah, so the answer to that is changed a little bit over time but at this point we see Linkerd adoption across industries, across verticals, and we see it from very small companies to very large ones so one of the talks I'm really excited about at this conference is from the folks at Xbox cloud gaming who are going to talk about how they deployed Linkerd across 22,000 pods around the world to serve basically on demand video games. Never a use case I would ever have imagined for Linkerd and at the previous Kubecon virtually Kubecon EU, we had a whole keynote about how Linkerd was used to combat COVID 19. So all sorts of uses and it really doesn't, whether it's a small cluster or large cluster it's equally applicable. >> Wow so as we talk about Linkerd service mesh we obviously are going to talk about security, application control, etcetera. But in this climate software supply chain is critical and you think about open source software supply chain, talk to us about the recent security audit of Linkerd. >> Yeah so one of the things that we do as part of a CNCF project and also as part of, I think our relationship with our community is we have regular security audits where we engage security professionals who are very thorough and dig into all the details. Of course the source code is all out there, so anyone can read through the code but they'll build threat model analysis and things like that. And then we take their report and we publish it. We say, "Hey look, here's the situation." So we have earlier reports online and this newest one was done by a company called Trail of Bits and they built a whole threat model and looked through all the different ways that Linkerd could go wrong and they always find issues of course, it would be very scary, I think, to get a report that was like, no, we didn't find- >> Yeah everything's clean. >> Yeah everything's fine, should be okay, I don't know. But they did not find anything critical. They found some issues that we rapidly addressed and then everything gets written up in the report and then we publish it, as part of an open source artifact. >> How do you, let's say, do they give you and adds up something? So if something happens so that you can act on the code before somebody else discovers the- >> Yeah, they'll give you a preview of what they found and then often it's not like you're going before the judge and the judge makes a judgment and then like off to jail, it's a dialogue because they don't necessarily understand the project. Well, they definitely don't understand it as well as you do. So you are helping them understand which parts are interesting to look at from the security perspective, which parts are not that interesting. They do their own investigation of course but it's a dialogue the entire time. So you do have an opportunity to say, "Oh you told me that was a a minor issue. "I actually think that's larger or vice versa." You think that's a big problem actually, we thought about that and it's not a big problem because of whatever. So it's a collaborative process. >> So Linkerd been around, like when I first learned about service mesh Linkerd was the project that I learned about. It's been there for a long time, just mentioned 22,000 clusters. That's just mind boggling- >> Pods, 22,000 pods. >> That's pods. >> Clusters would be great. >> Yeah, clusters would be great too but it filled 22,000 pods. >> It's a big deployment. >> That's a big deployment of Linkerd, but all the way down to the smallest set of pods as well. What are some of the recent project updates some of the learnings you bought back from the community and updated the project as a result? >> Yeah so a big one for us, on the topic of security, Linkerd, a big driver of Linkerd adoption is security and less on the supply chain side and more on the traffic, like live traffic security. So things like mutual TLS, so you can encrypt the communication between pods and make sure it's authenticated. One of the recent feature additions is authorization policy so you can lock down connections between services and you can say Service A is only allowed to talk to Service B and I want to do that not based on network identity, not based on like IP addresses, 'cause those are spoofable and we've kind of like as an industry moved, we've gotten a little more advanced from that but actually based on the workload identity as captured by the mutual TLS certificate exchange. So we give you the ability now to restrict the types of communication that are allowed to happen on your cluster. >> So, okay this is what happened. What about the future? Can you give us into suggestion on what is going to happen in the medium and long term? >> I think we're done you know we graduated, so we're just going to stop. (all laughing) What else is there to do? There's no grad school. No, so for us, there's a clear roadmap ahead continuing down the security realm, for sure. We've given you kind of the very first building block which at the service level, but coming up in the 2.12 release we'll have route based policy as well, as you can say this service is only allowed to call these three routes on this end point. And we'll be working later to do things like mesh expansions so we can run the data plane outside of Kubernetes, so the control plane will stay in Kubernetes but the data plane will, you'll be able to run that on Vms and things like that. And then of course in the, we're also starting to look at things like, I like to make a fun of (indistinct) a lot but we are actually starting to look at (indistinct) in the ways that that might actually be useful for Linkerd users. >> So we talk a lot about the flexibility of a project like Linkerd you can do amazing things with it from a security perspective but we're talking still to a DevOps type cloud of developers who are spread thin across their skillset. How do you help balance the need for the flexibility which usually comes with more nerd knobs and servicing a crowd that wants even higher levels of abstraction and simplicity. >> Yeah, that's a great question and this is what makes Linkerd so unique in the service mesh spaces. We have a laser focus on simplicity and especially on operational simplicity so our audience, we can make it easy to install Linkerd but what we really care about is when you're running it and you're on call for it and it's sitting in this critical, vulnerable part of your infrastructure, do you feel confident in that? Do you feel like you understand it? Do you feel like you can observe it? Do you feel like you can predict what it's going to do? And so every aspect of Linkerd is designed to be as operationally simple as possible. So when we deliver features, that's always our primary consideration, is we have to reject the urge, we have an urge as engineers to like want to build everything, it's an ultimate platform to solve all problems and we have to really be disciplined and say we're not going to do that, we're going to look at solving the minimum possible problem with a minimum set are features because we need to keep things simple and then we need to look at the human aspect to that. And I think that's been a part of Linkerd's success. And then on the Buoyant side, of course, I don't just work on Linkerd, I also work on Buoyant which helps organizations adopt Linkerd and increasingly large organizations that are not service mesh experts don't want to be service mesh experts, they want to spend their time and energy developing their business, right? And building the business logic that powers their company. So for them we have actually recently introduced, fully managed Linkerd where we can take on, even though Linkerd has to run on your cluster, the sidecar proxies has to be alongside your application. We can actually take on the operational burden of upgrades and trust income rotation, and installation. And you could effectively treat it as a utility, and have a hosted-like experience even though the actual bits, at least most of them not all of them, most of 'em have to live on your cluster. >> I love the focus of most CNCF projects, it's peanut butter or jelly, not peanut butter trying to be become jelly. What's the peanut butter to Linkerd's jelly? Like where does Linkerd stop? And some of the things that customers should really consider when looking at service mesh? >> Yeah, now that's a great way of looking at it and I actually think that philosophy comes from Kubernetes. I think Kubernetes itself, one of the reasons it was so successful is because it had some clearly delineated boundaries. It said, "This is what we're going to do. "And this is what we're not going to do. "So we're going to do layer three, four networking, "but we're going to stop there, "we're not going to do anything with layer seven." And that allowed the service mesh. So I guess if I were to go down the bread of the sandwich is Kubernetes, and then Linkerd is the peanut butter, I guess. And then the jelly, so I think the jelly is every other aspect of of building a platform. So if you are the audience for Linkerd most of the time is a platform owners. They're building a platform an internal platform for their developers to write code and so, as part of that, of course you've got Kubernetes, you've got Linkerd, but you've also got a CICD system. You've also got a code repository that's GitLab or or GitHub or whatever, you've got other kind of tools that are enforcing various other constraints. All of that is the jelly in the, this is analogy it's getting complicated now, and like the platform sandwich that you're serving. >> So talk to us about trans and service mesh from the, as we think of the macro. >> Yeah, so it's been an interesting space because, we were talking a little bit about this before the show but, there was so much buzz and then what we saw was basically it took two years for that buzz to become actual adoption and now a lot of the buzz is off on other exciting things and the people who remain in the Linkerd space are very focused on, "Oh, I actually have a real problem "that I need to solve "and I need to solve it now." So that's been great. So in terms of broader trends, I think one thing we've seen for sure is the service mesh space is kind of notorious for complexity, and a lot of what we've been doing on the Linkerd side has been trying to reverse that idea, because it doesn't actually have to be complex. There's interesting stuff you can do, especially when you get into the way we handle the sidecar model. It's actually really, it's a wonderful model operationally. It's really, it feels weird at first and then you're like, "Oh, actually this makes my operations a lot easier." So a lot of the trends that I see at least for Linkerd is doubling down on the sidecar model trying to make side cars as small and as thin as possible and try and make them kind of transparent to the rest of the application. >> Well, William Morgan, one of the coolest Twitter handles I've seen at WM on Twitter, that's actually a really cool Twitter handle. >> William: Thank you. >> CEO of Buoyant. Thank you for joining theCube again, Cube alum. From Valencia Spain, I'm Keith Towns, along with Enrico's (indistinct) and you're watching theCube, the leader in high tech coverage. (upbeat music)

>>The cube presents, Coon and cloud native con Europe 22, brought to you by the cloud native computing foundation. >>Welcome to vincia Spain in Coon cloud native con Europe, 2022. I'm Keith towns alongside en Rico senior. Etti senior it analyst for giong welcome back to the show en >>Rico. Thank you again for having me here. >>First impressions of QAN. >>Well, great show. As, as I mentioned before, I think that we are really in this very positive mode of talking with each other and people wanting to see, you know, the projects, people that build the projects at it's amazing. I mean, a lot of interesting conversation in the show floor and in the various sessions, very positive move. >>So this is gonna be a fun one. We have some amazing builders on the show this week, and none other than William Morgan, CEO of buoyant. What's your role in the link D project? >>So I was one of the original creators of link D but at this point I'm just the, the beautiful face of the project. >>Speaking of beautiful face of the project, linker D just graduated from as a CNCF project. >>Yeah, that's right. So last year we, we became the first service mesh to graduate in the CNCF. Very proud of that. And that's thanks, you know, largely to the incredible community around Linky that is just excited about the project and, you know, wants to talk about it and wants to be involved. >>So let's talk about the significance of that link D not the only service mesh project out there. Talk to me about the level effort to get it to the point that it's graduated. That's you don't see too many projects graduating CNCF in general. So let's talk about kind of the work needed to get Nier D to this point. >>Yeah. So, you know, the, the, the bar is high and it's mostly a measure, not necessarily of like the, the project being technically good or bad or anything, but it's really a measure of maturity of the community around it. So is it being adopted by organizations that are really relying on it in a critical way? Is it, you know, being adopted across industries, you know, is it having kind of a significant impact on the cloud native community? And so for us, you know, there was the, the work involved in that was really not any different from the work involved in, in kind of maintaining ity and growing the community in the first place, which is you try and make it really useful. You try and make it really easy to get started with you, try and be supportive and to, you know, have a, a friendly and welcoming community. And if you do those things and, you know, you kind of naturally get yourself to the point where it's a, it's a really strong community full of people who are excited about it. >>So from the of view of, you know, users adopting the, this technology, so we are talking about everybody, or do you see really, you know, large organization, large Kubernetes yeah. Clusters infrastructure adopting it. >>Yeah. So that's the answer to that is changed a little bit over time. But at this point we see Linky adoption across industries, across verticals, and we see it from very small companies to very large ones. So, you know, one of the talks I'm really excited about at this conference is from the folks at Xbox cloud gaming, who talked about, who are gonna talk about how they deployed Linky across, you know, 22,000 pods around the world to serve, you know, basically on demand video games, never a use case I would ever have imagined for Linky. And at the previous Kuan, you know, virtually Kuan EU, we had a whole keynote about how Linky was used to combat COVID 19. So all sorts of uses. And it really doesn't, you know, whether, whether it's a small cluster or large cluster it's equally applicable. >>Wow. So as we talk about link D service match, we obviously are gonna talk about security application control, etcetera. But in this climate Software supply chain is critical, right. And as we think about open source software supply chain, talk to us about the recent security audit of link dealer. >>Yeah. So one of the things that we do as part of a CNCF project, and also as part of, I, I think our relationship with our community is we have regular security audits, you know, where we, we engage security professionals who are very thorough and, you know, dig into all the details. Of course the source code is all out there, you know, so anyone can read through the code, but they'll build threat model analyses and things like that. And then we take their, their report and we publish it. We say, Hey, look, here's, you know, here's the situation. So we have earlier reports online, and this newest one was done by a company called trail of bits. And they built a whole threat model and looked through all the different ways that Linky could go wrong. And they always find issues. Of course, you know, it's, it would be very scary, I think, to get a report that was like, no, we didn't find yeah. Earth clean, you know? Yeah. Everything's fine. You know, should be okay. I don't know. Right. But they, you know, they did not find anything critical. They found some issues that we rapidly addressed and then, you know, everything gets written up in the report and, and then we publish it, you know, as part of an open source artifact >>Are, you let's say, you know, do they give you and add something? So if something happens so that you can act on the code before, you know, somebody else discovers the >>Yeah, yeah. They'll give you a preview of what they found. And then often, you know, it's not like you're going before the judge and the judge makes a judgment and then like off the jail, right. It's, it's a dialogue because they don't necessarily understand the project. Well, they definitely don't understand it as well as you do. So you are helping them, you know, understand which parts and, and your, you know, are, are interesting to look at from the security perspective, which parts are not that interesting. They do their own investigation of course, but it's a dialogue the entire time. So you do have an opportunity to say, oh, you told me that was a, a, a minor issue. I actually think that's larger or, or vice versa. You know, you, you think that's a big problem. Actually, we thought about that, and it's not a big problem because of whatever. So it's a collaborative process. >>So link D been around, like, when I first learned about service me link D was the project that I learned about. Yeah. It's been there for a long time, but just mentioned 22,000 clusters. That's just mind boggling pod, 22,000 pods, the pods. Okay. >>Clusters would be >>Great. Yeah. Yeah. Clusters would be great too, but filled 22 thousands pods, big deployment. That's the big deployment of link D but all the way down to the small, smallest set of pods as well. What are some of the recent project updates from of the learnings you bought back from the community and updated the, the project as a result? >>Yeah. So a big one for us, you know, on the topic of security link, a big driver of link adoption is security and, and less on the supply chain side and more on the traffic, like live traffic security. So things like mutual TLS. So you can encrypt the communication between pods and make sure it's authenticated. One of the recent feature additions is authorization policy. So you can lock down connections between services and you can say service a is only allowed to talk to service B. And I wanna do that. Not based on network identity, you know, and not based on like IP addresses, cuz those are spoof. And you know, we've kind of like as an industry moved, moved, we've gotten a little more advanced from that, but actually based on the workload identity, you know, as captured by the mutual TLS certificate exchange. So we give you the ability now to, to, to restrict the types of communication that are allowed to happen on your cluster. >>So, okay. This is what happened. What about the future? Can you give us, you know, into suggestion of what is going to happen in the medium and long term? >>I think we're done, you know, we graduated, so we're just gonna >>Stop there's >>What else is there to do? There's no grad school, you know? No, no. So for us, there's a clear roadmap ahead, continuing down the, the security realm, for sure. We've given you kind of the very first building block, which at the service level, but coming up in, in the two point 12 release, we'll have route based policy as well, as you can say, this service is only allowed to call these three, you know, routes on this end point and we'll be working later to do things like mesh expansion so we can run the data plane outside of Kubernetes. You know, so the control plane will stay in in Kubernetes, but the data plane will, you'll be able to run that on VMs and, and, and things like that. And then of course in the, you know, we're also starting to look at things like I like to make a fun of WAM a lot, but we are actually starting to look at WAM in, in the ways that that might actually be useful for Linky users. >>So we talk a lot about the flexibility of a project, like link D you can do amazing things with it from a security perspective, but we're talking still to a DevOps type cloud of, of, of developers who are spread thin across their skillset. How do you help balance the need for the flexibility, which usually becomes more nerd knobs and servicing a crowd that wants even higher levels of abstraction and simplicity. >>Yeah. Yeah. That's a great question. And this is, this is what makes Linky so unique in the service mesh spaces. We have a laser focus on simplicity and especially on operational simplicity. So our audience, you know, we can make it easy to install Linky, but what we really care about is when you're running it and you're on call for it and it's sitting in this critical, vulnerable part of your infrastructure, do you feel confident in that? Do you feel like you understand it? Do you feel like you can observe it? Do you feel like you can predict what it's gonna do? And so every aspect of Linky is designed to be as operationally simple as possible. So when we deliver features, you know, that's always our, our primary consideration is, you know, we have to reject the urge. You know, we have an urge as, as engineers to like want to build everything, you know, it's an ultimate platform to solve all problems and we have to really be disciplined and say, we're not gonna do that. >>We're gonna look at solving the minimum possible problem with a minimum set of features because we need to keep things simple. And, and then we need to look at the human aspect to that. And I think that's been a part of, of Link's success. And then on the buoyant side, of course, you know, I don't just work on link day. I also work on, on buoyant, which helps organizations adopt Linky and, and increasingly large organizations that are not service mesh experts don't wanna be service mesh experts that, you know, they wanna spend their time and energy developing their business, right. And, and building the business logic that powers their company. So for them, we have actually re recently introduced, fully managed. Linky where we can take on, even though Linky has to run on your cluster, right? The, the, the, the sidecar proxies has to be alongside your application. We can actually take on the operational burden of, of upgrades and trust, anchor rotation, and installation. And you can effectively treat it as a utility, right. And, and, and have a, a hosted, like, experience, even though the, the actual bits, at least most of them, not all of them, most of 'em have to live on your cluster. >>I love the focus of most CNCF projects, you know, it's, it's peanut butter or jelly, not peanut butter. Yeah. Trying to be become jelly. Right. What's the, what's the, what's the peanut butter to link D's jelly. Like where does link D stop and some of the things that customers should really consider yeah. When looking at service mesh. >>Yeah. No, that's a great way of looking at it. And I, I actually think that that philosophy comes from Kubernetes. I think Kubernetes itself, one of the reasons it was so successful is because it had some clearly delineated, it said, this is what we're gonna do. Right. And this is what we're not gonna do. So we're gonna do layer three, four networking. Right. But we're gonna stop there. We're not gonna do anything with layer seven. And that allowed the service mesh. So I guess if I were to go down the, the bread, the bread of the sandwich has Kubernetes, and then Linky is the, is the peanut butter, I guess, and then the jelly, you know, so I think the jelly is every other aspect of, of building a platform. Right. So if you are the, the audience for Linky, most of the time, it's a platform owners, right. They're building a platform, an internal platform for their developers to write code. And so, as part of that, of course, you've got Kubernetes, you've got Linky, but you've also got a C I CD system. You've also got a, you know, a code repository, if it's GitLab or, or GitHub or wherever you've got, you know, other kind of tools that are enforcing various other constraints. All of that is the jelly, you know, in the, this is, analogy's getting complicated now. And like the, the platform sandwich that, you know, that you're serving. >>So talk to us about trans and service mesh from the, from the, as we think of the macro. >>Yeah. Yeah. So, you know, it's been an interesting space because we were talking a little bit about, you know, about this before the show, but the, there was so much buzz, you know, and then what we, what we saw was basically it took two years for that buzz to become actual adoption, you know, and now a lot of the buzz is off on other exciting things. And the people who remain in the Linky space are, are very focused on, oh, I actually have a, a real problem that I need to solve and I need to solve it now. So that's been great. So in terms of broader trends, you know, I think one thing we've seen for sure is the service mesh space is kind of notorious for complexity, you know, and a lot of what we've been doing on the Linky side has been trying to, to reverse that, that, that idea, you know, because it doesn't actually have to be complex. There's interesting stuff you can do, especially when you get into the way we handle the sidecar model. It's actually really, it's a wonderful model operationally. It's really, it feels weird at first. And then you're like, oh, actually this makes my operations a lot easier. So a lot of the trends that I see at least for Linky is doubling down on the sidecar model, trying to make side cards as small and as thin as possible and try and make them, you know, kind of transparent to the rest of the application. So >>Well, William Morgan, one of the coolest Twitter handles I've seen at WM on Twitter, that's actually a really cool Twitter handle. Thank you, CEO of buoyant. Thank you for joining the cube again. Cube alum from Valencia Spain. I'm Keith towns, along with en Rico, and you're watching the cube, the leader in high tech coverage.

(upbeat music) >> Announcer: TheCUBE presents KubeCon and CloudNativeCon Europe, 2022. Brought to you by Red Hat, the Cloud Native Computing Foundation and its ecosystem partners. >> Welcome to Valencia, Spain, a KubeCon, CloudNativeCon Europe, 2022. I'm your host, Keith Townsend alongside Paul Gillon, Senior Editor, Enterprise Architecture for SiliconANGLE. We are, I think at the half point way point this to be fair we've talked to a lot of folks in open source in general. What's the difference between open source communities and these closed source communities that we attend so so much? >> Well open source is just it's that it's open it's anybody can contribute. There are a set of rules that manage how your contributions are reflected in the code base. What has to be shared, what you can keep to yourself but the it's an entirely different vibe. You know, you go to a conventional conference where there's a lot of proprietary being sold and it's all about cash. It's all about money changing hands. It's all about doing the deal. And open source conferences I think are more, they're more transparent and yeah money changes hands, but it seems like the objective of the interaction is not to consummate a deal to the degree that it is at a more conventional computer conference. >> And I think that can create an uneven side effect. And we're going to talk about that a little bit with, honestly a friend of mine Alex Ellis, founder of OpenFaaS. Alex welcome back to the program. >> Thank you, good to see Keith. >> So how long you've been doing OpenFaaS? >> Well, I first had this idea that serverless and function should be run on your own hardware back in 2016. >> Wow and I remember seeing you at DockerCon EU, was that in 2017? >> Yeah, I think that's when we first met and Simon Foskett took us out to dinner and we got chatting. And I just remember you went back to your hotel room after the presentation. You just had your iPhone out and your headphones you were talking about how you tried to OpenWhisk and really struggled with it and OpenFaaS sort of got you where you needed to be to sort of get some value out of the solution. >> And I think that's the magic of these open source communities in open source conferences that you can try stuff, you can struggle with it, come to a conference either get some advice or go in another direction and try something like a OpenFaaS. But we're going to talk about the business perspective. >> Yeah. >> Give us some, like give us some hero numbers from the project. What types of organizations are using OpenFaaS and what are like the download and stars all those, the ways you guys measure project success. >> So there's a few ways that you hear this talked about at KubeCon specifically. And one of the metrics that you hear the most often is GitHub stars. Now a GitHub star means that somebody with their laptop like yourself has heard of a project or seen it on their phone and clicked a button that's it. There's not really an indication of adoption but of interest. And that might be fleeting and a blog post you might publish you might bump that up by 2000. And so OpenFaaS quite quickly got a lot of stars which encouraged me to go on and do more with it. And it's now just crossed 30,000 across the whole organization of about 40 different open source repositories. >> Wow that is a number. >> Now you are in ecosystem where Knative is also taken off. And can you distinguish your approach to serverless or FaaS to Knatives? >> Yes so, Knative isn't an approach to FaaS. That's simply put and if you listen to Aikas Ville from the Knative project, he was working inside Google and wished that Kubernetes would do a little bit more than what it did. And so he started an initiative with some others to start bringing more abstractions like Auto Scaling, revision management so he can have two versions of code and and shift traffic around. And that's really what they're trying to do is add onto Kubernetes and make it do some of the things that a platform might do. Now OpenFaaS started from a different angle and frankly, two years earlier. >> There was no Kubernetes when you started it. >> It kind of led in the space and and built out that ecosystem. So the idea was, I was working with Lambda and AWS Alexa skills. I wanted to run them on my own hardware and I couldn't. And so OpenFaaS from the beginning started from that developer experience of here's my code, run it for me. Knative is a set of extensions that may be a building block but you're still pretty much working with Kubernetes. We get calls come through. And actually recently I can't tell you who they are but there's a very large telecommunications provider in the US that was using OpenFaaS, like yourself heard of Knative and in the hype they switched. And then they switched back again recently to OpenFaaS and they've come to us for quite a large commercial deal. >> So did they find Knative to be more restrictive? >> No, it's the opposite. It's a lot less opinionated. It's more like building blocks and you are dealing with a lot more detail. It's a much bigger system to manage, but don't get me wrong. I mean the guys are very friendly. They have their sort of use cases that they pursue. Google's now donated the project to CNCF. And so they're running it that way. Now it doesn't mean that there aren't FaaS on top of it. Red Hat have a serverless product VMware have one. But OpenFaaS because it owns the whole stack can get you something that's always been very lean, simple to use to the point that Keith in his hotel room installed it and was product with it in an evening without having to be a Kubernetes expert. >> And that is and if you remember back that was very anti-Kubernetes. >> Yes. >> It was not a platform I thought that was. And for some of the very same reasons, I didn't think it was very user friendly. You know, I tried open with I'm thinking what enterprise is going to try this thing, especially without the handholding and the support needed to do that. And you know, something pretty interesting that happened as I shared this with you on Twitter, I was having a briefing by a big microprocessor company, one of the big two. And they were showing me some of the work they were doing in Cloud-native and the way that they stretch test the system to show me Auto Scaling. Is that they bought up a OpenFaaS what is it? The well text that just does a bunch of, >> The cows maybe. >> Yeah the cows. That does just a bunch of texts. And it just all, and I'm like one I was amazed at is super simple app. And the second one was the reason why they discovered it was because of that simplicity is just a thing that's in your store that you can just download and test. And it was open fast. And it was this big company that you had no idea that was using >> No >> OpenFaaS. >> No. >> How prevalent is that? That you're always running into like these surprises of who's using the solution. >> There are a lot of top tier companies, billion dollar companies that use software that I've worked on. And it's quite common. The main issue you have with open source is you don't have like the commercial software you talked about, the relationships. They don't tell you they're using it until it breaks. And then they may come in incognito with a personal email address asking for things. What they don't want to do often is lend their brands or support you. And so it is a big challenge. However, early on, when I met you, BT, live person the University of Washington, and a bunch of other companies had told us they were using it. We were having discussions with them took them to Kubecon and did talks with them. You can go and look at them in the video player. However, when I left my job in 2019 to work on this full time I went to them and I said, you know, use it in production it's useful for you. We've done a talk, we really understand the business value of how it saves you time. I haven't got a way to fund it and it won't exist unless you help they were like sucks to be you. >> Wow that's brutal. So, okay let me get this right. I remember the story 2019, you leave your job. You say I'm going to do OpenFaaS and support this project 100% of your time. If there's no one contributing to the project from a financial perspective how do you make money? I've always pitched open source because you're the first person that I've met that ran an open source project. And I always pitched them people like you who work on it on their side time. But they're not the Knatives of the world, the SDOs, they have full time developers. Sponsored by Google and Microsoft, etc. If you're not sponsored how do you make money off of open source? >> If this is the million dollar question, really? How do you make money from something that is completely free? Where all of the value has already been captured by a company and they have no incentive to support you build a relationship or send you money in any way. >> And no one has really figured it out. Arguably Red Hat is the only one that's pulled it off. >> Well, people do refer to Red Hat and they say the Red Hat model but I think that was a one off. And we quite, we can kind of agree about that in a business. However, I eventually accepted the fact that companies don't pay for something they can get for free. It took me a very long time to get around that because you know, with open source enthusiast built a huge community around this project, almost 400 people have contributed code to it over the years. And we have had full-time people working on it on and off. And there's some people who really support it in their working hours or at home on the weekends. But no, I had to really think, right, what am I going to offer? And to begin with it would support existing customers weren't interested. They're not really customers because they're consuming it as a project. So I needed to create a product because we understand we buy products. Initially I just couldn't find the right customers. And so many times I thought about giving up, leaving it behind, my family would've supported me with that as well. And they would've known exactly why even you would've done. And so what I started to do was offer my insights as a community leader, as a maintainer to companies like we've got here. So Casting one of my customers, CSIG one of my customers, Rancher R, DigitalOcean, a lot of the vendors you see here. And I was able to get a significant amount of money by lending my expertise and writing content that gave me enough buffer to give the doctors time to realize that maybe they do need support and go a bit further into production. And over the last 12 months, we've been signing six figure deals with existing users and new users alike in enterprise. >> For support >> For support, for licensing of new features that are close source and for consulting. >> So you have proprietary extensions. Also that are sort of enterprise class. Right and then also the consulting business, the support business which is a proven business model that has worked >> Is a proven business model. What it's not a proven business model is if you work hard enough, you deserve to be rewarded. >> Mmh. >> You have to go with the system. Winter comes after autumn. Summer comes after spring and you, it's no point saying why is it like that? That's the way it is. And if you go with it, you can benefit from it. And that's what the realization I had as much as I didn't want to do it. >> So you know this community, well you know there's other project founders out here thinking about making the leap. If you're giving advice to a project founder and they're thinking about making this leap, you know quitting their job and becoming the next Alex. And I think this is the perception that the misperception out there. >> Yes. >> You're, you're well known. There's a difference between being well known and well compensated. >> Yeah. >> What advice would you give those founders >> To be. >> Before they make the leap to say you know what I'm going to do my project full time. I'm going to lean on the generosity of the community. So there are some generous people in the community. You've done some really interesting things for individual like contributions etc but that's not enough. >> So look, I mean really you have to go back to the MBA mindset. What problem are you trying to solve? Who is your target customer? What do they care about? What do they eat and drink? When do they go to sleep? You really need to know who this is for. And then customize a journey for them so that they can come to you. And you need some way initially of funneling those people in qualifying them because not everybody that comes to a student or somebody doing a PhD is not your customer. >> Right, right. >> You need to understand sales. You need to understand a lot about business but you can work it out on your way. You know, I'm testament to that. And once you have people you then need something to sell them that might meet their needs and be prepared to tell them that what you've got isn't right for them. 'cause sometimes that's the one thing that will build integrity. >> That's very hard for community leaders. It's very hard for community leaders to say, no >> Absolutely so how do you help them over that hump? I think of what you've done. >> So you have to set some boundaries because as an open source developer and maintainer you want to help everybody that's there regardless. And I think for me it was taking some of the open source features that companies used not releasing them anymore in the open source edition, putting them into the paid developing new features based on what feedback we'd had, offering support as well but also understanding what is support. What do you need to offer? You may think you need a one hour SLA for a fix probably turns out that you could sell a three day response time or one day response time. And some people would want that and see value in it. But you're not going to know until you talk to your customers. >> I want to ask you, because this has been a particular interest of mine. It seems like managed services have been kind of the lifeline for pure open source companies. Enabling these companies to maintain their open source roots, but still have a revenue stream of delivering as a service. Is that a business model option you've looked at? >> There's three business models perhaps that are prevalent. One is OpenCore, which is roughly what I'm following. >> Right. >> Then there is SaaS, which is what you understand and then there's support on pure open source. So that's more like what Rancher does. Now if you think of a company like Buoyant that produces Linkerd they do a bit of both. So they don't have any close source pieces yet but they can host it for you or you can host it and they'll support you. And so I think if there's a way that you can put your product into a SaaS that makes it easier for them to run then you know go for it. However, we've OpenFaaS, remember what is the core problem we are solving, portability So why lock into my cloud? >> Take that option off the table, go ahead. >> It's been a long journey and I've been a fan since your start. I've seen the bumps and bruises and the scars get made. If you're open source leader and you're thinking about becoming as famous as Alex, hey you can do that, you can put in all the work become famous but if you want to make a living, solve a problem, understand what people are willing to pay for that problem and go out and sell it. Valuable lessons here on theCUBE. From Valencia, Spain I'm Keith Townsend along with Paul Gillon and you're watching theCUBE the leader in high-tech coverage. (Upbeat music)

>> Narrator: Live from Austin Texas. It's theCUBE, covering KubeKon and CloudNativeCon 2017. Brought to you by Red Hat, the Linux Foundation, and theCUBE's ecosystem partners. >> Welcome back everyone, live here in Austin Texas, theCUBE's exclusive coverage of CloudNativeConference and KubeKon, for Kubernetes' Conference. I'm John Furrier, co-founder of SiliconANGLE and my co-host Stu Miniman, our analyst. And next is Matt Klein, a software engineer at Lyft, ride-hailing service, car sharing, social network, great company, everyone knows that everyone loves Lyft. Thanks for coming on. >> Thanks very much for having me. >> All right so you're a customer of all this technology. You guys built, and I think this is like the shiny use cases of our generation, entrepreneurs and techies build their own stuff because they can't get product from the general market. You guys had a large-scale demand for the service, you had to go out and build your own with open source and all those tools, you had a problem you had to solve, you build it, used some open source and then give it back to open source and be part of the community, and everybody wins, you donated it back. This is, this is the future, this is what it's going to be like, great community work. What problem were you solving? Obviously Lyft, everyone knows it's hard, they see their car, lot of real time going on, lot of stuff happening >> Matt: Yeah, sure. >> magic's happening behind the scenes, you had to build that. Talk about the problem you solved. >> Well, I think, you know, when people look at Lyft, like you were saying, they look at the app and the car, and I think many people think that it's a relative simple thing. Like how hard could it be to bring up your app and say, I want a ride, and you know, get that car from here to there, but it turns out that it's really complicated. There's a lot of real-time systems involved in actually finding what are all the cars that are near you, and what's the fastest route, all of that stuff. So, I think what people don't realize is that Lyft is a very large, real-time system that, at current scale, operates at millions of requests per second, and has a lot of different use cases around databases, and caching, you know, all those technologies. So, Lyft was built on open source, as you say, and, you know Lyft grew from what I think most companies do, which is a very simple, monolithic stack, you know, it starts with a PHP application, we're a big user of MongoDB, and some load balancer, and then, you know-- >> John: That breaks (laughs) >> Well, well no but but people do that because that's what's very quick to do. And I think what happened, like most companies, is, or that most companies that become very successful, is Lyft grew a lot, and like the few companies that can become very successful, they start to outgrow some of that basic software, or the basic pieces that they're actually using. So, as Lyft started to grow a lot, things just didn't actually start working, so then we had to start fixing and building different things. >> Yeah, Matt, scale is one of those things that gets talked about a lot. But, I mean Lyft, you know, really does operate at a significant scale. >> Matt: Yeah, sure. >> Maybe you can talk a little bit about, you know, what kind of things were breaking, >> Matt: Absolutely, yeah, and then what led to Envoy and why that happened. >> Yeah, sure. I mean, I think there's two different types of scale, and I think this is something that people don't talk about enough. There's scale in terms of things that people talk about, in terms of data throughput or requests per second, or stuff like that. But there's also people scale, right. So, as organizations grow, we go from 10 developers to 50 developers to 100, where Lyft is now many hundreds of developers and we're continuing to grow, and what I think people don't talk about enough is the human scale, so you know, so we have a lot of people that are trying to edit code, and at a certain size, that number of people, you can't all be editing on that same code base. So that's I think the biggest move where people start moving towards this microservice or service-oriented architecture, so you start splitting that apart to get people-scale. People-scale probably usually comes with requests per second scale and data scale and that kind of stuff. But these problems come hand in hand, where as you grow the number of people, you start going into microservices, and then suddenly you have actual scale problems. The database is not working, or the network is not actually reliable. So from Envoy perspective, so Envoy is an open source proxy we built at Lyft, it's now part of CNCF, it's having tremendous uptake across the industry, which is fantastic, and the reason that we built Envoy is what we're seeing now in the industry is people are moving towards polyglot architectures, so they're moving towards architectures with many different applications, or many different languages. And it used to be that you could use Java and you could have one particular library that would do all of your networking and service discovery and load balancing, and now you might have six different languages. So how as an organization do you actually deal with that? And what we decided to do was build an out-of-process proxy, which allows people to build a lot of functionality into one place, around load balancing, and service discovery, and rate limiting, and buffering, and all those kinds of things, and also most importantly, observability. So things like tracing and stats and logging. And that allowed us to actually understand what was going on in the network, so that when problems were happening, we could actually debug what was going on. And what we saw at Lyft, about three years ago, is we had started our microservices journey, but it was actually almost, it was almost stopped, because what people found is they had started to build services because supposedly it was faster than the monolith, but then we would start having problems with tail latency and other things, and they didn't know hot to debug it. So they didn't trust those services, and then at that point they say, not surprisingly, we're just going to go back and we're going to build it back into the monolith. So, we're almost in that situation where things are kind of in that split. >> So Matt I have to think that's the natural, where you led to service mesh, and Istio specifically and Lyft, Google, IBM all working on that. Talk a little bit about, more about what Istio, it was really the buzz coming in with service mesh, there's also there's some competing offerings out there, Conduit, new one announced this week, maybe give us the landscape, kind of where we are, and what you're seeing. >> So I think service mesh is, it's incredible to look around this conference, I think there's 15 or more talks on service mesh between all of the Buoyant talks on Linker D and Conduit and Istio and Envoy, it's super fantastic. I think the reason that service mesh is so compelling to people is that we have these problems where people want to build in five or six languages, they have some common problems around load balancing and other types of things, and this is a great solution for offloading some of those problems into a common place. So, the confusion that I see right now around the industry is service mesh is really split into two pieces. It's split into the data plane, so the proxy, and the control plane. So the proxy's the thing that actually moves the bytes, moves the requests, and the control plane is the thing that actually tells all the proxies what to do, tells it the topology, tells it all the configurations, all the settings. So the landscape right now is essentially that Envoy is a proxy, it's a data plane. Envoy has been built into a bunch of control planes, so Istio is a control plane, it's reference proxy is Envoy, though other companies have shown that they can integrate with Istio. Linker D has shown that, NGINX has shown that. Buoyant just came out with a new combined control plane data plane service mesh called Conduit, that was brand new a couple days ago, and I think we're going to see other companies get in there, because this is a very popular paradigm, so having the competition is good. I think it's going to push everyone to be better. >> How do companies make sense of this, I mean, if I'm just a boring enterprise with complexity, legacy, you know I have a lot of stuff, maybe not the kind of scale in terms of transactions per second, because they're not Lyft, but they still have a lot of stuff. They got servers, they got data center, they got stuff in the cloud, they're trying to put this cloud native package in because the developer movement is clearly pushing the legacy guy, old guard, into cloud. So how does your stuff translate into the mainstream, how would you categorize it? >> Well, what I counsel people is, and I think that's actually a problem that we have within the industry, is that I think sometimes we push people towards complexity that they don't necessarily need yet. And I'm not saying that all of these cloud native technologies aren't great, right, I mean people here are doing fantastic things. >> You know how to drive a car, so to speak, you don't know how to use the tech. >> Right, and I advise companies and organizations to use the technology and the complexity that they need. So I think that service mesh and microservices and tracing and a lot of the stuff that's being talked about at this conference are very important if you have the scale to have a service-oriented microservice architecture. And, you know, some enterprises they're segmented enough where they may not actually need a full microservice real-time architecture. So I think that the thing to actually decide is, number one, do you need a microservice architecture, and it's okay if you don't, that's just fine, take the complexity that you need. If you do need a microservice architecture, then I think you're going to have a set of common problems around things like networking, and databases, and those types of things, and then yes, you are probably going to need to build in more complicated technologies to actually deal with that. But the key takeaway is that as you bring on, as you bring on more complexity, the complexity is a snowballing effect. More complexity yields more complexity. >> So Matt, might be a little bit out of bounds for what we're talking about, but when I think about autonomous vehicles, that's just going to put even more strain on the kind of the distributed natured systems, you know, things that have to have the edge, you know. Are we laying the groundwork at a conference like this? How's Lyft looking at this? >> For sure, and I mean, we're obviously starting to look into autonomous a lot, obviously Uber's doing that a fair amount, and if you actually start looking at the sheer amount of data that is generated by these cars when they're actually moving around, it's terabytes and terabytes of data, you start thinking through the complexity of ingesting that data from the cars into a cloud and actually analyzing it and doing things with it either offline or in real-time, it's pretty incredible. So, yes, I think that these are just more massive scale real-time systems that require more data, more hard drives, more networks, and as you manage more things with more people, it becomes more complicated for sure. >> What are you doing inside Lyft, your job. I mean obviously, you're involved in open source. Like, what are you coding specifically these days, what's the current assignment? >> Yeah, so I'm a software engineer at Lyft, I lead our networking team. Our networking team owns obviously all the stuff that we do with Envoy, we own our edge system, so basically how internet traffic comes into Lyft, all of our service discovery systems, rate limiting, auth between services. We're increasingly owning our GRPC communications, so how people define their APIs, moving from a more polling-based API to a more push-based API. So our team essentially owns the end-to-end pipe from all of our back-end services to the client, so that's APIs, analytics, stats, logging, >> So to the app >> Yeah, right, right, to the app, so, on the phone. So that's my job. I also help a lot with general kind of infrastructure architecture, so we're increasingly moving towards Kubernetes, so that's a big thing that we're doing at Lyft. Like many companies of Lyft's kind of age range, we started on VMs and AWS and we used SaltStack and you know, it's the standard story from companies that were probably six or eight years old. >> Classic dev ops. >> Right, and >> Gen One devops. >> And now we're trying to move into the, as you say, Gen Two world, which is pretty fantastic. So this is becoming, probably, the most applicable conference for us, because we're obviously doing a lot with service mesh, and we're leading the way with Envoy. But as we integrate with technologies like Istio and increasingly use Kubernetes, and all of the different related technologies, we are trying to kind of get rid of all of our bespoke stuff that many companies like Lyft had, and we're trying to get on that general train. >> I mean you guys, I mean this is going to be written in the history books, you look at this time in a generation, I mean this is going to define open source for a long, long time, because, I say Gen one kind of sounds pejorative but it's not. It's really, you need to build your own, you couldn't just buy Oracle database, because, you probably have some maybe Oracle in there, but like, you build your own. Facebook did it, you guys are doing it. Why, because you're badass, you had to. Otherwise you don't build customers. >> Right and I absolutely agree about that. I think we are in a very unique time right now, and I actually think that if you look out 10 years, and you look at some of the services that are coming online, and like Amazon just did Fargate, that whole container scheduling system, and Azure has one, and I think Google has one, but the idea there is that in 10 years' time, people are really going to be writing business logic, they're going to insert that business logic >> They may do a powerpoint slides. >> That would be nice. >> I mean it's easy to me, like powerpoint, it's so easy, that's, I'm not going to say that's coding, but that's the way it should be. >> I absolutely agree, and we'll keep moving towards that, but the way that's going to happen is, more and more plumbing if you will, will get built into these clouds, so that people don't have to worry about all this stuff. But we're in this intermediate time, where people are building these massive scale systems, and the pieces that they need is not necessarily there. >> I've been saying in theCUBE now for multiple events, all through this last year, kind of crystallized and we were talking about with Kelsey about this, Hightower, yesterday, craft is coming back to programming. So you've got software engineering, and you've got craftsmanship. And so, there's real software engineering being done, it's engineering. Application development is going to go back to the old school of real craft. I mean, Agile, all it did was create a treadmill of de-risking rapid build scale, by listening to data and constantly iterating, but it kind of took the craft out of it. >> I agree. >> But that turned into engineering. Now you have developers working on say business logic or just solving, building a healthcare app. That's just awesome software. Do you agree with this craft? >> I absolutely agree, and actually what we say about Envoy, so kind of the catchword buzz phrase of Envoy is to make the network transparent to applications. And I think most of what's happening in infrastructure right now is to get back to a time where application developers can focus on business logic, and not have to worry about how some of this plumbing actually works. And what you see around the industry right now, is it is just too painful for people to operate some of these large systems. And I think we're heading in the right direction, all of the trends are there, but it's going to take a lot more time to actually make that happen. >> I remember when I was graduating college in the 80s, sound old but, not to date myself, but the jobs were for software engineering. I mean that is what they called it, and now we're back to this devops brought it, cloud, the systems kind of engineering, really at a large scale, because you got to think about these things. >> Yeah, and I think what's also kind of interesting is that companies have moved toward this devops culture, or expecting developers to operate their systems, to be on call for them and I think that's fantastic, but what we're not doing as an industry is we're not actually teaching and helping people how to do this. So like we have this expectation that people know how to be on-call and know how to make dashboards, and know how to do all this work, but they don't learn it in school, and actually we come into organizations where we may not help them learn these skills. >> Every company has different cultures, that complicates things. >> So I think we're also, as an industry, we are figuring out how to train people and how to help them actually do this in a way that makes sense. >> Well, fascinating conversation Matt. Congratulations on all your success. Obviously a big fan of Lyft, one of the board members gave a keynote, she's from Palo Alto, from Floodgate. Great investors, great fans of the company. Congratulations, great success story, and again open source, this is the new playbook, community scale contribution, innovation. TheCUBE's doing it's share here live in Austin, Texas, for KubeKon, for Kubernetes conference and CloudNativeCon. I'm John Furrrier, for Stu Miniman, we'll be back with more after this short break. (futuristic music)