 Well, hello everyone. Welcome to another episode of Kubernetes by example insider I had grad plans to do this from the fancy new sometimes referred to as Jenga building that is part of the use campus But I I got almost everything set up and kind of ran out of time Kind of one of those days. So here I am in my very spare old office You can see the stars are missing very depressing. The lighting is terrible and et cetera. So, but hopefully I sound okay And just by way of introduction, I'm Langdon White. I am a faculty member at Boston University And I host the show along with It's one of several of our guest hosts today. We have Savita and you want to introduce yourself? Sure. Hi everyone, I'm Savita Lagunathan and this is I it's my pleasure to be on the show and it's my fifth time and It gets better and better What can I say and it's a special episode? It's just before the holidays So I'm super excited to be here and talk to my good friend Divya Yeah, and so we we welcome Divya Mohan to the show And we'll talk about a bunch of stuff, but Divya, do you want to you know, introduce yourself give a little bit of background and who you are? Yeah, sure. So hi, and thank you Savita for having me on the show and thank you Landon Thank you the rest of the team that's gone to like great lengths to organize this just before the holidays I know how, you know, terribly Hectic it can get for a lot of folks out there Because before the holidays everything tends to start getting a little wonky Everything tends to slow down So I'm really really glad that I you know, I'm on the show and I get to you know, chat with you all so I I am a senior technical advance list at Susa you know at my day job and Over and about all the work that I do in the open-source space As part of my day job. I'm also You know one of the documentation maintainers for the Kubernetes project. I get to lead with some very awesome people and Basically, I have been a part of the Kubernetes ecosystem for around two three years, I think two years as of now, but It's been a very fun ride and I've learned a lot in the process. So I try to give it back via, you know, my role as a CNC of ambassador and Yeah, I think that's that's a little bit of a little bit about me and You know, we can we can talk about this all day because it's my favorite topic like I'm my favorite topic Talk about every single day. So yeah, that's me Cool, well, thanks so much for being on the show I would like to clarify that this is my last week of classes and so that is why this is also a crazy time for me But, you know, once once the classes are over and then finals begin things definitely start to slow down for the holidays And semester break, you know, it's kind of crazy So let's see to kind of get right into it So what does it mean that you do when you kind of are you know, we we talk about technical vandalism You know and and it's a new enough role that Different people have kind of different definitions of it. So so what is it exactly what you do in that kind of job? Yeah, so To be really really honest and fair with you Two years back when I was, you know at my previous job with HSBC I did not have an idea this existed in the very first place like it was It was a very very eye-opening to see that, you know, there is something that actually Is there out in this ecosystem and in this industry that helps bridge the gap between You know developers and the projects or the products that they consume. So essentially Technical evangelism or technical evangelist really just Could mean, you know, the person who's trying to bridge the gap and sort of be that, you know Person in the middle communicating between your developers or your end users who are actually using your project and the Creators of the project or you know, just an organization who's actually put the project out but When my role goes much more beyond that so I'm also involved in, you know, community building for the projects that we have in Susa, especially the cloud native side Not to not to, you know, completely isolate the Linux side of things but cloud native is where I'm a little more proficient in terms of, you know Experience and level of knowledge. So I guess that's that's why I you know advocate and speak about those projects in a bit more detail and over and about that I also like help Help, you know be that feedback loop Where in I speak to people who are in the community who are using our projects And feed it back to our engineers or if they have any questions or if they have any, you know What do I say concerns around specific features of the project I Conveyed back we have various forums where we interact with them and we try to bring in the engineers who actually work on the project as well to interact with these folks but Summarizing I think it summarizing the whole thing I think it would be just you know being that person in the middle who's actually being the bridge between the two extremes of the spectrum, but Did that answer your question? You know, I one of the things I wanted to kind of talk about and it's kind of related to, you know technical advocacy or technical evangelism is, you know You have a pretty heavy involvement in things around documentation And what I'm kind of curious about is like are those You know, are those kind of two pursuits Related that one caused the other or you know, basically it's kind of like what is Your kind of contribution to documentation? Why do you think it's important or what is important about the kind of the contributions that people make to documentation in general to a community and to like a piece of software Yeah, so I speak from personal experience when I say that, you know, documentation is extremely essential when it comes to a project a product Whether it's open source, whether it's proprietary, whatever be the case if you do not have appropriate documentation um It's going to be really tough to actually Attract users and even if you end up attracting, you know, your potential audience You will end up like, you know, having a steep onboarding curve set out for them Because if your documentation is not really great, it doesn't have You know, um that user friendly Accessible nature to it. It is going to sort of put your users off and you know tell Them that you know, maybe You know, you should actually try another project where you know, you're you're able to understand stuff better So in my opinion, I have been a part of so many Crisis calls and outage calls and you know Events where a lot of money is stuck online and I have been at the Receiving end of you know, or rather I have been at the end where I have to actually go through documentation and not really find The solution I'm looking out for I have been frustrated by it so many times that uh, you know That's that's one of the things that actually Propelled me towards the technical writing side of things earlier on um in the cloud in my cloud native journey um But coming to your point. I think these two are very um integrated uh, like, you know When you speak about evangelizing when you speak about putting your product out there or your project out there One of the very first things that has to be out there is also your documentation because Like it or not, it's the first marketing piece that's there out Like how many ever billboards you put up? How many ever ads you have? How many have uh, how many ever campaigns you have? That's the first thing that you consume as an end user as a developer or as a Whatever, so you have to consume that Piece of documentation first to understand the technology So it's I wouldn't say it's a form of technical evangelism, but it's very interrelated to what I do currently and it's something I'm extremely passionate about as well even though I Have moved on from the role of the technical uh writer in my organization. Um, I Just recently moved on. So, um, I still you know go back and you know tell people that It's important that your dogs are still, you know Up to date and not really up. It's not even the case of being up to date. It's more on the case of Accessibility, you know, it's more around how you structure your documentation make it more user friendly All of that matters like the content matters sure But you know, it has to be put in a specific way if you just you know, write Technical jargon in your documentation How how is like a person who's just getting started? Supposed to know that you know that particular phrase means something in you know That is important or integral to that product So it's very important because the whole point of evangelism or advocacy Is to simplify the onboarding experience is to actually communicate that that project exists And to help developers use that project. So documentation figures into the whole cycle uh, but Again, it's it's not like it's a part But it definitely figures in the whole cycle of actually evangelizing for your project So if you do not have good documentation all your evangelism efforts are really not going to work Your advocacy is not going to work Right, right Sorry I mean to coach here I I was going to add that I can totally relate to that because when I started with my community's journey Not everyone around me knew about it and I found the documentation in the community and now I know like, um There is an example um a reference for uh, whatever projects that I look at and sometimes I can even I I I will go a bit further and then say like I judge the projects and products based on their documentation, you know and Divya, you also mentioned a little bit about the technical writing and everyone um So the developers are you know, they are not trained um on Writing and I think that should be a skill that should be like part But it's not and people don't do it and we have any like a little bit of tips and tricks on how to like They can write good, um technical documentation for the feature that they are working on like you mentioned one thing that don't use a lot of jargons But is there anything um an addition to that that you can say, um That would have the viewers at me too personally No, so I I learned from you. So I mean, uh, like you you are my first, you know, whole entry point into the ecosystem so I mean, you've taught me a lot but um To come back to the question. I guess um The first thing that I would probably want to say is your simple words Even if it's not technical jargon sometimes people think it's like an essay writing competition. It's not. Um, you do not need to use Really flowery fancy words And you know show your prowess in English or in any other language To actually start writing technical documentation if you are able to explain Um it to a five-year-old So I actually judge Technical documentation that way now that if you're able to explain it to my five-year-old nephew And you're able to read it out on my five-year-old nephew is able to understand it um, yeah, I mean that's that's that's like, you know, the pinnacle of um Excellence for me, but I understand that not everybody can start off there. Not everybody can actually um You know start off writing like that. So the first thing that I would say is um Understand what you want to convey when you're talking about a feature Like you might want to convey specific things you might want to look at it. Um from you might want to dive deep Um and start off like at level 100 But also keep in mind that not everybody reading your documentation is going to start off at level 100 People are going to probably start at level zero or even below that if there is So try to keep that thing in mind. Uh, then next obviously you should have um some sense of grammar and syntax In the language that you're writing in I wouldn't say that you have to be um an avid reader or you know, like a prolific writer, but you need to have um, at least an intermediate level of um Excellence in the language that you're trying to write primarily because um If sentences are structured in a particular way They could mean one thing and if they're structured in a particular in another way, they could mean Another thing altogether. So you need to have that grasp Know your basic grammar and syntax and know how you know sentence structuring and You know phrasing it in a particular way could mean something totally different Like you need to have that knowledge and for that I think more than um intermediate level of knowledge of the language is not required and last but not the least, um Don't like I said introduce technical jargon at all because I've seen a lot of projects in the very first page they will write like 10 things and All of the 10 concepts will have no linking to any other website will have no You know context settings. So suppose, you know, uh project is leveraging some other technology or some other framework and You have to say that this project uses that framework Do not assume that that person knows about that framework hyperlink it Talk about it and at least two or three lines Make that person understand why you know that project why your project is leveraging that framework Set the context for that person because nobody is going to you know, come with like The amount of context that you have when you're writing the documentation. So link it have like, you know references in your If you can't link it have references You know noted somewhere in your page so that that person can go and visit that page later on So those are the three things that come like right off the top of my head But there's a lot more to unpack as you You know learn there's like, you know sectioning. There's like structuring of the documentation stuff like that but that comes with time like I did not start out as a trained technical writer either I had like fantastic mentors Over the course of my journey and they helped me become who I am so You will not start off great First draft is always going to be trash. So do not expect to write a great first draft But you improve over time and practice. Maybe it might not make you perfect, but it'll kind of get you closer to it So I have so many comments Um The the first one being uh, you know It's actually something I regularly say in most of my classes particularly ones related to like kind of programming Is how terrible language English is and actually how terrible all spoken languages are In the sense that it is so difficult to communicate what's in your head to somebody else, right? Yeah, this is why like requirements gathering is so difficult And kind of related to that when you're talking about something like documentation You know you can it doesn't matter, you know This is what makes a brilliant writer, right? Is that the closer you can get to what's actually in your head to the paper that you know the more brilliant you are Right. Um, and but then kind of a related topic or kind of two similar topics This is one of the reasons I'm really glad that I went to a liberal arts college And even though many people in the technical fields Complain about like core You know where you have to go and take a writing class, right? Or maybe even several writing classes This is why it's so important. Um, you know, it's because being able to Read and write at a at a kind of a sophisticated level is really important no matter what you do, right? And then the last comment I wanted to make was that and you kind of alluded to it at the end, which is that Just get something on paper Or or you know written it doesn't really matter what it is or how good it is just write it And then go back and fix it, right? Like people I think get often scared by the blank page, right? You know, even if it you can even go so far as to kind of take some other piece of content, right and adapt it And you know, sometimes my adaptions are a hundred percent replacement eventually, right? You know, the the key is get something out and then just keep going keep going keep going The other thing and then my last comment But I think then we should find fun Which is just that one of I think the biggest failures of writing on the internet these days or kind of in general Is that the entire point of that whole like htp and html thing? Why differentiated from books is because you can immediately cross-reference But no one does it in my opinion anywhere near enough, right where you can just say hey You know if you do want to use all that technical jargon Or you haven't figured out how to write it in such a way that you can get rid of it yet You can always have a glossary and you can always have links, right? And and that's the magic of being able to write on the web That I like said sometimes maybe I go a little overboard like I have too many links But at the same time, you know, there's a lot of uh, you know I think people don't have for the fact that your your content is not standalone when it's web Yeah Yeah, which I think is hugely important um but yeah, so what I wanted to kind of move on to a little bit is You know when we were kind of talking about this show in advance It seems like you've been getting pretty heavily involved in what's called web assembly And we've actually weirdly enough had a number of people on the show who talked about web assembly And so what I'm first curious to hear it's like Okay, there's a technology there, but what's your take on it? Why do people keep getting interested in it? What's the what is it about web assembly that is kind of maybe changing things and why would it be changing things? So, um to be honest, uh, this is a question. I asked myself last year When I started getting involved rather not getting involved rather learning it myself because um at first glance web assembly looks like something that's made for the web and Probably is like similar to assembly level Assembly language programming or stuff like that. Like why would anyone be interested? Is the first question I asked myself, um, and uh, then I of course went down into a rabbit hole and um you know dug like I've never done before and um I I discovered various other Assets where web assembly could actually be utilized and they they were already being done. So Um, it it's not it's no longer just for the web. Um, it it was introduced as a specification that would Like, you know bring more languages to the web. Um, and it was you know kept uh, not kept rather announced with that in mind, but um as you know the Framework matured. Um, and we're still maturing. It's not like we're done As a framework matures. I think we are seeing more applications In the server side and there are several cloud native projects That actually leverage web assembly. Um, and it's interesting, uh, because You would think that with containerization. We've sort of reached Um, the pinnacle of all abstraction, right? Uh, But it's not the case. Uh, because you still have that um Very last layer of abstraction in the form of maybe your application libraries Um or code, you know language specific libraries that need to be included for your code to run in every execution environment Um imagine that level being taken away as well Imagine that, you know, you have an environment Um, you have a container or or and it's very much possible because there is a lot of good work being done. Um, So imagine that last layer of abstraction also Uh, you know being added to your workloads. You can possibly Um, you know run your code anywhere write it once and run anywhere was like where we started off with this whole java and all of the other things, right? Um, web assembly is the hope that it's actually going to happen and uh with you know more and more cloud natus projects, um adopting it and adopting uh, you know, or extending support for web assembly more languages actually, um, you know, uh extending support for the web assembly framework I think we are going to reach there. It might take more convoluted approach because um, it's Like there is like a lot of work to be done still. Um, it's not just, you know Um that easy to like overhaul an entire system that's been built For maybe I don't know as long as I've been alive. So It's not it's not as easy. But um, I think we are getting there. We are, you know, um going to run Write once run anywhere approach. We are also, you know, um Going, uh, we are also as an industry moving towards the edge, right? Like we want Stuff to work on edge. We want, um, our Compute closer to storage. We want our workloads to run on multiple cpu architectures. We want all of that And with web assembly that's that's going to be more, you know, easier to achieve Because like I said, it introduces that last level of abstraction that we've not had with containers so far So I hope that answers your question because I've like went into like a side of things I was gonna comment It's interesting you brought up java because I was thinking while you were talking about it. It's like, uh, You know javascript was named javascript based on the popularity of java. Yeah Yeah And in so many ways it was a mistake, right? Because yeah, you know javascript and java have very little to do with each other It's not only Yeah, not only kind of in syntax, but also like in like just like in usage, you know style And web assembly, I wonder if it's suffering kind of from the same thing where, you know It sounds a lot as you said, right? It sounds a lot like assembler, right? And you know, and I know I don't like you But I don't want to do assembler. Um, and so, you know, it's uh, it kind of has this, uh, challenge with, you know, kind of While it's technically correct for its name, right? Because I mean it is a compiled, you know, kind of scenario That's kind of happening on the I mean it is a weird concept, but at the same time You know, it does kind of provide that barrier to entry You know kind of alluding back to what we were talking about before I think this is where documentation comes in right in the sense that yeah That's your first foray into that to me to be to understand that Really, it's just a way to run, you know, your blob of code in a more efficient way You don't really actually in a lot of cases need to know that much about how web assembly even works To in order to kind of leverage its feature set Um, the other thing I wanted you to maybe elaborate on a little bit So it's funny. There's the term edge With the, you know, think about it in terms of like a capital E, right? But it's but with web assembly, it's actually both the traditional edge that we've talked about You know for years now with a lower case E and then this kind of capital one, right? So in my mind, we have Applications that are delivered through a browser, right? And where a lot of the functionality takes place on the client side And I think of that as like lower case E, right? But then kind of related to that We're starting this, uh, you know new buzzword You know bingo around the term edge with a capital E Where we mean we want to put it, you know, put our content on servers kind of as close to the end user as possible Yeah, and we see this with like, um Uh, I just blanked on the the term, but I'll use an example like Akamai, you know We see it with companies like Akamai CDNs, um, which is kind of like in the right path But yeah Why does web assembly potentially make both maybe look like I think of it as lower case E and capital E Or or one or the two of them? What are your thoughts there about how particularly with kubernetes? Does web assembly bring some more edge, you know to to that tool chain or to that platform? Right, um Like you know take the smaller case like you said, um For the first example, like I'll explain there and then you want the capital one. So, um, if you talk about like having Applications delivered on the browser, um, web assembly is basically a binary format, which is why the name has assembly in it It's like just a binary code format and uh, essentially it's Just the output of a compiler. So you like you said you don't need to Know how to write assembly Uh to actually learn more about web assembly. So, um, when uh, what in the case of the smaller Uh, you know, non-capitalized edge, um, what happens is that there weren't a lot many programming languages That could be brought to the web. Um, because most of them had to actually traditionally Compiled to javascript since javascript was the de facto programming language and uh, This was getting a little strenuous given, you know, that there were performance issues cropping up with applications. Um, Like, you know that ran heavy workloads. So, uh, for for example, like if you had a Um, and a web app for figmar photoshop or something run, uh, you would notice performance issues and uh, fun fact, they are also I think one of the I wouldn't say first but like one of the few uh, first adopters of web assembly because they have like adobe is one of the Um, you know adopters of web assembly. They have integrated like web assembly into their, uh, products. So, um, they do use web assembly. So it's it's one of those cases where, um, You have a binary code format. Um, That is the output of a compiler. Um, Enabling you to bring more, uh, content onto the web. Uh, in the sense that, um, you just need to write your Own code in whatever language you prefer. Uh, the only caveat is that it the code that you write or the programming language that you write it in has to have, um, A compiler that actually translates it to the web assembly format. So if you do that, uh, you can actually have, um, you know Your code then leveraging the web assembly framework to, um Um, Have this on the web. So, um, that's one thing and when you talk about, uh, the capital edge, uh, you are going to have, uh, number of different architectures that your, uh, devices are running on. It's not going to be like, Hey, I am going to have like the standard architecture that we have here and we could we could probably be running on a raspberry pi or You know, there have been several use cases, not specific to web assembly, of course, but Specific to other workloads that I've heard of in the kubernetes space wherein they're running on like Submarines and rocket ships and stuff like that. So in that case imagine, you know, uh, having to, um, Run all of your code. Um, all of your workloads, uh, and write it in, you know, very specific languages and, you know, having to, um, sort of Take all of that packaging and put it in a device that does not really have, uh, the capability to run that much of, um, code like you do, like the devices are pretty compact. They are, you know, They do not have as much storage and they do not have as much processing capability as a traditional machine would have. Assume that, you know, you're trying to put a large amount of code just or go code or whatever the code that you think of on that device and you end up not being, you end up having to rewrite it for every Specific architecture that you're trying to put it on. Web assembly sort of takes away that as well because it's like portable across architectures, not just languages and with the, like I said with the different, um, uh, you know, language compilers, uh, being supported and, you know, extending their support right now. Um, it's able to actually cover a wide range of applications, although we're not really mature yet. Like, again, we are still very much in the, um, in a very nascent face because there's a lot of, um, you know, capabilities that are not very inbuilt into the whole framework. Uh, for example, if you're talking about assembly or assembly programs or even binary code formats, you are not going to have all the fancies and frills that come with a higher level programming language, like memory allocation. That's the first thing that comes to your mind, right? Like when you talk about a high level programming language like Java, it does all the memory stuff and you don't need to really take care of it unless your app breaks. Uh, so Web assembly does not have that. It does not have like a lot of, you know, networking capabilities. Uh, it's sandbox. So there are specifications that are being built and developed. Uh, like there's the WASI spec, there's the, um, WAUGI spec. Uh, there's the WAPC spec. So there are different protocols. There are different frameworks that are being built as an ecosystem to support, um, Web assembly and to, you know, let it actually enable people to do what, what we started off with, like write once running the end goal that we want to achieve and of course to help improve that, um, developer experience altogether. Like you do not need to worry about what language you're using and what architecture you're running on. You just need to write it in a language that's comfortable to you and eventually we probably will have a compiler that supports it. Yeah. So, so before we move on from there, I just wanted to say, I mean, this is the KBE insider show, right? So as you were kind of saying, as Web assembly is kind of nascent, um, you know, both in, in what it can do as well as in adoption. Think out a year from now. Um, you know, uh, let's not talk too much further than that just because then we get into science fiction. But, you know, maybe a year from now, maybe it's a little bit longer. Who knows, but what, what do you think is going to change about like, uh, kind of working with Kubernetes and working in, and kind of the Kubernetes ecosystem? Assuming that everything goes awesomely for Web assembly, you know, gets adopted, you know, that, you know, heavily in the technology gets more robust, et cetera. Uh, what is, you see that changing about Kubernetes over the next year? So, uh, there are a lot of projects that I've just recently started, you know, um, announcing their support in the cloud native space for Web assembly as well, like OPA gatekeeper, which is like the Kubernetes, uh, which is like a toolies. It, it's not recent in the sense like recent, but fairly recent. Uh, it announced support for Web assembly. I actually, um, you know, sort of see, um, more and more projects going down this line. Um, and, uh, I also remember this one announcement tweet from Ralph, uh, just a second if I can actually put the link to that sure. Um, it would be great. Uh, but I would like to actually even say that, um, that that was a very big, you know, step forward in terms of, um, where we are with Web assembly in the cloud native ecosystem. And it was such a cool thing, uh, that I even retweeted it, uh, just a second though. Um, but, uh, coming back to the question, um, I think that with, um, it's basically going to have, like, projects are going to basically start supporting, um, you know, Web assembly, um, within the cloud native ecosystem. So the one that I was talking about is here. It was just on December 2nd. So I'll just paste the link here and that's this one. So, uh, the, uh, the container shim for, uh, run was he was sort of, uh, accepted as an upstream, uh, project supporting Web assembly in the CNC. That was announced last week. So I think this is one, like, uh, pre-desk, not pre-desk, sir. Maybe it's a sign of good things to come is what I could say. That's really awesome. Like I have been putting off learning and I know like, um, was some is like up and coming. And I, I have seen the, we are co-chair, the, um, was some cloud native conco-located event. Um, I totally forgot the name, but I think it's really to watch them and it's a co-located event. So like, I am going to make it a point in this, um, day of learning. So Red Hat has this day of learning every quarter. So probably this time I'm going to dedicate that to was some so that, you know, I can learn a little bit more about it. Um, and, um, to take a slight detour from the, uh, Web assembly, I want to like talk a little bit more about, um, the KCNA exam. So you were involved, you were one of the co-creators of the exam and can you talk a little bit more about it and like, who, who is eligible to take it? Or like, we have to have experience in the cloud native field, um, to even attempt the exam. And, um, once you have gotten that certification, what does it mean? Like for the person who has obtained it, um, um, and also like from perspective of their career growth. So do like, how can they use it? Can you talk a little bit more about that? Yeah. So, uh, the main reason why I actually got involved in the whole exam process, to be honest, uh, it was an honor. That's one thing. But one of the main reasons why I got involved was like, this is an exam that I wish I had when I started out. Um, it's something that I always try to do, uh, wherever I go, that I try to be the person that I wanted when I started off. Um, because, uh, when at least I started off, uh, there weren't a lot of, uh, signposts. I mean, there were, but there were in a lot of signposts around how to get started with the cloud native ecosystem. And even if I did have that signpost, um, I did not know how to go from, say, point A to point B. The only available certifications were like really intimidating. It was CKACKAD and the year that I joined, they introduced CKS. I was like, I do not know a thing about, uh, the Kubernetes or the cloud native ecosystem. And suddenly, uh, here I am trying to, you know, learn something for CK. Fun fact, I have still not taken a CK exam because I keep postponing it and now it's expired. But, um, the whole thing is that I was very intimidated to take this exam in the very first year. And, uh, when the opportunity came up, uh, on my radar to help design or help create questions and review questions for this exam, um, I just jumped at it. So it's an extremely basic level. It requires extremely basic level knowledge of the Kubernetes and the cloud native ecosystem. So when you enter an ecosystem, it does not need to be, you know, Kubernetes and cloud native. Even when you, um, say, switch from your or schooling to your college or from college to say a job, um, there is a different vocabulary used everywhere. You do not use the same vocabulary. So, um, I remember when I switched from, you know, college to, uh, actually, uh, my first job, uh, I used to call people sir and ma'am because that's, that's how we refer to people, um, in academia. You call them, you give them respect. And that was the first thing that was told to me in my office that, you know, you don't refer to it. So that, that's just a very basic example, but there was so many other differences. And when you come into the cloud native ecosystem and when you come into the Kubernetes ecosystem, it's going to go far beyond, you know, not just calling people sir and ma'am. It's going to, um, you know, entail an understanding of what Kubernetes is. And once you learn about Kubernetes and it's, I do not know how many concepts have lost track of the concepts page, but the number of concepts that it has, if you ever get to the end of those, you have another ecosystem to learn that surrounds it. Like you have stuff like Helm, you have things around, um, Grafana, Prometheus, Prometheus has its own exam now. So I mean, you have like things related to the cloud native ecosystem that you need to learn more of. And should you wish to get involved, you need to know the terminologies associated with the ecosystem as well. Like you need to know what is a SIG, what is a TAG, what is like, how is the CN, like, you know, how is the CNCF actually, um, you know, how, how do the projects work, how, what is the code of conduct, stuff like that. Like you do not know all of this right off the bat when you come into an ecosystem. And you do not know if you know everything without actually getting tested. Because if you do not, you know, assess yourself in some form or the other, you're not going to understand where you stand among your peers. And this is where I think the KCNA comes in. And it's a brilliant, brilliant exam, not just because, you know, I helped in the co-creation, but I think it's something that is required, like a basic entry level exam to test your knowledge, because who, who will, if you build stuff without, you know, having firm foundations, if you just run into some, something like I did, it's going to take you far longer to understand everything. Like you cannot start, you know, randomly putting puzzle pieces without seeing where they fit. You have to ensure that, you know, things fit in a particular order. So if I start learning Kubernetes without knowing, say, where it came from, and if I directly start, you know, learning Kubernetes, maybe security without understanding even the basics of security, it's not going to make sense. So you need that basic and basic level knowledge. And within this ecosystem, this is the best way to actually test that knowledge. And that's, that's what I think is, you know, my definition of the exam and literally anybody can take it if, you know, they want to test themselves on the foundational knowledge that they have gained with maybe work experience or with maybe, you know, just contributing or even just tinkering on their local laptop. It's meant to, it's meant to not, you know, demotivate you, it's meant to sort of test your knowledge. And if, you know, should you pass and should you clear, which it's not that difficult, you will be able to move on and, you know, learn more about a specific project or specific set of projects. If you are looking to, you know, diversify more into the administrative side of Kubernetes, you could go to CKA. But that's, again, I'm going to tell you that that's a very steep curve to take, because CKA is going to be very, very operations focused coming from a very, and I come from a very operations side of things. So I know that it's going to be a lot operations focused. And you have the CKAD, which is developer focused, and you have CKS, which has like more security focused stuff. So taking the CKCNA is like the very first step, then you need to like dive in, dive deeper and figure out what is the specialization that you want to do. Or if you don't even want to do like Kubernetes, now we have PC, which is the Prometheus certified associate. But again, that's an entry like the Prometheus side of things. So you can choose these things. Yeah. I was going to say, I think you bring up a really good point is like one of the kind of, whether you feel like you need an exam or a certification or whatever to, you know, decorate your LinkedIn profile or whatever, one of the things that's super nice about exams is that, you know, some experts have said, hey, if you know all of these things, you've got a pretty good coverage of kind of the space of knowledge. And so it can be a really good way to just kind of guide how you learn, you know, to kind of say, okay, well, these are the topics covered, so maybe I should go kind of learn those together. And if I can then pass the exam, that means I probably have a pretty good idea of what the space. And I think, you know, so I know for me, I've never been much for kind of like the certifications and exams. I know a lot of people who are, they really like that checkbox, they really like that, you know, badge or whatever. Whereas, but what I have used them for, which I think is super useful, is like I said, it's kind of, there's an expert who said, hey, here's how you get a well-rounded view of the space, right? And kind of, you know, some guidance of where to start, which can be super helpful. Because it can be kind of, you know, some people might find it mildly overwhelming, the thousands of pages of documentation, and, you know, all the different glossary items and everything else that you have to learn. I just wanted to point out, we did actually write a blog post about the QBuy Exam, on QBuy Example, about the exam, and also your co-creator, Katie, and the interview we did with her in Detroit, which will use, sorry, Savita, did you want to talk some more about the exam at all, or do you, I was going to use it as a segue? No, I was, I could relate to one thing, not much, I don't want to add much, but I just have one thing to say that I did take the KCA, and it was not, it was overwhelming, to be honest, so I wish I had something like a KCNA to dip my toes in the water and check, like, oh, do I want to do further in this thing? And they want to, like, not do, it would have been, like, amazing. So kudos to, kudos for creating such an awesome course. And thank you, I don't have any, any more thing to add on that question, so back to you, Langdon. Yeah, we should, like, pass the mic around, we could do it, like, through the camera view. But, yeah, so the segue, of course, was, as Savita knows, and Divya, I think you, did I meet you at QCon? I think we met in, kind of, passing while I was walking down a hallway. Yeah, we were, we were running across each other in the hallway, like, and it was not in slow motion, so we were basically running in opposite directions. It's more the, I don't remember where I was a lot of the time, you know, so I used to joke about when I was traveling a lot, you know, I would get off the plane and have to, like, look at the airport to remember what place I had gone to. But what I was gonna say is, you saw the car, and some other people have seen the car, but one of the things we did at QCon was we, basically, I took various people around on car rides and interviewed them, kind of like this show, except much shorter, and we were in a cool Ford Mach-E car. Yeah, I did see that. So the reason I was bringing up the segue is because I interviewed Katie and there's a link to that, to the interview in the car or whatever. And so those have been dropping, basically, since QCon every so often, like, once a week or something, but they're all on the QBike example site now. And I think they're hilarious. Like, to be honest, I can't believe how well it came off, you know, like, I thought it was really good. Like, I think you felt the same. It was wonderful, because two reasons. I didn't have to drive. I got to talk, and I got to, like, be in, like, the, I did not know anything about the Mach-E before I even, like, got into it. And then I learned a lot about it. And I'm like, Oh, wow. Then it was a cool car, you know, like, I felt like a cool kid all of a sudden, getting into the car. And it was so much fun. And I want to explore one new place called Bell Isle, thanks Langdon. And thanks for not taking me to Canada. So yes, we got to talk about conveyor and community, Kubernetes community and, like, how things are, the community is community involvement is, like, kind of, like, transferable. And what keeps things going. Yeah, it was so much fun. And other than that, I also want to mention that the blog is out today. So please, I think it came out yesterday. So please, if you're interested in seeing my video and many others video too, it's all available in the KBE website. And just to clarify, I like Canada. I would love to go to Canada. But when we're driving on that route in Detroit, it's very easy to get trapped in the Canada, you know, lane. And, you know, we didn't all have passports. We didn't all have, you know, the ability to go into the country, you know, et cetera, et cetera. So we were concerned about, you know, our relationship with customs more than we were worried about our passport control. Exactly. Because we disliked Canada. Oh, sorry. It might have come off like that. Thank you for bringing that up. I really want to visit. Is that I, if I had crossed the border, it would have made me illegal to come back. So yeah, so we had a lot of good reasons for not crossing the border. However, it was no knock on Canada as much as the international part. No shade. But, you know, so yeah, and we just posted links to all the videos and they're up and, you know, go check them out. They were pretty entertaining. Divya, I wanted to give you the chance. Do you have any other things you wanted to add about what you're kind of seeing in the next, you know, what you're, you know, what you're interested in? You know, what else is there besides WebAssembly that you're finding really particularly interesting? I think the temptation is all the things, but, you know, is there anything specific that you would like to highlight? Yeah, I mean, that's a very wrong question to ask me because I'm like, Savita knows this very well. I basically just like go behind every new thing that comes. And I'm like, we gave, we even gave a talk about it at the KubeCon here in Valencia where, you know, I just dabble in way too many things at Bara really quickly. So, but that being said, one of the, one interesting thing that I'm actually more interest, you know, I'm very focused on right now is to look at various multi-tenancy solutions. And I'm very interested in that space because like it or not, nobody is actually going to, you know, want to stay locked down to one provider or, you know, have like a single cloud provider taking care of all of their, you know, needs because it's either going to be a hybrid implementation or it's going to have like spread out a spread of various cloud providers. So, it's one thing that is very interesting to me because there are a lot of challenges that come associated with that implementation when it comes to Kubernetes specifically. So, scaling and, you know, all the other problems that come along with it are very interesting to me because I was one of the administrators in my previous company for the Kubernetes team. So, that's one thing that I realized is like a challenge and it's one thing that I'm interested in. Another thing like I think is very interesting is maybe for me specifically would be how we manage to actually, when we do this multi-tenancy thing, how we manage to also implement all the fills and fancies that are associated with a normal traditional setup, like scaling out your observability setup, scaling out your, all everything basically, scaling out your security, ensuring that the same level of security is maintained in, you know, multi-tenant setup. So, a lot to do with multi-tenancy but also interested in how it all scales out to actually deliver the same level of service that it does now. But primarily, yeah, just multi-tenancy would be the first thing that I'd say because everything else comes as an after effect, I think, because everything else is like on top of that for me. Yeah, multi-tenancy in basically every scenario terrifies me. You know, it's always, it's always like massive wrinkle of like every system, especially when, you know, it's not built, kind of built in at the beginning. But any which way, it's still like one of those places where there's just so many potential gaps. Yeah. So, I think we should probably wrap it up here. We're about at the top of the hour and, you know, I would say thanks, Divya, so much for being on the show. We really appreciate it and, you know, hope to have you back. Maybe we will interview you in a car in the next, the next time we do a series. We do have grand plans for Amsterdam for doing something. We don't know what yet, exactly. Is it going to be on the canal? Yeah, exactly. Exactly. Maybe, you know, a submarine or something. Who knows. That would be cool. Sunita, did you have any other closing remarks? No. Thank you, Divya, again for coming on the show and the submarine would be so cool. Not so cool for my phobia, but it would be like super cool, you know. Yeah, I'm just giving, I'm just throwing out crazy ideas to, I don't know, will it be a letdown if we deliver on something reasonable or will it be, you know, oh, thank God they didn't do something terribly. We'll see how it goes. All right, thanks again. Thank you so much for having me.