0:00 Introduction & Speakers

0:00 Well, hey. I'm, I'm Jason Morgan. I'm a technical evangelist with Voyant, and just means it's my job to talk to folks about Linkerd, encourage them to try it out, and help them be successful once they get on that path. Yeah. And I'm Catherine Panganini. I'm the head of marketing and community at Buoyant, and I will work with Jason on Link4D, but also on the cloud native glossary, something one of our pet projects that we created together and are very proud of. So yeah. Yeah. So, you're asking about what the cloud native glossary is. So it was it's

0:30 What is the CNCF Cloud Native Glossary?

0:33 it it's a glossary of terms, but it's not as boring as it sounds, I promise. Or it's really boring but still helpful. So our intent was as we're as we kinda got together and started working together, you know, before working together at Buoyant Right. Right, we'd we'd each spend a lot of time trying to explain to folks concepts around Kubernetes and cloud native and like, if you've ever had to talk to your friends or people in your self circle about about this space, you'll find a lot of the terms don't, like, don't have meaning to a lot of

1:06 people. Right? And the glossary was an attempt to take terms like service mesh, container, you know, gate API gateway. It was a pure team. Yeah. Yeah. Was their ability. All the same. Make them easy to understand in plain language. And the English part's good, but the really exciting part is Oh, yeah. So we are we have several localization teams that are localizing the glossary in I don't know how many languages now, but we have Chinese, Korean, Spanish, Portuguese, French. Oh, French is not live yet. Spanish and I don't know. Probably missing something. The Hindi one's live. Oh, Hindi. Yeah. So very

1:48 excited about that. And I think one of the important things, especially for someone who is with my background who does not have a technical background, it's really hard to understand cloud native. There is no context. And most of the content out there really assumes a lot of context that people like me don't have. And so one thing that was important for me when we created LostRay was to lighten a way that people like me can understand, because there are a lot of people who need to understand it and are not technologists. You have all the

1:50 Glossary's Purpose: Accessibility for Non-Technical Users

2:22 people who are working in cloud native companies, marketing, sales, but the leadership team too who are ultimately taking and making all these decisions about whether to fund project which is very expensive. And so if they don't understand it, you cannot talk to your leadership team about these projects. How how can they make these decisions? So so the goal is not only to educate technical people but also nontechnical people. And I feel like it's good, like the way they're described, it's accessible for both. Right? Like, if you're just getting started, a technical person will appreciate the easy, digestible language, but it's all it's

3:01 not excluding nontechnical people as well. I think that's a great I think that's a great explanation. So I heard a couple questions in there. Right? Like, is the glossary done? No. Right? Absolutely not. And it it won't get done. And what we'd really love is for folks for folks that are good at understanding and explaining technical terms, if you have some time and some bandwidth, look at our look at look at the definitions that are out there. If they can be improved, send PRs. If there's something missing, you know, create an entry. If you're a business or if you

3:04 Contributing to the Glossary

3:34 are in the space and and you use a lot of terms, but you don't necessarily have them defined, don't go write your own glossary and definitions. Link to the cloud native glossary. You know, and then whatever whatever language is your native tongue, right, if it's not English, you know, we would love to see love to see cloud native become accessible. And that sounds terrible, not as I We love the the tooling and the technology to become more accessible to more folks. Make it a broader audience. Not not so much for like specialized engineers that really love Kubernetes and containers, but make

4:07 it for people that are just trying to get things done with computers. Alright? And make it easier for those folks. So I think I answered a lot of your questions. Yeah. And think one one of the important things is the glossary is really a living document. Right? Like, things change all the time. Technology changes all the time. Right. That's why it's like, it's it's not good to have like, if you see definitions now out there, most of them are vendor provided, which is actually really bad because vendors might be biased towards their own product, they may not keep it up to date,

4:17 Glossary as a Living, Vendor-Neutral Document

4:43 you know. There are lots of issues with it. So like having a glossary that is vendor neutral by an institution like the CNCF where anyone can contribute, you know, that is a document that is always updated, that will ensure that they're vendor neutral, that they are objective, they're not, you know, representing some vendor's view. And so, yeah, I mean, it is changing a lot. So that living aspect of it is really important, and that's why I think it will never end, Right. As cloud native ends, you know? So there's always new technology coming and yeah, and it's like as people

5:22 use it, that's our goal, right? As people use it, you may because there's one approach, right? Contributing to looking for specific terms that you feel should be included, but my hope or our hope is that as people use it, right, you're using it because you wanna cling to it or understand it or explain it to someone, as you read it and you're like, Arun, I actually think this could be improved or this could be slightly better or we could build on that. Right? Like like, that's how it gets better. It's a little bit like Wikipedia. Right? Wikipedia is really

5:50 good because so many people contribute. Right? And the more people contribute to the glossary, the better it will be. I think the foundation is there, so we have a lot of round covered. But I'm pretty sure a lot can be improved. I'm pretty sure we missed terms. So Yeah. There are some terms that I really wanna get out there, like get ups. Meaning help with that, simplifying that, so if anyone is interested in helping out with that term, it's not merged yet. So yeah, I mean, anyone interested in that. And what Jason mentioned, really, it's explaining

6:22 complex terms and simple words is really hard. Right. It requires a lot of knowledge. But it's really fun once you get there. So it's not easy, but it's like and it yeah. It's like once you see it, once you read it, and it's such a yeah. It's just I I think it's like a joy to read it, and it's like so digestible. It's like, suddenly it sounds so easy, and then yeah. Them. Yeah. Yeah. The one only caveat I'd put out there, if you're thinking about it, right, like, if you're gonna write a definition for something, it's not, like, it's

6:44 International Community & Localization Efforts

6:51 not an entry level thing. Even though there's no code, right, you really have to understand what you're talking about in order to explain it in a clear fashion. Just be warned out there if you're thinking about contributing. That's Yeah. Like a little bit of a misconception. I think like the localization aspect of this is good for entry level contributors just because there is already a solid Definition of the definition of And then localizing is a lot easier in that sense. It's still difficult. Like localizing well, but it's a little easier. You don't need to be an

7:19 expert knowing it because someone did already that research and so, yeah. But it's fun. And, oh, the other thing is like we have we have monthly meetings where we meet with all the different teams around the world. It's so exciting. You have like people from China, from Korea, India, Spain, South America, and Brazil. It's like it's it's really cool and like Yeah. That community, and we all try to help each other, and they learn from each other. I think that that is a little bit special. Think that it is a little bit more international because of that localization

7:50 aspect of it. And also, I know that the Kubernetes has localization, but I don't think they collaborate as much as our localization team, and they don't know each other as much. And so I know some of them do localize the Kubernetes docs, and they've said that. And I think that's kind of nice. Meeting people all around the world. So Yeah. It's pretty cool. So the origin story for the glossary, right, like where did it come from? You know, I I say this a lot. Right? But it's really cool working with Catherine because, like, you know, most people, when you

8:10 Origin Story: From Landscape Confusion to the Glossary

8:18 see something that's messed up, right, like, oh, that's funny. That's messed up or whatever. Right? And you kinda move on. You know? So Catherine and I started working together because she saw the CNCF landscape talk and was like, hey, you know, this is a giant mess of things. It's hard to understand. And she she was like, let me figure out how to make it better. So she started writing this article series on explaining the cloud native landscape in a clear fashion. And so we started working together on that. And as that grew and, you know, we

8:48 we actually started to make something really valuable, we got involved with the CNCF. And and Catherine's been working with the CNCF for a while, but we're like, hey, there's a lot of focus on technical value from the CNCF. But what about, like, actual outcomes? What about business value? And long story short, we set up this business value committee within the CNCF. And when we set it up, we're like, hey, what are some things we can do to help the CNCF add value to businesses? And one of the early ones that we came up with was

9:18 a glossary of terms. Like, it would be really helpful if there first thing. You need to understand the concepts before you Yeah. You need have common language. First yeah. Right? Like, if you don't use if you and I use a word differently, the same word differently, that's that's a barrier to understanding. And so having having shared definitions seemed Yeah. Like the best and most boring place to start. Yeah. And I think, like, I mean, the CNCF started out really as the like, I mean, like, at the earlier on, like, only the most technology advanced and highly skilled

9:50 engineers were interested in topics. So they had all these content and very geeky, right, like but so much changed since then. Like, we're seeing so much adoption. And as I mentioned before, you have all these marketing and salespeople, all the leadership team, all we have all these people who are not necessarily technical, but it's, for them, critical for their biz like, business critical for them to understand it. Otherwise, they cannot sell it. Otherwise they cannot make the right decisions. But there was no content that was, like, for them. So, like, we also thought, like, because the first articles

10:20 that we did was for the new stack, and that was great. That's where we got a lot of feedback. And at some point, we said, like, CNCF should own this type of content. Like, why is I mean, it's great. We love the news stack and we appreciate appreciate the opportunity. But, like, the CNCF is the eminence in this, you know, field, and they should kind of make it easier. How's it work? I feel. Yeah. It's a little too much. It's a very satisfying sound, though. I really enjoy it. So I think one of the things that

10:49 CNCF's Broader Push for Business Value & Accessibility

10:50 With the business value subcommittee, right, do you believe this is really a question because I don't know the answer. Do you believe that the CNCF is gonna do more things that focus on business leaders and help them understand the value of the tech, not just the tech? So, well, like, first of all, like, the business value tracks at coupon is something that came out from our Yeah. And we so we A of people come we did the first we were the first reviewer for the first because it was like a separate thing. Yep. So I think that is new.

11:25 It's still kind of, well, is geared towards technical people too, but it's talking about the business value, right? And I mean, the business value sub committee is there to create these resources. So we we create we have created the glossary where in the works is a project summary table, which is still not ready, but it basically puts like all the projects in one category side by side, and you can compare what they do. This is not like business value, there's also like a business case in it, but it's like making sense of it or helping end users

11:57 actually select which projects they should evaluate, and that came because like a service provider mentioned it is so difficult for them to, like the landscape is overwhelming, he does not know which projects are relevant for their clients, it's like you either have the landscape which just just give you a name, and then you have like deep dives, and there's not like how do you, like, they need an overview, it's like to understand like, okay, a, b, c look interesting, I'm gonna evaluate those. And it's really hard to kind of see what's relevant. And so that's

12:25 like an end user request, right, like, or or need, so we try to cater to that. And then now we're also building cloud native learning journey, which is basically a page that will have all these CMCF resources bundled and it will start with content that doesn't require any previous knowledge, right? So it's like, okay, if you're very new, this is the one on one section, start with the cloud native definition, then maybe the glossary, and then gets increasingly more advanced to really help people in their cloud native learning journey instead of having to find all these resources on from

13:00 themselves. So I think most of that content is not like initiated by the CNCF, but like groups like ours, that's where people can tell. And most of them is like generally people say like, oh, this is a problem I've had. And then we were like, okay, you're having this problem, someone else probably having this problem. Like, let's solve this together. Like, let's create something that helps you, and in that way help other people too. So so I don't think yeah. It's not CNCF driven in that sense, but it's like these these groups kind of create

13:30 there are a lot of groups. Why the cartographers group is another group that created like the Cloud Native Maturity Model and all these things. So there are all these people who volunteer, contribute to open source without codes, and non code contributions, also very important and very valuable. So Yep. There are a lot of initiatives. Right? And so what we wanna do is make it easier for people to find that. And just to add add a little bit to what Catherine said, right, like you can see with, you know, the things that the business value community came out with, You see

13:59 with the emphasis in talks at KubeCon, right, more more user stories and getting getting out of vendor stuff. That certification that's meant to be, like, hey, you're new to this space. Let's give you a baseline a baseline conversational knowledge that you need to to have those hallway track conversations with a lot of folks have been in the space for a long time kinda take take for granted. So I think I think the CNCF is absolutely working to better explain the real value, not this not just the technological value, but the outcome value of projects things.

14:33 CNCF Support for Community-Led Initiatives

14:33 Super supportive. The thing is, like, the CNCF is small. They have a very small team. Right? And they are they depend, let's say, on the community to help and support. And like once you have a good idea and they believe in it, they really give you the resources, right? Like to create a glossary, you need someone to develop the website, and so we get all the resources which is amazing, and then the PR team, like that's where my marketing sales comes, like I know what needs to be done, and then the PR team is amazing, and then they're like, you know, like

14:59 I don't know, they write a blog post or talk to reporters, and like, so they make the resources available to to help get the word out, which is, so I think it's great. I've really enjoyed working with the CNCF. Alright. So you want me to to define service mesh? I'm gonna do it off the top of my head. I'm not gonna look it up. Right? But a service mesh is according to the the glossary definition, and somebody look me up as you're watching this and and laugh at how wrong I am. But it is it is a tool that

15:11 Defining Service Mesh

15:28 uses uses effectively a don't think it has to be a sidecar, but uses a series of load balancers to route your traffic from an application through to this other process. Right? Let me start again. A a service mesh exists to take the platform level infrastructure that your applications need when you're gonna run-in a microservice environment and take that code or that tooling that allows you to do a good job at service discovery, secure your traffic over the network, do circuit breaking, do timeouts, do retries, take it out of your application code so you're not doing

16:06 it in a shared library and instead put it in a separate process, route your traffic through that process, and give them the responsibility for core usability on the network features for your app to something that can be managed by your platform team. At its core, it's intended to allow platform teams to deliver more value to application development teams by reducing their operational overhead and giving them better performance, better security for their applications. So but look it up and feel free to mock me. It's less technical in the Yeah. Glossary. Yeah. I'll put it on the

16:42 screen underneath just as you go around. Thank you. Yeah. Great. Do I do we think everybody that's using Kubernetes should have a service mesh? No. I don't think everybody needs to have one, and I try not to deal in shoulds in a general sense. But I think for most folks that are using that are using Kubernetes, right, like, a little bit of a story. Right? Like, I used to work at a company and we had we had a service mesh based on one of the big one of the really well known service mesh products out there. I won't I won't name it.

16:46 Do You Need a Service Mesh? (and Linkerd's Role)

17:16 Right? And, you know, we used to tell folks, like, get get Kubernetes figured out first because it's hard. And then you add in a service mesh and it's harder. Right? And that's that's a thing that a lot of folks deal with as they begin that as they begin that journey. And since I've been at Boeing, partly because, it's my job to tell you to use Linkerd e, right, but I came here because I believe Linkerd e is good. I'll tell you, is a tool that in my view and in my experience with customers that adopt

17:46 it, it makes Kubernetes easier. So if you're doing REST based services, you're doing gRPC applications, and you're running in Kubernetes, this is a tool you can add to your environment to enhance the capabilities of your platform and to make life, like, make life easier for yourselves and your developers. Right? And that's that's pretty that's pretty awesome. So if if you're building custom apps, I would recommend a service mesh. If your cluster is intended exclusively to host infrastructure components like your registry, your CICD system, other like vendor products that vendors are responsible for the core code,

18:23 then I don't think I don't think a service mesh is particularly important unless you're have, like, a high security regulatory requirement for encryption in transit. And even then, you could probably bug your vendor to, like, use HPS calls between their components. Right? That's that's my view on that. I don't know if you have anything to add. No. It's like, I mean, it's more of a technical part. Yeah. Because like, I hear it all the time that a lot of people say, like, service metrics are are think that it's so overly complex How complicated. That then

18:49 play try Linkerd and it's not. I, course, cannot have experimented with it because I don't code. But it's like, apparently, it is a lot easier than a lot of people think. And if you get a lot of value out of it, and we always say, like, just give it a try and it's for Don't believe us. Just just try it Right. And then you'll see. Best features of Linkerd you know, the thing that I tell people is we think Linkerd is awesome because it's boring. Right? Like, I think the best feature of Linkerd is you can have something

19:09 Key Features of Linkerd

19:20 that runs in Kubernetes, install Linkerd, add that thing, that application to the mesh, and it still works. Right? I think I think that's fantastic. Beyond that, right, like, somewhat, whatever tongue in cheek value point. Right? Mucil TLS, like, having a guarantee that every conversation in your cluster between components is gonna be encrypted and both the client and the server are gonna be positively identified using cryptographic identity, I think is really a big deal. Right? Like, the thing that you trust to do mobile banking, the thing that you trust to, you know, browse whatever secure thing you need to do on the

20:01 Internet is the foundation of trust they can use in your cluster between your components. And that's hugely powerful. And, you know, third, it depends what you're doing, but I like I'll tell you, I had a terribly painful experience before Kubernetes trying to get trying to get 15 different app teams to all write a slash metrics endpoint in their app and put some sort of comparable data. So I could look at app a and app b and see similar results. And that was brutally hard. With with BlinkerD, you get the same metrics for every single application

20:37 without any without bothering any developers, which is my favorite thing. I, I hate trying to get people who are trying to develop a feature to instead stop what they're doing and build plumbing. Right? That was it was not a great experience. Yeah. So you're asking about what's what's next with Linkerd and and specifically around Linkerd and the Gateway API. So really exciting, I guess. Exciting is gonna depend on who you are. What I find exciting from a technical perspective is there has been a move with Linkerd to add things like policy, let you do header

20:53 Linkerd and the Gateway API

21:10 based routing, let you do some more intelligent things with your traffic. But we're trying to balance that new set of features with, you know, the thing that Linkerd has always been famous for, which is simplicity, not having a ton of custom resource definitions. Right? Things like that. And the gateway API project came along at a incredibly good time for us. Right? And and it turns out that the primitives that the gateway API gives you in your Kubernetes class there are exactly the sort of things that you don't just need from an ingress perspective, but that you want in order to manage

21:39 traffic east west between your applications. And we're adopting the constructs in Linkerd. I think by 02/14, we expect to be a % gateway API compliant, right, which is which is really exciting. And it it's gonna allow us to do do policy, do header based routing, do traffic splitting, do all of it with no, you know, without any new linkerdy isms in your cluster. No adopting, no changing the way you work to fit our mesh. Right? Which is the reason we're easy to use today, and it's the way we're gonna be able to give new features to folks out there while keeping

22:15 that same promise. Yeah. Great question. Thank you so much. So, where do you go to learn more about Linkerd? Well, I biased towards Slack, slack.linkerd.io. You can join up. You meet other folks that are doing linker d. Talk to us. See if you have, you know, commentary about how badly I messed up the service mesh definition. I'm at Jason on the linker d Slack. You can find us on Twitter, just at linker d. We have a website, linkerd.io, where you can learn more. That's where all our docs are. Our getting started guide, which is fantastic.

22:17 Linkerd Resources & Service Mesh Academy

22:46 You can go get Linkerd up and running in a Kubernetes cluster. If it takes you thirty minutes, let me know. I'll also apologize for that. And we have Service Mesh Academy. Oh, oh, right. If you go to Boynton, sorry. Go ahead. Yeah. Yeah. So if you're interested in getting, like, hands on experience with Linkerd, once a month, we have a live workshop. And, yeah, like, topics. Next topic is GitOps with Flagr, Flux, and Liberty. So really excited about that. I think that's next week. But, yeah, like, every month there is, a new topic. It's % open source.

23:19 Yeah. And they're they're, like, technical deep dives. Right? So you're gonna you're gonna really get to know a particular component of Linkerd and the way it works. Like, I learned a ton when we talked about certificates and the way we do routing, and I could just really highly recommend it. Yeah. Well, yeah. For sure. Like, thanks a ton for for having us. We really appreciate it. Thank you. You know, it's been a it's been a great conference. It's been great getting to hang out a little bit. So Yeah. We've loved it. Yeah. Thanks so much

23:34 Conclusion & Thank You

23:43 for having us and and letting us share our little pet project and talk about VingerDee. I really appreciate the opportunity. Thank you, Dave. Yeah.