← Kubernetes Podcast from Google
Kubernetes Podcast from Google
Linkerd, with William Morgan
00:53:06
is the CEO of , the company behind Linkerd. You worked at Twitter before as a software engineer and engineering manager and you have a long experience in the field. Do you have something cool to share? Some questions? Let us know: - web: -...
Loading summary
Transcript173 lines
- [00:00]
Abdel Sigiwar
Hi and welcome to the Kubernetes podcast from Google. I'm your host, Abdel Sigiwar.
- [00:05]
Kazlyn Fields
And I'm Kazlyn Fields.
- [00:16]
Abdel Sigiwar
In this episode we speak to William Morgan. William is the CEO of Buoyant, the company behind Linkerd. We talked about Linkerd's architecture and use cases and how a company can balance business and open source.
- [00:29]
Kazlyn Fields
But first, let's get to the news. Red Hat announced the Red Hat Connectivity Link, an implementation of the Gateway API and Project Quadrant to automate connectivity between applications deployed on different platforms. Check out the link in the show notes for more details.
- [00:48]
Abdel Sigiwar
The schedule for Kubecon and Cloud Native Con 2025 in London is live. The event is taking place April 1st to 4th in Excel London.
- [00:58]
Kazlyn Fields
The call for proposals for the next major Kubecons are still open for Kubecon China and Japan. The cfp will close February 2nd and they are accepting proposals both in Japanese and English for Kubecon Japan and Chinese and English for China and for Kubecon India. The CFP will close on March 23rd and applications are expected in English.
- [01:19]
Abdel Sigiwar
Cubesonet is the name of a new open source project from Polar Cygnus. The tool uses EBPF to measure and report cross zonal traffic in Kubernetes hosted on cloud environments. Network traffic between availability zones in the cloud are not typically free and the tool provide users with the visibility to monitor cross zonal traffic and optimize their setup to be more cost effective.
- [01:42]
Kazlyn Fields
And that's the news.
- [01:45]
Abdel Sigiwar
Today we are talking to William Morgan. William is the CEO of Buoyant, the company behind Linkerd. You worked at Twitter before as a software engineer and also an engineering manager and you have a very long experience in the field. I'm super excited to talk to you today. So welcome to the show, William.
- [02:01]
William Morgan
Thank you Andil. Great to be here and thank you for having me.
- [02:03]
Abdel Sigiwar
I'm glad we managed to finally get to do this. Last time Linkerd was on the show was 2022. I actually checked it out. So I guess in five years there have been a lot of new things I hope. But as usual we try to start our episodes with the assumption that no one knows what we are going to be talking about. So my first question to you is what is Linkerd? Can you like give us a basic introduction?
- [02:25]
William Morgan
It's an open source project and it's a service mesh and in the early days of Linkerd I often had to spend a lot of time explaining why Service mesh was like a thing that you had to care about. Nowadays that term at least has kind of become a little more common. But the idea is that you add linkerd to a kubernetes cluster or a set of clusters, and it kind of provides this application layer of networking. Where normally we think of networking as how do I get a TCP packet from point A to point B. A service mesh like linkerd is going to be focused more on how do I get HTTP requests to go safely from one pod to another. Can I do retries? Can I do timeouts? Can I do request level load balancing? Can I send it across clusters? Can I secure both sides of the connection with mutual TLS so I can encrypt things and keep it and authenticate them? So kind of this higher order level of features. So that's what linkerd does. And the goal for us is you should be able to add linkerd to an existing kubernet application and not break the application and not have to change any of your configuration. You should be able to just start getting new and powerful capabilities.
- [03:32]
Abdel Sigiwar
Awesome. So, yeah, the way I always describe service mesh is it's adding intelligence to the network layer essentially, in a way, without having to change the application, as you said. So you don't really need to modify your application to be able to do like mtls end to end encryption or authentication or stuff like that. So as somebody who have been dabbling mostly in the ISTIO space for a while, I just read the documentation to prepare for the episode and so, you know, you correct me if I'm wrong. So linkerd follows like a very standard kind of architecture, control plane, data plane kind of architecture with sidecar proxies, right?
- [04:02]
William Morgan
Yes.
- [04:03]
Abdel Sigiwar
So what makes it different from other service meshes out there?
- [04:07]
William Morgan
Yeah, I think the biggest difference kind of starts with a philosophical difference, which is our angle for linkerd has always been around maximizing simplicity and especially operational simplicity. So our model of our user is, okay, here's some poor soul who's been tasked with adopting Kubernetes and, and learning everything about Kubernetes and the kind of like rich set of knowledge you have to imbibe in order to be able to operate kubernetes successfully. And now they're adding Linkerd into that mix. Can we minimize what they really have to know? Can we stick as closely as possible to, you know, kind of the way that kubernetes already works? Can we make it so that linkerd gives you features out of the box by default without having to add config as much as possible. And then when you do have to add config, can we kind of make sure that that config scales sublinearly with the value you're getting back from it? So that ethos has kind of informed every design choice that we've made in Linkerd. And I think Linkerd's reputation kind of like showcases that philosophy. Like, when people tell us that they love it, it's because they're like, okay, it's because it's so simple. It's because I didn't have to do a bunch of complicated things to make it work. And maybe more importantly, it's because at 3am when I wake up, alarm bells are ringing because I'm an SRE and I'm on call or whatever. I can understand what Linkerd is doing. I can build, like a mental model of how it works, and then I can diagnose and debug it really quickly. And, you know, we can talk about how that philosophy kind of turned into specific implementation choices and things like that. And when we talk about, like, the proxy and stuff like that, we'll get into some of those details. But really that philosophical difference, I think, is the most salient when comparing to other projects.
- [06:01]
Abdel Sigiwar
Yeah. So we're going to get into the details. I just wanted to mention very quickly when you said, if you are like a poor engineer that is tasked with learning kubernetes, I think that we, like a lot of people, assume that everybody knows Kubernetes very well, and you just have to jump into Reddit to see the horrifying fact of how much people are still struggling. It's quite interesting for me. I was talking to Kathleen the other day, and I saw a post on Reddit recently about somebody saying we have apps deployed on Kubernetes, but we have to restart the pods every. Every week because, you know, they treat them as VMs, essentially. They're like pods, but they like. It's.
- [06:35]
William Morgan
Yeah. And it's funny because Kubernetes has been around for 10 years now. And so, like, we finally, you know, there was always a joke of like, oh, you know, this job posting is like asking for 10 years of Kubernetes experience. Well, now we actually have 10 years old. Right. You know, and we've been doing. I've been involved with Kubernetes, or at least Kubernetes adjacent since 2016. So, you know, almost 10 years. Yeah, 10 years. But what strikes me is every time I go to Kubecon and I've gone to almost every, you know, North America and European Kubecon since the early days. There's new people in that audience all the time. Yeah. You know, so I find myself having to explain what linkerd is, what a service mesh is. I'm like, I've been doing this, you know, I've been explaining the same thing for like nine years now. But there's still new people coming to this audience. So I think it's a great sign. But you're right, you know, this is still new for a lot of people. It's still new.
- [07:24]
Abdel Sigiwar
Yeah, yeah. And so let's dive a little bit into it. Like looking at the architecture it does have from what I could see like mostly three components in the control plane. Right. Destination identity, proxy injector. Are these like individual pods?
- [07:34]
William Morgan
Typically it's a little messier than that. The destination component actually has. Yeah, those are three pods. The destination component has like three containers in it and the other ones all have one container. And like we've gone back and forth over time and probably in the future we might change some of those, some of those details. Well, there's, there's like a, there's like a balance, you know, that you're always striking between. You want to have a simple deployment, you don't want to have 100 things there. But each of these control plane components kind of has different scaling requirements and different resource consumption requirements as the data plane scales. So you don't also necessarily want to lump them all into one. Like any engineering kind of decision, it's really a set of trade offs in where you want to balance yourself across a set of trade offs. So today, yes, there's three basic pods and then there's like a set of containers inside them.
- [08:28]
Abdel Sigiwar
My follow up question to that was going to be do you realistically in production see these requiring like different scaling capabilities or different scaling requirements like with high scale deployments?
- [08:40]
William Morgan
Oh yeah, no, definitely, yeah. Like you know the proxy injector for example, that's a mutating and mission controller like thing. The only time it gets called is when a pod gets created. And so you know, if you suddenly create a whole crap ton of pods or if you're, you know, you have lots of pod churn, then that thing is really heavily used. If not, then like it's really, it requires a minimal resource basically doing nothing. Whereas the destination component, a lot of what that is serving is like service discovery lookups, kind of like dynamic configuration. So that tends to be the heaviest thing to Scale. And it scales, you know, kind of roughly along the lines of, you know, how many. What's the size of your data plane? It also depends on what the data plane is doing and how much traffic it's taking and how many new pods are being created. And so, you know, that turns into how many lookups do we have to do.
- [09:29]
Abdel Sigiwar
Yeah.
- [09:30]
William Morgan
So they do have pretty different scaling considerations based on the nature of your application.
- [09:35]
Abdel Sigiwar
I see. Yeah. And like, I guess you probably might have guessed it. My question is always related to that. Infinite debates about like microservices versus monolith and other service mesh tools have gone between the two. Right. So that's why I was, I was asking, like, was.
- [09:48]
William Morgan
Yeah, I don't have like a strong. I think earlier in my career I would have had this strong philosophical viewpoint. And at this point I tend to be pretty pragmatic about it. I think there's lots of value. Like Istio kind of famously went to the monolithic control plane. I think there's value to that. Is there enough to push linkerd over the edge to do that? Maybe every once in a while we kind of consider it and try and outline the pros and cons, but you know, it's just a collection of trade offs at this point.
- [10:16]
Abdel Sigiwar
Yeah, yeah. Cool. And so coming down to that, then if we go down to the data plane, I would have to, and excuse me for the term, you guys are a little bit old school. You are still doing proxies.
- [10:26]
William Morgan
Yeah, well, this is a more, you.
- [10:27]
Abdel Sigiwar
Know, all the new kids are not doing proxies anymore.
- [10:30]
William Morgan
Well, no, no, no, Abdul, they're still doing proxies. Everything ends up being a proxy. It's just, where do you put that proxy? And then, you know, how much do you talk about it?
- [10:39]
Abdel Sigiwar
Let's be correct in my statement. The cool kids are not doing sidecars anymore.
- [10:42]
William Morgan
Well, I wouldn't even say they're the cool kids. I think we're the cool kids and they're the fuddy duddies. Because the first version of linkerd didn't use sidecars either. First version of linkerd used per node.
- [10:55]
Abdel Sigiwar
Proxies, a shared proxy.
- [10:57]
William Morgan
Now this is like in the ancient days. This is like 2016, I think. I'm not saying this is a good. We moved away from the model for a reason, but part of the reason was because we had these very heavyweight proxies at the point they were actually running on the jvm. They're written in Scala. We had built them on top of a bunch of Twitter open source libraries that we had used and the jvm, it's not very cool these days, but it is very good at scaling up. It's not very good at scaling down. And so we were like, well, these proxies are like 150 megs. There's no way that we can really use them as a sidecar. So we'll just put them on per node basis where you kind of can amortize that resource usage. And it worked pretty well. And that was the first version that went to production kind of famously at companies like Monzo. But then what we learned and the reason we moved to Sidecars later was it was just really annoying operationally because you'd have this one proxy would be responsible for whatever random selection of pods had been allocated to that node. And then if that proxy died or if you were rebooting it because you were upgrading it or whatever, then like some random section of your application is not working of your applications would be impacted. And so the kind of the operational blast radius was really random and the security blast radius was not great. You have all the TLS certificates sitting in memory and this one thing, and you're like, well, it's kind of like defeats. We did all this work to get containerization and isolation and now we've kind of undone it. We took all our TLS certificates and we're just mixing them in memory in this one process. So for a variety of reasons, we moved to Sidecars. So yes, we're the cool kids, they're the funny duddies that are going back to the olden way.
- [12:38]
Abdel Sigiwar
All right, I just wanted to see how much I can trigger you with that. So let's talk about the proxy. So it's called linkerd 2. I assume that's because there was a linkerd 1.
- [12:47]
William Morgan
Yeah, yeah, that's right.
- [12:48]
Abdel Sigiwar
And it's written in rust.
- [12:49]
William Morgan
Yes. Yeah.
- [12:50]
Abdel Sigiwar
And you call it a microproxy. So it's just a sidecar that does basically what most sidecars in most other service meshes does, right?
- [12:56]
William Morgan
Yeah, yeah, that's right. That's right. So what we did, you know, we had that kind of 1.0 architecture based on the JVM and per node proxies. And at some point we were like, this just isn't really serving our users needs. And so we wrote linkerd 2.0. And by the way, you should never rewrite your project from scratch. Right. This is like the classic second system syndrome. Like every software engineering textbook is like, this is a bad idea. So we did the bad idea. That's what came out. Maybe we got lucky. But yeah, so we said we're going to. If we were to do this the right way, what do we think is the most efficient, most effective, especially from the operational and security perspectives. And it ended up with us writing what we're now calling a microproxy. I don't think we used that term at the time. Written in Rust that was designed to run as a sidecar. And the reason why we ended up calling it microproxy is because it's really distinct from something like Envoy or nginx, which are these kind of general purpose proxies. Right. They're like these Swiss army tool. You can use it for anything. You can front your cluster with it, you can put it against the open Internet or you can treat it as sidecar, do whatever. For us, we were like, like, we're going to trim it down to the bare minimum. Like, what is just the features that you need when you're running in a cluster and you're next to a pod and we're going to do it in Rust. And you know, this is like 2018. So the choice to use Rust was like pretty scary at that point. The language had just solidified, actually. I don't know, you know, first version of this might. Rust might have been pre 1.0 or something. Yeah, it was an ecosystem.
- [14:34]
Abdel Sigiwar
Was like, yeah, you know, funny story that I had the opportunity to interview Matt Klain, the person who wrote Envoy. And in the interview, it's actually in the show, Matt Klain said if he got the opportunity to rewrite Invo, he would rewrite it in Rust because Invoi is written in C. Yeah, well, I.
- [14:49]
William Morgan
Think in the world of. What year is it 2025, like, it's a clear. That was a clear win. But at the time it was a real gamble, you know, and we had to spend the next couple of years. Again, this is a terrible idea. You should never do this. But we had to spend the next couple of years kind of funding some of the basic networking ecosystem. There's libraries, if you're a person. There's libraries like Tokyo and hyper and h2 that are the foundation of any HTTP proxy that just weren't there or were in the most rudimentary forms. And so we had to fund that basic development just to get this proxy to the point. Now in 2025, we're like, oh, it was a great idea, awesome. But gosh, it was a big, big gamble at the time.
- [15:29]
Abdel Sigiwar
Yeah, I'm just going to go on a wimp and assume you hired a bunch of of junior engineers that just had this idea of let's just rewrite everything. Right. Because that's every junior engineer dream.
- [15:38]
William Morgan
That's even worse. It was our most senior engineer. Senior engineer. You could be like, well, you know, you can argue senior engineer. You're like, well, sure, sure.
- [15:49]
Abdel Sigiwar
All right, so then, okay, back to the point of invoice. So this was the first time I found out what Linkerd is and your name because I read the article that is like why Linkerd doesn't use invo. And this is back from 2020, right?
- [16:01]
William Morgan
Yeah.
- [16:02]
Abdel Sigiwar
So you touched on it a bit. So Invoice General purpose proxy. Linkerd to proxy is a micro specific proxy. Can you talk a little bit more about why not just use something that exists? That might have been easier.
- [16:16]
William Morgan
Yeah, I felt kind of uncomfortable writing that article too. This is back in 2020, like you point out, but there were so many people who were saying like, well, why don't you use Envoy? Envoy is the de facto standard for service meshes. Why are you doing this? And I was like, you know, Envoy is a great project and I don't want to like shit on Envoy. Do I have to really write a blog post where I'm like, and here's why Envoy. So I tried to make it as like, as friendly towards Envoy as possible. But I think for us the core insight was the data plane is kind of the heartbeat of. It's the most important part of the service mesh because that's the part that your application traffic is going across. And we had, even back then we had users and adopters who were sending financial transactions across or who were sending medical data across or who were doing sending incredibly sensitive information through the proxy. And it didn't feel right to us as kind of security minded people to use C for something like that. No human being is able to write C in a safe manner. It just felt like we had to build something that was really going to be future proof. And so that led us to Rust. If you're not a Rust aficionado, kind of the biggest difference is that the language and the compiler have a whole set of checks and technologies and whatever. The borrow checker kind of famously that prevents you from misusing memory in unsafe ways. And so that ends up meaning your Rust program is going to run just as quickly as and C and it's close to the middle. But you avoid this whole class of security vulnerabilities that are unfortunately Endemic to C and C. So even back 2018 when we were making this call, we were like, it just didn't feel right to use something that was going to be kind of unsafe by default.
- [18:15]
Abdel Sigiwar
I've heard all sorts of arguments against C and C and for Rust. This is the first time I hear a safety or security focused algorithms.
- [18:24]
William Morgan
Right?
- [18:25]
Abdel Sigiwar
Yeah, it's the first time I hear somebody say, like, it makes so much sense when you talk about it, but I've never heard somebody say, like, it doesn't feel right to write something that could potentially be unsafe that would handle sensitive data. Right. Which you're right. Which is funny because a lot of other open source tools that the Internet relies on are actually written in C and they handle arguably a lot of sensitive data.
- [18:45]
William Morgan
Yeah, yeah, no. And you know, there are ways of making those programs become secure over time, hopefully through discovery, through humans spending a lot of time and energy on it. It just didn't, you know, that's like not the future of Software. Even in 2018, we were like, that can't be the future of software.
- [19:01]
Abdel Sigiwar
Yeah, sure. And so I'm going to bring you back a little bit before 2018. LinkerD have been around since 2016, so that's almost as old as Kubernetes itself. What have you seen change in the way people use it or adopt it over the years?
- [19:14]
William Morgan
Gosh, there's been so much evolution in this space. There's the obvious stuff where it's like, okay, well, we had to like justify why Linkerd existed for a long time and now we kind of have more interesting conversations than just that. We had to do a lot of work in the early days to distinguish the different types of proxies, because everyone at that point was very familiar with proxies. Right. You put your nginx was around, Apache was there. You put your proxy in between your application and the Internet and that's a proxy. And we were saying, well, actually you need like 10,000 proxies and you should put one in every pod. And people are like, oh, it's crazy. Like, I can't imagine running 10,000 Apaches. They all require so much tuning and feeding. We're like, well, no, no, you know, like this is a different thing and you're not going to have to become a proxy tuning expert. But it just took a long time, I think, for people to come to terms with the fact that because Kubernetes was like this building block that we could build on top of a lot of the stuff that seemed kind of crazy to say at that point, hey, we want you to deploy 10,000 proxies. Actually became pretty practical. Like that was one command. We had tools like the proxy injector, like mutating webhook and mission controllers and things like that where you actually could kind of do this. We had containers. So part of it was just up leveling people's expectations of what was reasonable for a piece of software to do. One thing that's been really interesting for me, I think has been watching how kubernetes adoption patterns have changed because that's everyone who's using linkerd is using it with Kubernetes. So we kind of like get exposed to how they're doing it. Yeah, Multicluster is like a really interesting one for me. We added the first version of multicluster in like, I don't know, 2019, 2020. It was pretty early into the project and it was basically like, hey, I've got these two clusters and like I need them to talk to each other. So how do I do that safely and securely and without like the application having to know about the cluster topology? So we built these features to do that, which was really cool. But they case then was kind of ad hoc. It was like, oh, I had this one cluster from this one team and this other team came up with their Kubernetes cluster and now we have to kind of piece them together. What we're seeing now is like a very different type of usage where people are out of the box. They're like, okay, we're going to deploy 200 clusters and we need them all or a thousand clusters. You're like, okay, well now there's a set of multi cluster features that actually are very different. It's like this planned adoption versus ad hoc adoption. So you just see things like that in the way that, that people are adopting kubernetes that end up influencing the linkerd roadmap. Like we added this feature recently called federated services. This was in 2.17 up to the latest release where you can basically treat, you know, if you have the same Service deployed across 200 clusters, you can treat it as one logical service and you can have your, you know, you're talking to that service. Well, we'll just load balance across all of those endpoints and if a cluster's down or if one pod is down, or if five clusters are down, or if there's a network like it doesn't matter, we'll just blow back across it. And that would have Been crazy five years ago, but now it's a pretty common use case.
- [22:24]
Abdel Sigiwar
As somebody who have been doing service mesh implementations doing multi cluster have been ad hoc, as you said, but now it's kind of becoming the norm more or less either for. Mostly for high availability. Right. So people want to reduce the blast radius or just for, you know, you deploy clusters across multiple regions in a cloud environment so you can get access to resources that you cannot get access to, access to one particular region or latency or whatever. Right. So those multi cluster use cases are kind of becoming part of discussion now. They're not like you're not going to look crazy if you say I'm doing multicluster now.
- [22:55]
Kazlyn Fields
No.
- [22:55]
William Morgan
And like, you know, kind of related to that. It seemed like in the early days there was a big focus on kind of these large multi tenant clusters. And so we tried in the very first early days of linkerd to make it so you can install linkerd and like just one part of the cluster, one namespace. And like you could have, if you didn't have cluster admin privileges, maybe you could just install it in like one namespace and have it as one tenant as a mesh. And like that ran into friction pretty quickly. But the pressure to do that has also vanished. You know, I think people are. That was kind of like the mesos kind of approach to the world, which is where I cut my teeth at Twitter on distributed systems. It was like one giant cluster, multi tenant. Now people are gravitating towards lots and lots of kubernetes, clusters that are smaller, that are often single tenant.
- [23:41]
Abdel Sigiwar
Yeah. And linkerd, like just from reading the documentation, linkerd sounds like the philosophy is also following this like minimalistic approach. Right. Like out of the box you get the minimal. And by minimal I don't really mean minimal in a bad way, but like the minimal amount of features available out of the box and then if you need stuff you have to install them later. Right. Is that like a fair way to describe it?
- [24:03]
William Morgan
Yeah, like reduce the config burden as much as possible and give you as much.
- [24:08]
Abdel Sigiwar
Yeah. And so that's like comes through plugin and comes through like a bunch of other ways. And so speaking of this topic of minimum, because I wrote. So this is. I'm gonna like churn my own horn a little bit here. I wrote an article a while ago which was why you shouldn't. Or I did the talk and an article called you probably don't need a service measure.
- [24:25]
William Morgan
Oh no.
- [24:26]
Abdel Sigiwar
It was basically how could you say that my life's work here, I am happy you don't know about it because some other people found it and they were not very happy. My whole point about that content was to try to tell people you shouldn't adopt a service mesh without understanding what you are doing. It was an argument about blind adoption. And my typical joke when I do this particular talk when I did it in the past was to tell people, I want to tell you why you shouldn't adopt a service mesh just because your security person read an article about mtls and came to you and said we need mtls, therefore we need a service mesh. Do you see my point? Like that's like blind adoption of technology without understanding what it does, right?
- [25:03]
William Morgan
Yeah.
- [25:04]
Abdel Sigiwar
So then this long introduction to go to my question. Where do you see a service mesh today in the cloud native architecture in general? Do we need it? Do we require it? Is it optional? Where do you see kind of like that debate settling, if it will settle?
- [25:20]
William Morgan
Yeah. Well, first, I think you're absolutely right. Blind adoption by definition is not what you want to do. And it's funny because I think that I love the cloud native community. It's a community of people who love learning and who love new stuff and who love trying stuff. And I think that's largely a positive thing. I think it does have a consequence where there is a lot of excited adoption of something that maybe you don't really need because it sounds cool and it feels cool. And we certainly felt that in the early days of Linkerd. Linkerd is no longer cool. So we see a lot less of that now. It's like they've all gone off to EBPF or whatever, whatever like you know, wasm, whatever the new cool thing is. But I think that's almost a part of this community. It's just like this excited adoption of something that, you know, maybe you don't actually. Don't actually need.
- [26:06]
Abdel Sigiwar
Yeah.
- [26:07]
William Morgan
Is service mesh required? This is a little self serving but I think we're getting to the point where it kind of is for non trivial deployments. Obviously if you have a cluster that's like your home cluster or you just have one cluster and you don't have requirements around encryption of data in transit or anything like that, you don't need it. But if we're in the case of like, oh, I've got 200 clusters and like they're going to have to communicate with each other, you kind of need a plan for that, you know, you need a plan for providing that Platform in a way that the developers are not exposed to the cluster topology and they're not like hard wiring in these, you know, these like things like cluster names or whatever into the code. So one way or another you need to solve that. And anything that the service mesh can, like any software, anything that the service mesh can provide you could solve in another way. Right? Like you could solve in the application layer. Of course, even tls, you know, have your applications do it. It's like horrible, but you could do it. But you know, I think the reason why Kubernetes is so powerful, one of the reasons why it's so powerful is because it fits into this model where like we're building a platform for our developers, right? Like we're kind of the service organization, we're the platform team, the devs are our customers and in that world you want to provide them with a bunch of capabilities without requiring them to write a whole bunch of platform specific code. And I think this linkerd fits right into that, whether it's multi cluster, whether it's TLS or whether it's something else. That's part of why our focus has been so much on how do we provide these features to you without you having to change code. Because changing code, it's not even you who's changing code, it's not the platform owner who's changing code. You'd have to ask the developers to change code. That's like the hardest conversation to have. So yeah, there's simple cases that don't require it. But I think as Kubernetes adoption evolves it starts becoming pretty important.
- [28:11]
Abdel Sigiwar
Yeah, it's interesting because my experience five years ago have always been the topic specific. You mentioned the topic of encryption in transit. That conversation was something I would have with regulated environments, regulated industries. So you talk to like banks or healthcare. Now it's in my experience actually becoming something that you are. It's a conversation you're having across the board. It doesn't really matter. It's just sometimes just like we're running cloud, but we don't trust it. Right. Like we just want to encrypt our data. We don't, like we don't. It's as simple as that.
- [28:41]
William Morgan
Well, you don't own the network. Your competitors could be running on the same network. Like you've got no idea. Exactly. So you kind of like in the move from on premise to cloud, you've lost all these guarantees you used to have. Right on on premise you had the physical wires and you had the racks with the locks and you're like, all right, this data, it's not going anywhere. And now you're like, you got no idea. So you have to recover some of those things that you lost from hardware. You have to recover them in software.
- [29:06]
Abdel Sigiwar
Yeah, yeah. I just have one more question for you. There was actually a panel discussion that you were part of and I think that this is not like the topic of the panel discussion is probably for me have been the defining topic of Open source in 2024. And there have been more discussions going on through 2024. I don't want to go into those discussions now. I just want to get like the panel discussion was about balancing and I'm going to introduce it and then let you correct me. Balancing open source and business. Like kind of like, how do you, how do you find that right line between being a maintainer of a project, which obviously means hiring people and paying them and making money out of open source projects? Right. What's your take? What's your thought on that?
- [29:49]
William Morgan
Yeah, Gosh, how much time do we have? It's like my life's work here, of course, and Linkerd kind of has a unique position here. Part of the reason. So I was on two very similar panels. One from kind of the founder CEO perspective and one from the maintainer perspective because I kind of have played both those roles. The reason why those panels were there was because there's been a big change over the past 18 to 24 months where, you know, in the world of Open source and I should say the world of commercial open source, because open source, huge spectrum, you know, and like what's true of the Linux kernel is very different from what's true of Python, which is very different from what's true of linkerd, which is very different from what's true of, you know, other projects. So we're talking specifically around what I would call commercial open source, which is really what is in the CNCF ecosystem.
- [30:34]
Abdel Sigiwar
It's like, yeah, yeah, pretty much with.
- [30:36]
William Morgan
One or two exceptions. Pretty much every project in this ecosystem is built by, there's a company behind it, you know, that's paying the maintainer. Sometimes there's multiple companies, although really if you look the majority of the time there's really one company where if that.
- [30:50]
Abdel Sigiwar
Company goes away, one pain, most of.
- [30:51]
William Morgan
Them project is failing and there's this big change. So okay, we're in that ecosystem and there's big changes happened where two years ago we were in what we call the ZIRP world, zero interest rate Policy money was free, VC money was flowing. Everyone's like, grow, grow, grow, grow, grow. Hey, you're a startup that's making an open source project. Like, I want to see your adoption numbers. And like if you get bigger adoption numbers, then you'll get more funding. And that was everyone's focus. And then the economy changed, it contracted fees, money dried up and suddenly a lot of projects and a lot of companies behind them were left in a situation where they don't have a functioning company and they have this open source project with a lot of adopters and they're like, I don't know what to do here. So that's scary. That's really scary from the CNCF ecosystem perspective. And we saw signs of that. We saw Weaveworks shutting down. That was crazy, right? The creators of GitOps, that's kind of a pillar of the community, gone. What happens to Flux? Well, for a while we didn't know. And then luckily Flux found a home. But like Flux could have disappeared easily. We saw projects like Redis and others change licenses. Like suddenly all this stuff is going on. I think if you're an adopter of one of these projects, you're in the ecosystem and you're relying on Kubernetes and Linkerd and Flux and like some of the other projects, you're probably being like, holy crap, like what's going to happen? Because I built my company on these projects and now suddenly a lot of them are having trouble. So I was on this panel. It's kind of like we explore these issues. There's one approach where it's to say, you know what, we don't want those projects. Forget those corporate OSS projects we only care about. Let's have projects that are like true multi vendor, like Kubernetes and arguably like Envoy. That's the only type of project that should be in the sansity and all the other projects should just die. You know, that's one approach. Obviously I don't like that one because I don't want to die. And the other approach, which is the one that I was kind of advocating for in these panels, is like, hey, let's be really honest and upfront about what these things are doing. Let's not pretend anymore that, hey, this is all one community of altruistic people coming together in harmony. Let's be upfront about the fact that pretty much everyone in these conferences or using these projects is doing it for money. Money, right? You're pulling this project in because your company is trying to build a business on top of it, or you're working for a vendor as an open source maintainer because you're trying to build your business. Everyone is in here for money. So let's be upfront about it. Let's not make it this shameful thing. We're like, oh, the vendors, they're off in the hall over there. We keep them over there. And you only go in there if you want socks. And the rest of the time we're talking about this pure open source community. That's not really what's happening here. And you know, the reason I was on this panel is because linkerd went through this, you know, through this process. And like in February of so almost a year ago, February of last year, we made a change that kind of profoundly improved our ability to provide linkerd to users. But it was a controversial one at the time. So I was there kind of talking about how that worked.
- [33:57]
Abdel Sigiwar
Yeah, it's definitely an interesting thing to notice from. I mean, I work for a vendor, but I'm obviously not very involved in the commercial side of things.
- [34:04]
William Morgan
Don't be ashamed. No one here works for a vendor.
- [34:07]
Abdel Sigiwar
Yes. What I mean is that like, I don't have a skill in the game in terms of like, well, I do in the sense that like, if Kubernetes is not making money, I don't have a job. But like, the point here is that like, I don't have the decision that like the magic wand that can allow me to like wave it and make a decision. But there was one thing that I saw that you wrote, I don't remember where exactly, that it like resonated with me so much because I am coming from the open source world of that perfect world. Like, we are all friends and everybody's happy and you know, like, we're all just like kind of of happy friends with each other. And then there was that change that was happening in February, which was like doing open source does not necessarily mean providing everything out of the box working. Right. Like, we're all spoiled in open source. Basically everybody just assumes you can have access to everything available all the time. And it was kind of like a wake up call. And I find it interesting, right? Like I find interesting discussion that's been happening and I think that that's going to carry on through 20, 25 and beyond. Right?
- [35:01]
William Morgan
Yeah, I hope so. I mean, I certainly had a lot of maintainers of other projects reach out to me when we made that announcement and say, hey, let me know how that works. Because we're in A similar situation and we have to figure out what to do. And so I was very happy. In like seven or eight months after we made that change, I was able to go out and write a blog post where I was like, hey, the thing we did and what we did was we didn't have to change a license because I was really trying to avoid that. We just changed the way that we were providing stable release artifacts. Well, we basically said we're not going to provide open source stable release artifacts, we're going to provide the weekly release artifacts. And if you want something that's called stable, that has semantic versioning guarantees, then you need to figure out how to get your company to pay for it. Yeah, and we did it in a nice way. You know, if your company is fewer than 50 employees and like just use it for free, that's fine. But if you're a big company and you're building a business on top of Linkerd, we said basically, and you're treating it as like this consumer, you know, as like a consumer, then you got to figure out a way to pay.
- [35:58]
Abdel Sigiwar
To pay for it.
- [35:59]
William Morgan
To pay for it. Yeah. And like you got to find a way to fund this project because like these maintainers are paid maintainers and I think you want that.
- [36:05]
Abdel Sigiwar
Yeah.
- [36:06]
William Morgan
As a Linkerd adopter, you want this project to be around. You want the maintainers to be like swimming in money and like just producing features without a fear in the world. Like that's good for you, you know, and it's good for them. But yeah, in October I was able to to write a blog post where it's like, hey, it worked. The company behind Linkerd Buoyant is profitable. We're adding more maintainers to the project. Like, we've kind of found this way of making Linkerd a truly long term project. We've been around for almost 10 years. Why can't we be around for another 90 years? Like, what do we have? You know? Yeah, and I was very fortunate to be able to write that and I feel very happy about that because not every project, I think is going to be able to make that, that transition. But I wanted to do it in a really upfront and honest way and say, look, there is a company behind Linkerd. We have to make money for Linkerd to survive. So, like, this is how we're going to do that.
- [36:58]
Abdel Sigiwar
Yeah. Open source costs money. That's something that people don't realize. Well, William, that was a fantastic conversation. I certainly learned a lot, so thank you for your time.
- [37:06]
William Morgan
Oh, absolutely. Thank you. I learned a lot too.
- [37:09]
Abdel Sigiwar
And yeah, I hope we'll be able to Talk again in five years from now when LinkerD announces Linker3 proxy.
- [37:15]
William Morgan
Yeah. Oh, boy. I hope not. Let's talk sooner than that, but with. Without hitting the 3.0 milestone.
- [37:20]
Abdel Sigiwar
All right, sounds good. Thank you very much, Mariam.
- [37:22]
William Morgan
All right, thanks, Abdel. Great talking to you.
- [37:25]
Kazlyn Fields
Thank you very much, Abdel, for that interview with William Morgan of Buoyant talking about Linkerd. This is one that we've been talking about for a while. Linkerd is a significant project in the CNCF ecosystem, and so it's been doing some really interesting technical things, and I loved the conversation about open source and business. So thank you for doing that, Abdel.
- [37:48]
Abdel Sigiwar
Yeah, it technically graduated to the CNCF before istio, so it has been around for a very long time as a service mesh tool. Right.
- [37:57]
Kazlyn Fields
I mean, ISTIO took a while to become part of the cncf, and then once it did, I think it was already graduated when it joined. Or was it incubating?
- [38:04]
Abdel Sigiwar
It jumped some steps.
- [38:05]
Kazlyn Fields
Yeah.
- [38:07]
Abdel Sigiwar
It took like a fast track.
- [38:09]
Kazlyn Fields
Yeah.
- [38:10]
Abdel Sigiwar
But yeah, the ninkity is it was on our mind for a while. I've been wanting to talk to somebody about it. Last time it was on the show was 2020, so it's been a while. So it's good to catch up and kind of figure out what's new, especially.
- [38:22]
Kazlyn Fields
Now that it's graduated. And I think early in the conversation, y'all were talking about where service meshes fall in today's world. I remember some meetups that I spoke at when I was trying to explain the concept of service meshes early on, and I was trying to come up with an analogy for it and like a net and the mesh, like networking. And I ended up describing service meshes as the things that Kubernetes doesn't do that you're like. You start using it and you're like, oh, I really need those. Service mesh just provides a bunch of those.
- [39:00]
Abdel Sigiwar
That's one way of looking at it, certainly. Yeah. It's basically a lot of features that you don't have in native kubernetes that if you watch.
- [39:07]
Kazlyn Fields
Which don't make sense in native kubernetes, really.
- [39:09]
Abdel Sigiwar
Which they're. You're right.
- [39:10]
Kazlyn Fields
Yeah, yeah. They're like application focused. Correct.
- [39:13]
Abdel Sigiwar
Or they are sometimes platform specific. Right, yeah.
- [39:16]
Kazlyn Fields
Therefore, meshing your services together.
- [39:18]
Abdel Sigiwar
I mean, before we go into the mesh discussion, like, a very simple example would be encryption, like end to end encryption. Like there are multiple ways you could do end to end encryption between pods.
- [39:26]
Kazlyn Fields
I have let myself get stuck in the trap though of like letting myself describe service meshes through that. And it's like, that's such a clear example that it's easy to be like, this is a thing that service meshes do and then not explain any of the other things service meshes do.
- [39:41]
Abdel Sigiwar
I agree with you. Except that the thing with this particular example is that on the surface, encryption between pods is an easy thing to understand as a use case. Right. But the implementation could vary depending how do you want to do it.
- [39:53]
Kazlyn Fields
Right, that's true.
- [39:54]
Abdel Sigiwar
There are like multiple ways of implementing it. So kubernetes trying to be this platform agnostic tool, it would be very hard to say, oh, we're going to do it it this way, because then it will not be platform agnostic, it would be more openaited. Right. So although technically all service meshes kind of use mtls. And that's kind of an interesting way of like that's an interesting thing where all of them converge toward the single way of doing encryption. Because there are certainly other ways, like you could use wireguard, you could use vpn, you could use like other tools. But it's just an example. Right.
- [40:27]
Kazlyn Fields
So yeah, with the prominence of MTLs, I hadn't even thought about the point that you could do other forms of encryption. So even if you were just looking for a service mesh for that one aspect of meshing your services together, there is variety that is caused by the distributed system that is Kubernetes. And so service meshes could be useful in that way. But yeah, people mostly just use mtls.
- [40:51]
Abdel Sigiwar
Yeah, that's kind of my pet peeve with. Well, used to be my pet peeve a few years ago when I wrote my article, you probably don't need a service mesh. Which was that coming out of that couple of years of working with people that just use it for the mtls part, which most of the time I was like, yeah, but there are other things you can do with this thing. Right?
- [41:11]
Kazlyn Fields
Invitation to those listening out there to interact with us, tell us how wrong Abdel is with his talk. You don't need a service mesh.
- [41:18]
Abdel Sigiwar
Yeah. So it's not you don't need a service mesh, it's you probably don't need a service mesh. There is a clear like separation there. Right, right. I stole the title from Mophie, but.
- [41:27]
Kazlyn Fields
That is very Mophie.
- [41:28]
Abdel Sigiwar
I was invited to a bunch of places with that talk. So I think Talks like this have a sort of like clickbaity feel to them.
- [41:38]
Kazlyn Fields
Yeah. Sometimes the clickbaity titles work out. You can go too far with it though.
- [41:42]
Abdel Sigiwar
Yeah. I mean, you have to have some substance behind what you're going to talk about. Right.
- [41:46]
Kazlyn Fields
But the point that you should not make blind decisions about what kind of tools you're using is always a valid one.
- [41:54]
Abdel Sigiwar
Correct.
- [41:55]
Kazlyn Fields
And so focusing that on service meshes, I think is a particularly poignant one because especially as we were talking about when service meshes first started up, nobody knew what it meant. And it's also pretty hard to understand what it is because it's so many things at the same time.
- [42:08]
Abdel Sigiwar
Yep, pretty much. Yeah.
- [42:09]
Kazlyn Fields
So it's a very valid thing to talk about.
- [42:11]
Abdel Sigiwar
So you know what? One thing that came to mind right now, just flashbacks to the consulting time when I was doing service mesh implementation. Service mesh was very interesting as a concept in the sense that in my interactions with different Personas, no one really seemed to understand it. Like I would work with people who are into cloud, native and kubernetes and they wouldn't understand it because that's too low level for them. And then you would expect. Well, certainly if I talk to somebody who's like into network engineering, they would and they don't because that's too high level. Right. And so it was always this just like floating thing that no one really knows what it does. It's like. Oh, it's like a layer, like. Yeah, but where, which layer? What are we talking about?
- [42:52]
Kazlyn Fields
It's super handy for certain things if you know what it's handy for and need those things. But you both have to know what you need and that it does that.
- [43:02]
Abdel Sigiwar
Pretty much, yes.
- [43:03]
Kazlyn Fields
These are two difficult things to figure out. Yeah.
- [43:07]
Abdel Sigiwar
And it's certainly coming from companies of the scale of Google where they need like something that works at high scale, hide the implementation details. I'm not saying that the idea came from Google, but the companies like Google. Right. And so obviously this is one of those. It's a technology that have been evolving to serve multiple things within one entity or multiple entities. And then when it makes its way to the public, not everybody necessarily have those kind of problems. And you know. Yeah, it's just, it's a much longer conversation, I guess.
- [43:36]
Kazlyn Fields
Technology.
- [43:37]
Abdel Sigiwar
Yes, yes.
- [43:38]
Kazlyn Fields
One of my favorite aspects of technical evolution that you all talked about in this conversation was Envoy.
- [43:45]
Abdel Sigiwar
Oh, yes. Oh, yeah.
- [43:47]
Kazlyn Fields
Let's talk about Envoy.
- [43:49]
Abdel Sigiwar
Yeah. I am a big fan of the Envoy project by itself, but I do understand Linkerd deciding not to go down the Envoy path because it's probably an overkill for what they were trying to achieve, at least when they were doing the implementation. Right?
- [44:03]
Kazlyn Fields
Yeah. A whole separate project that is designed to be a proxy. It kind of gets into the space we were just talking about where service mesh is flexible for all those different environments that you might be running Kubernetes in. And Envoy as a standalone project also has those considerations of it might be run in different environments and things. So it's got flexibility built into it that you might not strictly need for linkerd. And so they did their own implementation of proxy.
- [44:29]
Abdel Sigiwar
Yes, correct. And also Envoy technically came out before. I think I will have to double check that. But it's probably before most service mesh tools exist on the market, so. So it was designed to solve completely different problems and then it was adopted by Istio eventually. Right. If we talk about Invo in the context of istio. But yes, to your point, it does more than just what a service in the mesh needs it to do.
- [44:52]
Kazlyn Fields
Yeah, makes sense. But really cool as a standalone project. Maybe we'll explore that someday.
- [44:57]
Abdel Sigiwar
Well, I mean, we did an episode with Matt Klein, the creator of Invo, I think it was last year or the year before, talking about Invo itself, like the creation, the evolution of Invo over time. So that was the person who created it at Lyft. That's where it was created initially. So one actually example I want to explore, speaking of end users, because that's like one of the things we want to do more of this year. There are actually companies using it without istio. Like there are companies just running self managed Invo.
- [45:23]
Kazlyn Fields
Yeah.
- [45:23]
Abdel Sigiwar
And that's something I want to talk about. Right. I want to have somebody on the show to talk about.
- [45:27]
Kazlyn Fields
Yeah. As a user who does this, that would be very cool to hear more about. And one thing I really liked about the Envoy conversation though, was the. But it also got into Sidecars, which is one of my favorite areas in Kubernetes. Do we do sidecars or not? Particularly challenging conversation in the world of service meshes.
- [45:48]
Abdel Sigiwar
Particularly challenging because Kubernetes just started officially supporting them last year. Right.
- [45:57]
Kazlyn Fields
And even then they're not called then.
- [45:58]
Abdel Sigiwar
Even then they're not called that. Yeah, yeah. I think in the context of. We didn't really touch on it with William, but in the context of linkerd at least the linkerd2 proxy is a micro proxy, so it's pretty lightweight. Right. So it doesn't really consume that much resources. And now that Kubernetes has like first class support for sidecars. Codes on codes then I think it's a good choice, generally speaking. But it's just interesting to see all these service meshes kind of oscillating between sidecar S and sidecar 4, or sidecar less, whatever you want to call it.
- [46:30]
Kazlyn Fields
Everything you add on to a piece of technology has potential for risk. Right. So sidecars is one of those areas that gets particular attention with like, how risky is it to have sidecars on your applications?
- [46:44]
Abdel Sigiwar
Yeah. It's funny, there is a saying in my language in Moroccan dialect, which loosely translated to something around the lines of like, add water, add flour. So imagine you're making a dough. The more water you add, the more flour you need to add. And it's like a vicious cycle, like, where does it end? And so if you're Moroccan and listening to me, you know exactly what I'm talking about. And it's kind of like this with technology. Like, you add layers, you add problems, you add complexity.
- [47:08]
Kazlyn Fields
And that's why Kelsey Hightower's no code is the way.
- [47:11]
Abdel Sigiwar
Oh, yes. No code is the future.
- [47:15]
Kazlyn Fields
Alternative code, though. Rust.
- [47:18]
Abdel Sigiwar
Yeah, that was a bold choice.
- [47:21]
Kazlyn Fields
Yeah, bold choice. To Reimplement linkerd into linkerd2 and using Rust. Rust sounds like it paid off for them pretty well. Rust is still pretty popular, I would say. And you reach a point, especially with the evolution of kubernetes over the last 10 years. There have been things like Ingress is one of my favorite examples where like, we thought it was going to go this way. We thought this was what people needed and it wasn't exactly what they needed. So you had to reimplement it. And that's just how technology goes, is you implement the thing. People want something totally different from what you made, but they're trying to use the thing that you made to do, do what they want, and then maybe re implement it at some point. I liked that you called out that it was probably a junior engineer that did that and then it was a senior engineer who did that.
- [48:05]
Abdel Sigiwar
That was my assumption.
- [48:06]
Kazlyn Fields
Both can happen. Different reasons.
- [48:08]
Abdel Sigiwar
Yeah. I think it's quite interesting that they actually bet on rust when it was still quite new and quite fresh and lacked a lot of standard tooling and standard libraries specifically. So it was quite interesting. I think my joke about junior engineers is basically junior engineers want to re implement everything. Right. So that was the job.
- [48:26]
Kazlyn Fields
Yes. Because you start learning something as a junior engineer and you're like, why is this thing so terrible? We should make a better version of it and then you become a senior engineer by trying to re implement that thing and learning that they had reasons that they did that.
- [48:38]
Abdel Sigiwar
That's the life cycle of software engineer, I guess.
- [48:41]
Kazlyn Fields
Yeah. And one of my favorite parts of the conversation, as I already mentioned, was about open source and business. That is something that's come up a couple of times. We did that episode about open tofu in the awkward position of open source and business these days.
- [48:58]
Abdel Sigiwar
Yeah. And specifically that they have made some changes in the way they distributed artifacts last year, which a lot of people were not happy about. And I'm glad that I managed to get to discuss that with William because getting to understand his side of things is also interesting. Right. Or I mean his company side of things. Right.
- [49:14]
Kazlyn Fields
I liked the way he described it. Yeah, yeah, yeah.
- [49:17]
Abdel Sigiwar
I think it was well said in, you know, like, like open source costs money. You need people to build and maintain this stuff. Right.
- [49:24]
Kazlyn Fields
Constant conversation that's happening in open source among maintainers. It's like we need more help. Who's going to help us?
- [49:32]
Abdel Sigiwar
Who's going to pay for it?
- [49:33]
Kazlyn Fields
Yeah, who's going to pay for that especially? That's one of my favorite parts of the long term support conversation that's going on in open source because all the businesses offering Kubernetes want to offer long term support because none of their customers want to upgrade, which. Which is understandable because upgrading is pain and suffering. It's also critically important. So all the businesses want to offer long term support now because it's just so hard for businesses to be able to upgrade on the kind of cadence that Kubernetes releases on. But realistically, the longer you make the support window for open source kubernetes, the more money that open source Kubernetes needs to burn. Actually doing the testing of those for every release cycle so it makes the costs for the project go up astronomically very fast. And we're already operating as best we can with the budget that we have. So in open source it's like, who's going to pay for that?
- [50:33]
Abdel Sigiwar
Yeah, that money has to come from somewhere. Right? Somebody have to pay for it.
- [50:37]
Kazlyn Fields
Yep. And I liked his perspective about as a business, how do you do open source as part of your business? And like how it was before is not how it is now.
- [50:47]
Abdel Sigiwar
Yes. Yeah, definitely. I mean they could have gone a different way and changed licenses like a lot of other companies did. So I guess we're gonna probably just see more of those coming going forward. Like companies changing positions and by position it could be anything from licensing to the way they distribute their software because somehow somebody have to pay for that software being shipped and delivered and distributed to the end user. So yeah, we'll see. It's going to be interesting.
- [51:15]
Kazlyn Fields
And as an end user, if you had the choice between paying for software that is closed source with support and all that, versus paying for software that is open source, where you can see the code and the work that's being done on it in real time, but also get support on it, which one of those do you want?
- [51:32]
Abdel Sigiwar
I mean, we're obviously biased because we're going to go with the second choice, but yeah, it's an interesting conversation.
- [51:39]
Kazlyn Fields
Yeah. And I'm sure we'll talk about it more as we go through the year in 2025. Happy New Year, by the way, Abdel here at the very end.
- [51:45]
Abdel Sigiwar
Yeah, Happy New Year. I think we already said that, but Happy New Year. Yes, thank you.
- [51:49]
Kazlyn Fields
Yeah, more Happy New Year. I'm excited for what we're going to be doing in 2025.
- [51:54]
Abdel Sigiwar
Yeah, we have. I mean, you have seen the emails. I have spent most of my last week just like reaching out to people. A lot of exciting things coming, whereas.
- [52:03]
Kazlyn Fields
I've spent most of the last couple of weeks working on the report. Looking forward to more information about how we did in 20 soon check us out on social media. Yeah. So thank you very much, Abdel. Glad that we got to talk about Linkerd and I'll see you next time.
- [52:20]
Abdel Sigiwar
That brings us to the end of another episode. If you enjoyed this show, please help us spread the word and tell a friend. If you have any feedback for us, you can find us on social media Kubernetespod or reach us by email at Kubernetespodcastgool.com you can also check our website at Kubernetespodcast.com where you will find transcripts and show notes and links. To subscribe, please consider rating us in your podcast player so we can help more people find and enjoy the show. Thanks for listening and we'll see you next time.