 Gentlemen, how are you? Hey, good. Hey, I didn't I just saw the annual review pop-up Yep, and but I didn't get a chance to Look through it. So Feedback would be super welcome there. It's it's always nice to go back over the year and realize just how much we've accomplished I really you know, it's the natural human thing you focus on the problems at hand And it's very productive most of the time, but it means that you're just focused on Okay, what is it that I have to get done that I haven't been the net you lose track of all the stuff you have done Yeah, yeah, yeah, you lose the perspective Yeah as a side note as we wait for people to join I'll say that I Consider much like a power presentation like a PowerPoint presentation where people will where it's like Easily possible to overuse animation and have it be distracting that The same as I think true of One of the calls that I was on yesterday where Where another Docker captain had a top gun playing as a video in the background of their zoom and and We didn't want the meeting then because we wanted to you know, finish the movie but It's just I think it was overdone is the point and then but anyway the So hopefully for the folks representing kuma today. Yeah, there it is. Okay, Nicola beat it to beat me to it then before I could even Alright representing very good cool All right fair enough. We are a couple minutes after I anticipate we'll have a few other folks joining I Invited a few folks that might That might be interested in today's topics Couple of housekeeping items. So one is that this is a CNCF SIG network call and so we meet about twice a month As such we the meetings are recorded in publicly posted. So Use swear words as you will on that hopefully everyone has a Link to today's meeting minutes. I'll post those in the chat I'm in general just a cup for some of us that are either new or haven't been here before I'll go ahead and share those minutes, but I'll also say a couple of other housekeeping things which is and that is oh The way we are I've generally been able to keep a cadence of about two topics a meeting That's I think we could squeeze in more Into the meeting time, although I don't know that us as a SIG could necessarily digest more And so in some respects think today we're fortunate that ambassador that that's coming up for review soon But they won't present today, but next time we meet I anticipate that Meshory will also be presented probably the next time that we meet so So I have a full agenda for the fourth Getting into the agenda then and off of housekeeping items Last time we met one of the topics was the discussion around the formation of the service mesh performance working group and so The presentation that we covered last time is available and this is an open call for Those that might be on this call or others that you might know of that would be interested in that working group to To jump on in will be identifying a routine meeting time soon Would you consider presenting this the SMI calls? I think that next week there is some call for the SMI group. So Yeah, that's a good thing to mention that there's Folks that are clearly interested in service mesh is there so they might be yeah Yeah Next item was is that chaos mesh has been presented Little over a month ago. I think here for consideration into the sandbox and so Their review is in flight and I We've spent a healthy amount of time with Well with that whole team actually not not not everyone but but all of the most of the maintainers and so My hope is is that we'll have this review done this week for chaos mesh That's a timely review in that litmus. We've also spent a lot of time with litmus chaos Even though they're not being reviewed in this thing that group that community is just Spending a lot of time over Over here as well. And so in a very good way. We've got there's a lot of chaotic things happening Obviously the term mesh is already very overloaded like too many things are claiming to be It's gotten quite mushy I'm in good company. This is good And then Just as we welcome in Well, so Nikolai's been here for some time But some others that are on the call for the first time. So Marco good to have you and Then if you haven't put your name down feel free to record your attendance but other than that we've got a fair bit of time on today's agenda for kuma and I'm gonna stop sharing so so that you guys can Introduce us to the project and Tell us what it's all about. Yes. Thank you. Lee. My name is Marco. I'm the CTO and co-founder of cong I am going to be doing these presentation today. How much time do I have? Let's say over 30 minutes like we there was to be two presentations today and it's cut down to one So we'll we'll have ample ample time Okay, so I'm going to be sharing my screen right now. Can you see it? It's there Yeah So I'm presenting kuma today as part of the Donation proposal as a CNCF sandbox project that I've started a month ago So this is the issue for three seven on the CNCF repository This is the PR. I'm sorry and this is the issue for three six As a matter of fact, you can also find a link to the presentation that I'm going to be presenting now on These issue as well You know when we look at at the industry we look at the CNCF landscape today There is No control plane built on top of envoy that supports on boy as a data plane proxy That's open. That's vendor neutral that the rest of the community can use In them, you know from CNCF There are some there is another project That is graduated or incubated linker D. It's not built on top of on boy I'm boy It is really, you know in the industry is being adopted as the data plane of the future And today if somebody wants to leverage on boy They either build the drone control plane or they go use another control plane that supports on boy And like I said today in the CNCF landscape, there is no vendor neutral donated control plane That the community can go to in order to do that So we built kuma and we wanted to donate kuma as a sandbox sandbox project With this goal in mind giving everybody the best control plane out there built on top of on boy And also integrating with the rest of this CNCF landscape in order to allow everybody to simply Implement mesh across pretty much any architecture. So what is kuma? kuma is a service mesh built In going on top of on boy has been released in September 10 2019 by Kong I has We think we're like about 1500 stars on Github. It's an Apache license 2.0 project Kuma it's a very simple project. It supports on boy. It implements the XDS API of on boy And it supports night on boy out of the box. It is one executable So developers or architects who want to create a service mesh They will start this one executable that is the kuma control plane and then they can go ahead and Then start the data planes and the data planes will connect with kuma and then from there on kuma is going to be controlling those data planes It's written in goal and it provides a native on boy integration and really has been built with extensibility in mind kuma has Came out of Kong with with the learnings that we have captured from the users and the customers even That that Kong is working with in pretty much every industry technology financial industry health care and so on and so forth It is it was clear from the service mesh landscape Back when kuma was released that there were some some missing aspects that today were not taking care of by any other service Mesh out there. So first of all for many organization service mesh. It is a journey Organizations are working towards transitioning existing workloads to Kubernetes. So there is this transformation to Kubernetes That's happening and at the same time as they do that and as they increase the service connectivity among their services They want to be able to take control of that connectivity right abstract that away from the Application teams so they can manage it from a central place Kuma has been built to support this transition So kuma does not support just Kubernetes, but kuma is a project that supports any Architecture and any platform it can run on virtual machines and it can support a virtual machine based workloads as well as it can support Kubernetes based workloads. That's why we call it universal It can support the organization as they're making this transition to Kubernetes into containers and in a way it simplifies that transition as well if we can abstract away connectivity from Brownfield applications that we want to transform into Kubernetes applications We're reducing the scope of that transition in the first place because we don't have to manage that connectivity anymore And so once we do that effectively kuma wants to enable an easier migration to Kubernetes It's easy to use service mesh for many users out there has been a very complicated topic Service meshes are hard to deploy they're hard to use they're hard to extend but it doesn't have to be that way So we wanted first and foremost to create something that would that was easy to use Something that was lightweight something that was extensible something that didn't have many moving parts So it would be easy to deploy and something that would provide out of the box hooks to allow users to utilize the product The project in different ways. We are obviously Kubernetes CRDs To change the state on Kubernetes based deployments as well as providing an HTTP API out of the box providing a CLI Out of the box as well as providing a GUI out of the box into the project Kuma has been built to be simple has been built to be scalable We're working with different kind of users. What we've learned is that especially in a large organization Service mesh doesn't just happen out of the box It like I said, it's a transition and different teams are going to be moving to Service mesh at different times depending on their specific goals and roadmaps at the time. And so One very common way to support the entire Organization and all the different lines of businesses and all the different teams that are building these apps It is to create different meshes so that each team can provide a mesh for their own application And they can each mesh comes with its own dynamic certificate authority But effectively these different teams do not have to coordinate together Within the same mesh in order to adopt mesh now because this is a single control plane that can start as many meshes as we want Kuma is multi-tenant in this case From one control plane we can provision as many meshes as we want We can create these connectivity obstruction layer that can cross boundaries can cross platforms can cross even Kubernetes namespaces And then it's up to the architect or to whoever is managing kuma to determine if they want to merge Different meshes together if it makes sense or if they want to keep them separate financial users in the financial industry That we are you know that are using kuma They really like the idea that if they want to they have these additional layer of separation Between different teams and different applications some others instead They prefer to have a very large mesh and everything is being deployed within one mesh. The point is that kuma Supports both so users who want to support Kubernetes They can do that who want to support the virtual machines as part of that transition to Kubernetes They can do that they want to create one mesh. They can do that They want to create multiple meshes. They still can do that In this in this case kuma is a very pragmatic service mesh It and by the way kuma as a project itself, you know, Kong is not a cult vendor The company that built kuma Did not have any agenda other than trying to build the best control plane for service mesh out there We don't build this to transition anybody to the cloud We're not doing this because there is some other hidden agenda into Kong is the Switzerland of connectivity tuition We work closely with all the clouds all the platforms So we don't have any other agenda other than creating the best product out there and really you can you can see this Passion and in this goal within kuma and the way kuma has been built So it's easy to use. It's simple. We provide policies out of the box We're going to be releasing Documentation right now, you know kuma is a non-mindsoul project But we want to create documentation to make it even easier to create new policies On top of kuma by perhaps supporting web assembly It's horizontally scalable. There is only one moving part. It's multi-tent We can create as many meshes as we want runs on kubernetes runs on virtual machines runs across pretty much every cloud It's easy to use it provides native CRDs that allow anybody to follow kubernetes best practices If you if they want to configure their mesh Policies can do pretty much anything policies can be can be doing traffic control fault injections traffic routing mutual TLS mutual TLS comes in different Forms in different flavors kuma supports a built-in Certificate authority so we out to generate out of the box the certificates and the keys for the CA root Backend and then we out to generate a certificate for each data plan proxy We implement out of the box things like certificate rotation and of course all of this is configurable So the user can configure what certificate authority back-end they want to use they can also provide their own root Certificate and key and we built this entire system in such a way that it can be extended So the by default the certificates that we create are specifically compatible But because these back-end system is extensible as part of the roadmap We would like to support for example spire as one of the CA back-ends that the users can use It provides a CLI that simplifies retrieving the state of the resources stored in kuma It provides an HTTP API that can be hooked with pretty much anything in the GUI itself is actually built on top of the HTTP API So anything that the CLI can do that the API can do that the GUI can do can also be done You know can also be automated by hooking into the HTTP API We do not allow to change the state of the resources if kuma is running on kubernetes because we want to use kubernetes to do that But if kuma runs on virtual machines, then the API the CLI can also be used to change and apply state changes on top of kuma Like I said kuma abstracts away Unvoy actually So if we want to start using kuma, we don't need to have any prior experience on unvoy under the hood There is going to be an unvoy proxy running but we Bundle unvoy into this kuma dp process that automatically does the initial bootstrap a Configuration provisioning so if if somebody wants to use kuma Under the hood they're going to be using unvoy, but they know if they don't look into kuma dp They they wouldn't know This makes unvoy easier to deploy and easier to configure Because they don't need to know what unvoy is or how to configure unvoy in the first place But if they want to go ahead and configure the low-level unvoy configuration They can still do that we provide a proxy template policy where the user can effectively Configure the unvoy configuration for different services Via kuma so kuma first and foremost is a control plane for unvoy But then kuma also provides policies that abstract away the most common features that unvoy provides into easy to use Policies for for the user It supports CNI of course because we want to be able to deploy kuma on Open shift 3.x 4.x it supports kubernetes. We have About nine different distributions that we generate for the community We do also by the way Work with the community. We have by weekly community calls kuma is an open governance project By weekly community calls where we gather their feedback And and we collect input from the community. We also have a slack channel and a development channel That the community can contribute to Yeah question if I might and it might just be Semantics or the way that I think of a distribution the the different distributions You know put out to support those different platforms is What are the primary differences between the distributions? We we make it easier. So basically kuma on kubernetes would Use the kuma docker container obviously in order to be able to provision everything But if you would like to run this on let's say red hat I'm sorry debian You would then start the goal and project Without necessarily having to use a container. So if I go You know the best way to to look into this if I go on the website kuma.io And then you know, we can click on the installation page We see that on kubernetes We provide so first and foremost on kubernetes. We provide an automatic installer that would install kuma and then If you decided to use for example amazon linux, uh, we would provide The automatic installer would automatically detect that the underlying operating system And it would install the kuma cp binary executable on top of that virtual machine So the difference is that with kubernetes we we just abstract away the entire installation process installing kuma is as easy as running kuma cattle install kuma cattle install Control plane and then this would generate a yaml file that we can apply on kubernetes Whereas if you're running this somewhere else you would get an executable then then you have to run Got it. Okay But the project and the binary is the same so what Although we make it easier to install kuma across these different distributions It's not like there are different flavors of kuma itself. That's always the same flavor. So basically every time we release the new version we generate Installation instructions for the new version across all of these different distributions But the the binary if you look into the kubernetes container Or if you look into the amazon linux the binary is always be it's always the same That's nice. Oh very good. Yeah. I think that the reason I was asking is it's I think that those two concepts flavors and distributions are often conflated and so Yeah, was it in fact a different capability or but yeah, it's about It's about installation and kind of fitting into the environment not Yeah Yeah, um with open shift for example, uh, we we suggest using cni, right? So basically we um, you know effectively each one of these distributions um Are distributions of the same project but with instructions that are catered to the specific environment where the user wants to that the user wants to use Um, you know kuma, you know, obviously with service mesh There is some very common requirements when it comes to managing that service connectivity Um, one of them it's obviously being able to collect metrics another one It's being able to implement mutual tls and then another one. It's being able to You know Fetch tracing logs from all the service to service traffic that we are generating Because kuma wants to make this very simple for the user Uh, we implement also some shortcuts that allow us to install primitives and grafana In order to automatically out of the box capture those metrics. They also implement We implement a helper for installing yeager so that we can collect tracing, you know We we want to really make the entire service mesh experience Extremely easy in order to be able to cater to a largest number a larger audience when it comes to adopting service mesh Simplicity is a feature This is a simple example of a Kubernetes policy. So if I go back on the website By the way, and I go on policies we can see that there are some policies You know, we generate new policies every time but some of these policies, for example, like traffic route can be implemented on kubernetes by using this very simple configuration. So in this example Every request made by the backend service to the redis service goes, um some of that traffic goes to redis to the redis service 5 5.0 and um Some other part of the traffic goes to service redis 6.0 Now the cool thing is we can tag our services with any arbitrary tag. So which means that We can assign A cloud region to a tag. We can implement routing across different clouds across different cloud regions. We do cross data center Routing we can do all sorts of things with these tags tags allow us to regardless of what's the underlying complexity of our workloads And where they're running with tags we can we can Apply policies in a very flexible way across the entire mesh. They're very powerful And if we're running a universal Because we want to you know implement a service mesh on top of systems other than kubernetes Because perhaps we want to integrate this with an existing mesh running on kubernetes We do provide kuma running as an Individual executable of course on kubernetes. We can leverage the underlying kubernetes api Um an hcd to store all of our configuration But on virtual machines. We cannot make that assumption. Therefore. We have support for postgres so Uh, if somebody wants to run kuma Um on virtual machine workloads, they can use postgres as the underlying storage for their For their configuration And and the policies are very simple as a matter of fact One of the goals here is to make sure that we make it easier for teams that are not familiar with kubernetes To get up and running with service mesh with something that it's very similar to kubernetes, but not quite there yet But it exposes them to the same concepts and then as you can see This is the universal policy example that does the same thing that i've demonstrated before with kubernetes It's quite simple and quite similar So the idea is that the teams that are transitioning or planning to transition to kubernetes They can start abstracting away their connectivity by using something that really looks a lot like kubernetes But it's not quite kubernetes. So doesn't doesn't scare them away But makes their transition to kubernetes much easier once they want to do that kuma, uh, is open it's community friendly We have released an open governance, which I believe Makes kuma the only control plane built on top of anvoi with open governance right now in the market in the entire community landscape We provide bi-weekly we set up a bi-weekly community calls the next one. It's next week Where we discuss with the community We're gonna list of agenda topics that you usually discuss, but you know, it's roadmap or particular spikes or architectural conversations and so on And and this is the first envoy based control plane that is being donated For service mesh that is being donated To to cncf as far as I know The velocity of the project. It's quite high. We're making Releases pretty much every month or almost every month We want to keep iterating on introducing more kuma policies to make an envoy easier to use We want to be exposing those envoy features Via native kuma policies One of the most requested features right now is to support smi integration So this is something that I would like to explore perhaps with the smi team the microsoft team um In the maintainers of smi Introducing support for web assembly, which as you know Envoy already supports as well as pluggable mkls backends We've built that the gooey wizards to get up and running with the gooey. We built that, you know, and so on and so forth Today kuma is being used by A series of users across the board We're using kuma is being used by For example companies like sabre Enterprise companies like sabre financial institutions in new york government agencies financial companies in europe In uk as well as I know there is many projects led by tau works and the companies like we pro Around kuma and those guys are active in our slack channel and um and community channels as well So this is a presentation to donate kuma Which is the first envoy based control playing to be donated to the community to advance the adoption of service mesh and envoy kuma supports and enables those cloud nation technologies and best practices We want to enable the adoption of kubernetes across the board And we want to be able to make that transition as easy as possible for those users or organizations That are transitioning to kubernetes, but they're not there yet. It's a journey So how can we enable that journey and make it easier for them to to do that journey? um, like I said, uh, we built kuma with no other agenda and no other plan other than uh Building the best control playing for service mesh out there. I mean, uh, if we look at the features and the roadmap It's entirely focused on advancing service mesh on advancing at the adoption of envoy and also advancing the adoption of the integrations that we natively provide With kuma that includes permit use that includes jager We integrate with cni when it comes to open shift and perhaps there is some other some other ones that that we're integrating with when it comes to our policies It has been originally designed by cong cong is a neutral player in um in as you know in the very opinionated cloud landscape. Um, so Like I said, this can be entirely used um on any any platform any architecture with with no Cloud dependency at all whatsoever It can be deployed in in pretty much Any any use case and there is nothing that would prevent any user From from deploying a service mesh that's non-opinionated using kuma in their own environment If you want to learn more, um, we provide the official website at kuma.io The repository is kuma kuma gui kuma website. There is a slack chat that um We provide as well and the twitter kuma mesh at kuma mesh handle is where we announce our releases So we just announced that 0.5. It was quite exciting with 30 more features that the community has been built building And we're going to be planning to release A point one release uh sometime this month. We're going to be discussing this In the community call as well as we planned the next major one to show up sometime in june or july so Nice. Oh very good. Thank you for this marco. This is this is nice. I uh was just uh Trying to pull up the pull request to on some of this because some of some of these questions Answers might be in there, but the Oh, yeah, and it is the current maintainers are uh Yourself ilia jakeb um All three of you are Are at kong or of kong so to speak. Okay Yeah, so we have some other users that have been contributing Um quite actively into the project. Uh, one of them for example comes to tau works and and those users are in the process Uh, there could be potential candidates to be additional maintainers to the project Uh, we have introduced open governance which creates a guideline to become a maintainer Sometime like uh three three weeks ago four weeks ago So open governance is new for kuma, but we did that in preparation for this donation to sandbox So we we just have started and we're willing to accept new contributions and new maintainers and the guidelines are out there Published for everybody to to see Nice, uh, that's good Uh, here's a here's a question. Um, considering the Well, it's just all right. Here's one. You may be fielded in the past, but um, so so envoy, you know, great choice for a proxy Underneath the this control plane kuma um given the experience that you guys have with with the maintainers have with nginx curious as to You know, why not nginx? for the same reason, uh Because we have uh because we have lots of experience with nginx We also know the limitations of the products and we also know what was the intended use of nginx And what is the intended use of envoy and the envoy really provides a nicer dynamic api Which as you know nginx does not provide to be able to dynamically change the state of On on how the proxy is going to be managing those network requests The service requests in in such a way that nginx cannot provide without some very messy reloads You know of the entire process Also, I am A big fan of envoy. Uh, as a matter of fact, one of the sponsors for the kuma donation sandbox is math claim Um, you know, I'm I'm a big fan of envoy. Uh, we have in the past also contributed To envoy upstream envoy. Uh, and we plan to keep doing so when it comes to kuma Um, quite frankly, we want to use the best the best tool for the job and and envoy has lots of momentum right now The kind of policies that he provides and the kind of filters that he provides Are very suitable for the kind of goals that kuma and service mesh in general want to achieve Therefore, it felt like a natural fit very good Our questions from from others on the call By the way, the uh, marco great. I think I said before great presentation. This is this is good at, you know, cool great project too Thank you, lee. Yeah, I love the simplicity Uh, uh, motto and kind of uh, it's pretty pervasive throughout the various things you highlighted in the project, which is Yeah, networking is hard enough And so yeah simplifying always needed Kudos on your new logo as well kind of the the redesign kind of you can see the resemblance between The old one and the new one, but but yeah Yeah, the old one and the old one the old logo was a little bit problematic. Uh, when it came when so the old logo Was created very quickly prior to releasing the project in back in september and it was very problematic to It was very problematic in different ways, but but basically the new one Um, it's more recognizable. Um, and it's smoother and it's nicer and I think it's a better foundation for the long term Plus logos are hard Don't tell me They are uh, I I didn't come up with the logo. Thank thankfully we have, uh You know, somebody has contributed to the design of the logo somebody somebody who's more creative than I am But but this new logo was also created In preparation for the donation, uh to cncf. We did not want So to me it's very important to clarify this point. Um, I don't want to leverage this donation to cncf as um As something that would make the old logo and kong and ink the company more recognizable in the marketplace I wanted to create a distinction a separation between the old and the new And so creating a new logo is Has been has been done also to give a fresher and better look to kuma in preparation for the cncf donation Right. So something that basically breaks any association with the past and projects kuma into the future So one comment I'll make about the logo and Please just take this as a take it or leave it suggestion My experience has been the cncf creative services team is unbelievably good. You literally see the result right behind my head And so not that this is something you do or don't have to do But they are just really really good That said apparently it's particularly stressful for them when you take feedback from 30 or 40 community members at the same time So you might want to rate limit that Yeah, yeah, um, of course, of course, I can help wrangle Um, like the various, uh community feedback pieces around logos as we get there. So Pre continue Yeah as part of the donation, um, you know, I had a chat with chris chris sent me all the documentation and materials. Obviously, we're going to be transferring the trademarks the ip's, you know, all of All of that all that we have to transfer is going to be then part part of Ownership of cncf, right? So including all of these efforts and so on and so forth. So at that point Cncf can do pretty much what they want with it I got Marco that was one of the questions that I had kind of Uh dangling in the back of my mind, but but you you've spoken, I think in part to it and that is I guess maybe to phrase a little bit differently, but just, um of The association to kong and and maybe the the business model around kuma or You know, how does it become a self-sustaining thing? Yeah, so, you know, we we provide like, you know, many many other organizations out there We provide support If enterprise customers wants to deploy kuma wants to run kuma As well as I don't exclude in the future to also have a cloud version of kuma So if if somebody wants to run kuma by themselves the control plane, for example, they can do that If if they would rather have a simpler way to deploy the product the project then perhaps They can go to kong or to quite frankly anybody who decides to create a cloud version of kuma, right? So it can be kong can be something else at that point But we want to first and foremost Enhance and integrate Our you know, our core business is the gateway. It's not kuma. So we want to integrate our our our gateway Project and product into a service mesh that's open. That's neutral. That's easy to use That's agnostic and that's why we have created kuma in the first place and that's why we want to release it We kong Inc the company Doesn't run a service mesh business Runs an api management business that that is our business. So kuma is is something that from a business standpoint provides A vendor neutral integration to to our gateway But the service mesh per se we want it to be neutral We want it to be open and if as a matter of fact we're open to get other maintainers And if anybody wants to be able to offer something on top of kuma Because of it's open and vendor neutral they will certainly be able to do that Nice. Yeah, thanks And because and because I wanted to add just because this is not our business We have also that that's one of the reasons why there is no other agenda with kuma That that you can see in the product or by using the product other than creating a service mesh out there that anybody can use and so That's simple. That's agnostic. That's multi tenant, you know All things that other service meshes out there do not have As well as we're making some significant effort to make sure that we can support more complex network topologies when it comes to deploying kuma across You know, larger and more complex use cases in such a way that existing service meshes out there Including some of the most popular ones cannot support And so we're we're very excited about the roadmap and the things that we're doing and we believe that you know We believe that we we're doing a good job into listening to our users And and and trying to do something that's simple and pragmatic for them, you know Very good. Um questions from from others Marco one of the things that that you'd mentioned a couple of times are our users Curious and the feedback that you're Tuning into and it's helping drive part of the roadmap for the project Um, I guess there's kind of two questions and there are one being That you were speaking you were looting to and kind of speaking to you on one of the last slides part of the intended roadmap and And I thought I'd ask is that uh, is that public as well? I mean it's public in the slides, but I mean is that available some miles? Yeah, so we are making our transitioning everything to github, uh, including, um github as a feature like trello, um, you know Um It's called projects. So obviously we're transitioning everything there and if if you go on the github everything is public everything is, uh, available on the repository as well as We discussed roadmap items Two times a month in the barbecue community calls So, uh, there is also slack chat chat channel on akuma called development where, uh folks can suggest or talk about roadmap items that they want to work on so Um, everything it's quite open and it's out there Nice nice very good. I see the project boards now Yeah, yeah, so we we started we started with that effort of course is you know, there's Lots of work to do and it can always be better, right? But um But that's but that's exactly the goal. But you guys should uh, yeah, just in many different respects. Um Moving right along briskly or just you know, good-looking Healthy a healthy shape to the project. I guess is what I would say the uh other part of the question that I didn't ask was about users and Uh, you guys, you know the project tuning into their feedback curious. Um, you mentioned Thoughtworks or a couple of other um any I guess the the question I'm trying to ask is Uh What have you you know, what are some of those things that you learned from your kuma users and nor are there any Kind of can references to adopters today um, this isn't some of the by the way marco some of the questions that I'm Uh, tossing toward for you and toward the other maintainers are not necessarily strict criteria for the sandbox. These are just You know general questions Yeah, but those are very good questions. I mean the the uh idea That we have uh, you know of kuma in cncf. It's not of a project that stops at sandbox That keeps going growing from there. So, um, as in my slides, you can imagine, uh, so I Presented my slides and you know, obviously there is a quote from tell us, uh, which is the largest telecommunication company In in canada. We are also working on a community use case uh with an enterprise Ticketing company that's been using kuma to fundamentally transform how they're transitioning to microservices and kubernetes and we are actually um Going to be releasing that a community case study On the website. So we're you know, for some of for some of these Case studies, uh, we have to ask Approval we can draft them out and then we have to ask approval to their legal team if they want us to publish them If not, we are going to just publish them in an anonymized form. But basically, uh, we're going to be creating more of these case studies So that other users can learn how they are using kuma And and fundamentally, you know, one of the biggest feedbacks that we hear is fine, you know We want to create a service mesh, but service mesh is a pattern. It's not an implementation So why couldn't we implement a service mesh? It can spend across the entire org if we wanted to do so, right? And that's a very valid question It doesn't have to be kubernetes only as a matter of fact There's lots of value in making a service mesh that's as big as it can be Across different lines of businesses or different, you know teams within the organization And as we do that One of the other questions is how do we do that without having to create a hundred clusters of service mesh? But perhaps having everything into into one place If you know if you use other service mesh control planes You have to create a new cluster for each service mesh that you want to support If you want to support different teams or different applications with different service meshes at different times Whereas with kuma we capture that feedback and in kuma we implement multi penance. So we have this concept of a mesh object You can create as many meshes as you want and each one of them has its own certificate authority back end that the user can configure But effectively there being provision Different data plane proxy certificates, which for all intents and purposes makes them become different meshes And the policies that we apply traffic permission traffic routing traffic logging traffic tracing you name it all of those policies can also be applied um Can also be applied on a per mesh basis. So it's it's difficult to understate how important what you just said is um, because what would so many people have missed Not in all kinds of spaces, but this is one is the fact that there is not going to be a single point of administrative control That's that's silly What you're going to have is a whole bunch of points of administrative control That are going to need to be able to operate independent of one another Yeah, in this decision has been made quite early Into the journey of kuma because we didn't have to learn it. We knew that that's exactly what they wanted because they were telling us, you know If you're building a service mesh build it in such a way that the operational cost of supporting the entire org Doesn't it's all of one not all of n the more an n equals the teams or the meshes or the applications that we want to support um Therefore we believe that with kuma we made something that's extremely easy to operate And can scale quite well across pretty much the entire organization. Uh, you know, you know, very nicely way clean way And plus, you know, because everything it's into one at the end of the day All of this is being provided by one cluster of kuma one control plane Then, you know, it also provides this bird's eye view on how many meshes are running in the organization and easy time to Burge some of them, you know, together or, you know, what's the relationship among them? So it also gives a better control on how that segmentation is being applied across the entire org All of this what i'm very excited about all of this is that All of this is being powered by anboy, uh, which is just amazing. So if anything, you know, by allowing to create these meshes allowing to Simplify how all of this is being done We advanced the adoption of anboy across pretty much every every single team every single line of business And that's why i'm very excited to not only work more closely with uh with the anboy community To build things that we need as well as i'm very excited to Uh, I really believe that that anboy is a pretty sweet Technology that uh, you know, uh, it is going to be the data point of the future You know, when we look at the data planes And when we look at anything in life And we ask ourselves Is the best time of these things? Ahead of us or in the past and when I look at anboy the answer to that question is the best times are yet to come Right, and so i'm very excited about anboy and and what and what the anboy community has been building And so with kuma and anboy i want to energize this cooperation To promote a better adoption of anboy across the board Nice, nice, uh comments from others Plus I have to say kuma comes with no drama attached This is a no drama project, uh, and and I know that in our industry We we we have enough of that already like I said, this is vendor neutral There's no other agenda rather than building the best service mesh control plane Out there it supports anboy it comes with no drama there is no There is no strategic plan other than creating the best product product obsession is is One one of the requirements for any maintainer in kuma and demonstrate that product obsession Over time right with with continuous improvements and and contributions. So so so there's no drama. Does that mean you're promising comedy? Excuse me if there's no drama. Does that mean that you're promising comedy? I'm I'm I'm promising a um a very collaborative environment That's that it's it's not driven by anything other than let's let's do something That's nice and that the entire world can use uh very product oriented the product centric. It doesn't hook into Any greater plan But but that I mean it's really that's what it is We're a bunch of people doing something that we like doing working on something that we like working on Uh, and we find we find pride into uh the adoption that anboy has within the community and the user base And we're you know, we we want to keep it that way Yep, yep that kind of uh That kind of thing is hard to quantify although Uh can be extraordinarily apparent in various communities. Um, some of the some of those that were mentioned on this call Fair enough, maybe last call for for comments from others while I Tie off here to say Well, one I guess let me pause and say any other comments from from folks Nikolai Marco, Nikolai, I guess I'm just I'm used to seeing the nsm logo behind your but I'll get I'll adapt So that's so great, uh Thanks a lot for the presentation today guys. We will um Reach reach out and spend a bit more time. We'll do a review and and hopefully um akin to the cadence that we delivered for smi and for chaos mesh also come out with a review of kuma and Yeah, I guess I'd said it before but yeah, what a good looking um project you guys have got thus far, so this is I'm particularly pumped uh personally about it. So Yes, thank you. Lee and thank you everybody. Um, and if anybody wants to join the next community call Uh, Nikolai, I believe that is next Wednesday, right? Yep, it is Is it uh 8 a.m. Pacific? Yeah, so you can get uh more details around that if you go on kuma.io slash community um, if you do that there is a field uh that um, you know, you enter your mail and it will create an event Uh google calendar event that you can then um, you can then save of course and then I hope to see you there nice All right, very good that that was uh, that's the last item on today's agenda. So we'll We'll convene or uh wrap up a little bit early. Um Thank you guys. We'll uh, we'll we'll reach out. We'll we'll have some some more conversations. This is good Thank you Well, bye