 Yes, it's very quiet, Alexis. It's about five minutes past now, so we'll get started. I see Alexis, Joe and Michelle from the TOC if there's someone else I missed. Let me know via text, but we have a full schedule today, so we might as well get started. So we have three project presentations today. So this is our TOC meetings that dedicated to community presentations and hearing from projects out there that have been in the backlog. We have three today. We have NSM, Key Colloke and Strimsy that we'll be presenting. So we'll each give them about 15 minutes to present with some times for questions and then we'll go from there. So without any further wasting time, let's have the NSM community present. I'll hand it off to Ed, I believe. Sure. Do you want to grab the slides or do you want me to... Yeah, Taylor's going for it, so if you feel... I'm finally letting Taylor drive. Awesome. Enjoy. Network service mesh. So Kubernetes networking actually does a fairly brilliant job of optimizing for the average case. It puts the things developers care about front and center in the API, which are things like L3 reachability, network policies for isolation, services to give you some very basic load balancing functionality, and it completely hides most of the implementation details that developers don't care at all about, like interfaces, subnets, et cetera. And this is super well done. Next slide. But it doesn't actually handle every case that people are wanting to do around networking in Kubernetes. So there are a bunch of cases, and the more we dig into it, the more these come up. Cloud native NFV is one, various L2, L3 enterprise that are domain use cases come up a lot, and there's a whole lot of other kinds of things innovation-wise that people are wanting to try that don't fit very well into the standard Kubernetes networking model. And that's fine, actually. Next slide. And so people look at Istio to solve a lot of these things. And Istio is super good if the problems you're looking to solve live at L7, right? If you're dealing with HTTP messages, it's probably the solution you're looking for. That's not what network service mesh does at all. But it's less good for things where your payloads are internet frames, IP packets, or other kinds of things that live below L7. So you can sort of take two approaches to what you're going to do about the unmet use cases. And we've seen both people in the community advocate for both of these approaches. The first on the left is not what we're advocating here with network service mesh. It's sort of the change all the things, right? Keep extending the Kubernetes networking to be all things to all people. Bring in subnets, bring in interfaces, bring in all these concepts that it looks like we've tried very hard to avoid forcing developers to deal with. And then the other approach, and this is sort of the approach on the right that network service mesh has taken, is let's step back and rethink entirely what we're doing. Let's put aside the 1990s networking concepts and ask ourselves what would a more cloud native approach look like? And we took a lot of inspiration from the stuff that was written in the cloud native definition, right? So we had a lot of beautiful infrastructure, loosely coupled, minimal toil. So we started with the presumption that Kubernetes was not going to change for these use cases, which are a small minority of what people want to do. And so we had to figure out what to do with the existing infrastructure to meet those needs. And we have done that. Loosely coupled meaning how do we make it so you don't get one giant glom of networking? Instead you get a loosely coupled system of how your networking works, so that you can compose together the things that you actually want in very much a microservice model. And the third one was minimal toil, which is developers still don't care about subnets, IP addresses, and other minutiae of networking, nor should they ever have to care. And so how do we put the system together in a way that imposes minimal toil on the developers? And the good news is there are excellent patterns to steal from everywhere in Kubernetes on this, and the good news is let them ask for named things with metadata in the form of labels. And so we've absolutely taken that approach. Cool. So human beings tend to think better in stories. And so I will often explain network service mesh in terms of a story, because it gives you a flavor for the kind of thing we're doing. And in this case, the story is Sarah and secure internet connectivity. Next slide. There we go. The protagonist in this story is Sarah. She's running a Kubernetes app to be deployed in the public cloud and one of the pods in her app, not all of them, not the whole cluster, one of the pods in her app needs secure access to her corporate internet. So from her point of view, this is what her problem looks like, right? Next slide. She still wants her normal Kubernetes networking, because that's fricking awesome. But she also, next slide, wants to be able to send and receive traffic to her corporate internet. And she wants to do this securely. For some definition of securely, she doesn't really want to understand the minutia of. In fact, I generally the opinion that for many developers, the definition of security is that which makes InfoSec leave me alone. So we introduced then Ariadne, next slide, the network service mesh spider, who is sort of the mascot for the program. And so talking a little bit about network service mesh, next slide. So you can think of network service mesh as handling things below the sort of L4 through L7 that normally is handled by service mesh and Istio. Instead, it handles payloads that are IP packets or Ethernet frames are possibly more exotic things. Next slide. So again, back to service fundamental problem still wants Kubernetes networking, but also wants to be able to get secure connectivity to corporate internet. Next slide. So in network service mesh, the way you do this is you define a network service. A network service is very analogous to a normal service in Kubernetes. It has a name. It also has a spec which has a payload. This simply tells you the kind of thing that you're getting from your network service in terms of its handling. This could be Ethernet, it could be IP, it could be more exotic things, but effectively it handles the thing that you need to handle. I know Kubernetes tends not to think in terms of L2. And I frankly am deeply pleased by this, but we do have people who occasionally do have use cases that require Ethernet frames to float about. Cool. Again, a lot like service resources in Kubernetes. Next slide. And then the only thing that you would have to do if you're Sarah to get this is deploy something for your VPN gateway and add a single line annotation, naming the network service you want to your pod. Next slide. So conceptually network service mesh has three basic concepts. The first is the network service we've already introduced. This is fundamentally the intersection of connectivity, security, quality of service, whatever it is that you want in the abstract to happen in terms of the service you want from the network. Next slide. And an example here would be secure internet connectivity. Next slide. And the third concept we have is a network service endpoint. This is very analogous to endpoints in Kubernetes. It is the concrete implementation that does the thing that you want. Next slide. Again, like endpoints and Kubernetes. And so in this example of VPN gateway pod, something that would do admission control and do whatever it has to do to talk to your corporate VPN concentrator would be an example of this. This is this L2L3 connection. This will often pop up in Sarah's pod as an interface, but conceptually it's just Sarah's traffic to her corporate internet and it gets there. Next slide. But we all know that things don't say simple. If you started in a world with the VPN gateway pod, eventually your infosec people are going to want you to interpose other things that do, for example, firewall rules based on policy between Sarah's pod and the VPN gateway, or it will inevitably become more complicated. You'll have IDS boxes and IPS boxes and a whole host of other things that people want functionally along this chain. And so network service mesh has the concept of composing these things together. So you can have multiple pods that are offering the same network service secure internet connectivity, some of whom are also consuming it because they don't do all the work for that. And network service mesh will allow you to chain them together. Next slide. And the way we do this actually borrows very heavily from a lot of what happens in Istio with with virtual services. So every pod in the system that is exposing a network service, say firewall pod and VPN gateway pod, they're both exposing the network service secure internet connectivity. But they can expose them with what we call destination labels. In this case app equals firewall and app equals VPN gateway. Next slide. When the firewall pod offers secure internet connectivity it realizes it doesn't really know how to do that. It knows how to do a piece of that. So it also requests it, and it can put a label on its request. We call this a source label. In this case app equals firewall. Next slide. So you can expand your definition of your network service beyond just name and payload to have a list of matches that will match source selectors and route them to destination selectors, possibly with weights. Next slide. And so a match matching app equals firewall gets directed to the VPN gateway pod because it has app equals VPN gateway. And then when Sarah's pod comes in with no labels on her request you'll fall through eventually to a match that matches anything. Next slide. And it will send you to a destination that is the beginning of the chain. And so in this way, you actually get very loose coupling between these network service endpoints that are doing part of the work, because the firewall pod has no idea what comes next. All it knows is it provides part of a service and then it consumes the rest of it, and you can simply add an IDS between the firewall and VPN gateway pod, just by changing the network service definition in order to augment your policy. Excellent. So this is super important because it means you get a minimal blast radius when it inevitably decides that something else has to happen here, you have to have additional pieces of the chain. Next slide. So you'll note here that Sarah, the developer never sees IP subnets routes or interfaces for folks who are interested I could talk about the technical details of how we handle that. But they're never anything that actually impinges on the developer. Next slide. Also, this does not require any Kubernetes upgrades. We don't need any changes in Kubernetes at all to make this work. And you can continue using whatever CNI plug and you wish to use in order to get your traditional Kubernetes networking because we're completely orthogonal to CNI. And then getting back to the end here with community. So for community, we have stars 132 about 46 forks. We've got code contributors from about contributions from about 22 folks. Typically, our weekly community meetings tend to be a little bit about 20 folks. There's a fair bit of interest we are currently running over 1600 views from our cube con talk. And we're getting a bizarrely large number of views on our weekly meetings I don't quite understand why. We have a number of different companies who are involved as existing sponsors who are working on aspects of this problem questions. Yeah, questions we got about five minutes for questions. I've got one. If nobody else has. So I was curious about the approach so the decoupled approach and the fact that the developer and launcher of the application doesn't really need to know much about what's happening in the back end. But it seems that the current API kind of determines the implementation being a string of pods down this service chain, we can call it that, which, which typically has big performance implications. Have you given any thought to changing the implementation which would seem not to impact the application end of the API. Um, so are you basically saying that there are some circumstances in which a string of highly granular pods to do your network work is probably less efficient than a single monolithic one. Yes, or a piece of hardware or whatever, you know, yeah, but basically pushing ethernet frames through, you know, half a dozen containers is not a quick way to get your friends from one place to another. Absolutely. So one of the things that I have not gone into in this presentation because the limitations of time is the network service mesh architecture itself while it fits beautifully with Kubernetes and we've done a lot of work to make it work well in Kubernetes is not actually welded to Kubernetes. And so within the architecture you could be getting your network service from the physical network, you could be getting it from VM running in some vim somewhere. It's very agnostic on that on the point of where it's actually running. And in addition, the architecture is completely agnostic as to how, how, you know, essentially granular you break the work up into or how monolithic you make it. So one of the things in discussions with people who are looking at building with building network services that we've has it had as a discussion is you sort of have two ways if you're building a network service endpoint that you can use network and network service match. I'm going to give you that first hot plug. Somebody has a workload you want to get granularity the workload plugging into your network service. At that point you can leave network service mesh and do whatever thing it is you're going to do for anything that happens past that point. Right. The second way you can use it is if you do have this composition chaining effect that you would like, you can use network service mesh to achieve that. But the architecture itself is very agnostic as to when you get off the bus, because there are going to be a lot of different answers as to what's the right way to approach that problem. That partially addresses my question. My question was actually more about if a service mesh or sorry, a network service required, you know, half a dozen of these services. Have you given any thought to actually composing those into a single implementation rather than six pods which I think was what was in the presentation. That's entirely up to whoever is building the network service endpoint. Network service mesh is giving you the virtual wires to connect them. Okay. You as the implementer of the network service endpoint can decide the degree to which you would like to centralize all of that in a single blob or disaggregated into multiple blogs. And, you know, quite honestly, I am not smart enough to know what I don't think there's a universal right answer for that. I think you will see a lot of experimentation is people figure out the again is the normal trade off between efficiency by centralizing versus flexibility by decentralizing. And in one of the really exciting things in this space is we have no idea what the right answer is really we have notions but we don't really know, and people are going to experiment and figure out. Thank you. I think it's because of being a bit like K native very low level group of building blocks, put it together how you like exciting if you're a low level person but potentially confusing if you're a high level developer. I'm confusing how. For the same reasons that Quinton has asked you about that you know you might not know how to assemble things as easily as an expert would. I see your point about disaggregation and then that will vary. The reason I was asking for clarification is from the point of view of the consuming workload. I wasn't sure how we could make it simple, simpler than it is. But I think your underlying point is if I'm someone who is building a network service that I want to offer. And, you know, there are options there. And, you know, disaggregation does introduce complexity. There's no question about that. You always have to trade the value of that against the cost. Yep. Cool. I think that does about us for for time right now so thank you. I posted the proposal from the NSM team on GitHub so feel free to take a look at it. It already has kind of cleared the bar for the sandbox and two TOC sponsors from Joe and Matt. But other than that, thank you Ed for your time and if you have questions reach out to their community. Thank you. Cool. All right, let's get next so. Can you hear me. Yeah, here you hear you will go for it. Stan, does your sound work. Yeah, can you hear me. Yep. Okay. Right, so we would like to present kick off project to you. I'm blessed with the widowage with me Stan, who is co founder and a project lead, and he'll take it off. Yeah. So, okay. So first of all, what is kick off? Well, it's a centralized authentication authorization services for modern applications and services. We built it focusing on usability for application developers, trying to make it as easy as possible to install kick off as well as easy to secure applications and services with kick off. We wanted it to be a ready out the box solution, not requiring you to bring your own user store or having to implement login pages and other related pages, allowing application developers to focus on on their business logic rather than the art of using users. Okay, next slide. So with regards to centralized authentication, we have support for openly connect and SAML. This allows obviously the applications to delegate all the authentication to kick off. And applications are also able to obtain tokens that allow them to now invoke API services with end to end user authentication. And of course this works for microservices that it also works on Istio and others of deployments like that. So next slide. We also have support for centralized authorization. So if you want to delegate the permissions and associated policies, you can do that to kick off and then fully centrally manage access to all services from kick off. Next slide. As I said, we have all the login pages that you put you require as well as allowing users to self register, allowing users to recover their password or configuring OTP and all of the things so that you don't have to develop those for your own applications. Next slide. We have an extensive admin console that allows the admin to manage most of the aspects off the Kiko server. And we also have an account console that allows your end users to manage their own accounts. And of course we have a company in rest API so you can bake this kind of capability into your own applications if you want to. Okay, next slide. So Kiko can federate identities from a number of locations. So as I said, we can use the internal Kiko database for your users, but we can also load identities from ALDA active directory, any custom user store. We can also do identity procuring to external open ID connect, SAML identity providers. We also have a bridge into Kerberos desktop logins. And we also have a large number of built in support for social networks. Next slide. Not only do we do scaling and high availability with inside a single site, we also have support for replication across multiple sites. Next slide. So it's easy to secure your applications and services with Kiko. You have a few options depending on what type of application you have. We have a number of Kiko specific client adapters. We also have the Kiko gatekeeper project, which is a reverse proxy solution that can be deployed as a sidecar. We also of course support both open ID connection and SAML2. So you can use any compatible libraries here or if your applications already have support for one of these you should decide. Next slide. Kiko is pretty opinionated and we try as much as we can to avoid feature creep, but at the same time Kiko is highly extensible and you can customize it a lot when you need to. Some examples here is that you can completely replace the whole authentication flow and provide complete alternative ways of authenticating users. For the login teams and the account consoles, you can style these with a little bit of style sheets or you could go in and you can modify the HTML templates or you could go as far as providing your own implementations for your pages. We also have some examples from the community where we have some custom Federation protocols where as an add-on or extension to Kiko, you can now get support for instance for CAS and WS Federation. Next slide. A few things on our roadmap. So the highlight is we are planning to migrate to a community's native Java stack called Quarkus. This will allow us to significantly reduce startup time as well as memory footprint and we'll get numbers comparable to GoBase projects. We're also going to work a lot on improvements around the storage focusing on support for CEO downtime upgrades as well as improving and simplifying the multi-site setup. We'll also be looking at potentially using ETCD for persistence as an alternative to the current relational database persistence layer that we have. We'll soon be adding support for operators as well as observability. We'll also be looking at allowing you to develop custom code for Kiko externally. So to write this in any language or framework that you want and host this alongside of Kiko instead of today where we only support Java custom code that is deployed directly inside Kiko. And this will also help with allowing us to have better API contracts over the long run. And finally we'll be looking at adding support for web authentication which will allow us to have a stronger standardized based authentication both for two factors as well as for passwordless experiences. So Kiklog as a project started 2014. It faced quite rapid adoption mainly because the prototype behind it solved a real problem and it made it very easy and quick for developers to secure their application. And as you can see on a graph from GitHub over time we had a steady and pretty decent amount of external contributions. Next slide please. There are a few community statistics worth highlighting especially a decent traffic on the mailing list. Warf messaging is also the Docker image pool count. Actually we were originally scheduled to present this deck to TOC in October. Back then this number was around 5 million so it more than doubled in half a year. And this kind of speaks for itself. Next slide please. Same for website traffic we've seen it tripled during past 18 months. And we also observed that we had pretty much linear growth like this since the beginning of the project. Next slide. We tried to cover some data from GitHub profiles of people contributing to Kiklog. Those were the company names which came up with those profiles. Several of those are already CNCF members. For example Hitachi made a number of great contributions for features needed to secure financial APIs. And we have plenty of examples of contributions like this. Next slide. Another community survey asking a number of questions how Kiklog is being used. One of the questions was are you willing to be a public reference. And those were the company names which came up agreeing. And again you can see quite a few recognizable brands here. We know from site conversations there are many other brands using Kiklog internally. Next slide. Technology radar by Toughworks is actually quite recognizable reports among application developers. The way they pictured us claiming like we are a solution that makes it easy to secure applications or microservices with little to no code actually made us really proud because they essentially captured our mission statement. Next slide. In the last mentioned survey, one of the questions we asked was how we deploy Kiklog. And if you add up Docker, Kubernetes, AWS and OpenShift, you can see that pretty much two thirds of Kiklog deployments reported by our community are in cloud related environments. So this also speaks a lot. Next slide. One of the many reasons we think that we fit CNCF nicely. So we have a very healthy community with a number of contributions as Stan highlighted, we try to be focused avoid future creep and really focus on embracing future facing standards like OpenID Connect and all to do both being already adopted in cloud native ecosystem. Primarily aim application developers, you're lightweight, portable and highly customizable. Next slide. So we would like to ask to become a sandbox project at CNCF. We hope that this would boost our community adoption even further. We would love to take part in the security seek, which we know is being formed right now, and on a very practical side. Currently CI testing is funded by Red Hat and happening on internal infrastructure. We would love to challenge it with CNCF resources. And that was our last slide. Thank you. Thanks. Any questions for the folks. I think we originally were going to propose this, you know, the project has blown a lot in the last six months. Do we still feel like sandbox is appropriate? Kind of feel like there's a pretty wide base and I mean, of course we want more adoption, but I think it's been adopted more than what we had in our original one. Do you feel like it could maybe skip sandbox? I mean, I will defer to the TOC on that I think first you need to find a TOC sponsor. Or two for the sandbox or one to push you for kind of an incubation boat. Personally, I think it's a bit borderline, but I kind of defer to the TOC on their opinion here since they make the judgment call at the end of the day. I had a related question actually, which is the project is what about five, six years old now. So I'd be curious if there are any reasons why we don't think it meets the incubation criteria because if it doesn't after five or six years, you know, that raises questions in itself. I think, you know, my biggest concern here is that, you know, and I don't know much about the key cloak, but like, you know, hearing about the plans for improving the way that it gets deployed makes me think that it's a little bit of the traditional Java application. And so I think one of the things that I would want to look at carefully when we look at sort of, you know, moving towards an incubation level would be something like, you know, is deployment something that is feels very natural on something like these are other dynamic environments. Are there extensibility hooks that are usable without sort of building jars and it sounds like those things are on the roadmap and I think that's that seems like things are moving in the right direction there, but it also seems like those are those are very nascent My overall preference would be to, you know, to get them into the incubation, like, you know, quickly, and then start to have that, that conversation, or sorry, get them into sandbox quickly and then, and then start to have that conversation. I think if we, if we try to skip over sandbox, then we're going to have to, you know, we're going to spend, spend more time kind of, kind of circling on it and trying to figure it out so that would be kind of my preference and then maybe have maybe have them try to immediately start working on that on on what, what kinds of things like that Joe mentioned for graduation. That makes sense. You're proposing sandbox to get them in early and then work with them to move towards the next level which requires a higher level due diligence if I understood that correctly Jeff. Yeah, yeah, it'd be. Yes, exactly. Don't wait a year to do that just get going on that. Let's get going on that now but let's get them into the same bar. Are you willing to sponsor them then Jeff. Well, we're, we're, I'll follow up, but I mean, we're, we're considering them for for authentication for into it. So yeah, I'd be happy to sponsor them. I think doing a call on the TSC mailing list asking for TSC sponsors input is probably the best step over since you have one through through Jeff now. Okay. I have one now. I'll catch up with you guys later, but yeah. Very quick and go ahead. Yeah, if we have time. So the sort of elephant in the room when it comes to centralized authentication authorization is typically high availability and and scalability because if if the centralized thing is either unavailable or slow. So all the applications that rely on it. And there wasn't much talk about that in the presentation. It sounded and I'm maybe putting words in your mouth here that there is some centralized server here that does all this work and if it's unavailable then the services unavailable. Is that true or do you have a better story than that around high availability and horizontal scalability. It's a cross side support. So I guess the best example if you go to access the thread cap.com to log in as a red hat customer actually it's red hat this is all behind it and it's a cross side replicated. So if one side goes down the other should pick up. Okay, but but in a given site, you just have one server and when that fails you have to fail. There is a cluster behind so it's it's cross side replication of clusters servers. So it's a traditional clustering. So multiple nodes and then you can replicate between sites as well. Okay. What's the clustering technology there is this some sort of, you know, L2 thing or, or is it something like wrapped for leader election type stuff. I've seen in JVS application server or red hat enterprise application platform. So in finnish spam based clustering. You need do you need access to red hat to be able to run it. I mean when you say red hat, you know, enterprise application platform that makes me think that I was referring to the red hat deployment. So that's the the community one. Why so everything that red hats has. So my manager, but everything that red hat has absolutely questions. So you have anything this spam, and you have white fly server. So do you have statistics on how many users are using the red hand version versus how many are using the community version. That's something that I'd be very interested to see if folks use it outside of the context of red hat enterprise license agreement. Oh, certainly. So ever all the names mentioned in the presentation are not product related. So all of this is purely community data. I don't have any permission to kind of like leak the customer data. And also, we know that, like from the mailing list, we know that there are pretty serious deployments. Actually, even people approaching multi tenancy with it to certain extent. I think I think we'll continue the discussion on the mailing lists. And we'll kind of go from there and kind of seek input from the TOC and maybe an additional to see sponsors. So thank you for your time. And given that we have 20 minutes left, we should respect the last project to go. So next up, I think is Strimsy. That's how you pronounce it. That's right. Thanks, Chris. All right, go ahead. Hello, everyone. My name is David Ingham. I'm an engineering director at red hat. And I've got some of my engineering colleagues with me today, hands on with this project. So in a nutshell, Strimsy is a fully open source project that's focused on the deployment and management of Apache Kafka on Kubernetes. So essentially it contains container images for Kafka and zookeeper, which is a prerequisite component of a Kafka cluster and provides operators and configuring the cluster. And also the topics and uses that that are running on that cluster. And yeah, like the slide says leverages the power of cube for scaling and high availability, etc. I'll talk about that a little bit. Next slide please. So why are we bringing this to CNCF? This this charts interesting. So this came from the recent Apache Kafka survey that illustrates how people are deploying Apache Kafka. And you can see that there's 34% here that are focused on Kubernetes. And this is an increasing trend. So in my experience working with customers increasingly organizations are looking to deploy Apache Kafka close to the workloads that are consuming and producing messages into the into the event streams. Next slide please. So there's a lot that's great about running Kafka on Kubernetes so Kafka itself can be a pretty daunting application to to deploy and provide ops for you can think of it as a cluster database management system as an analogy. So there are there are many components typically you'll run with a cluster of several broker instances. You'll have several zookeeper instances, you'll have other components for something called Kafka connect which is interacting with third party systems or mirror maker which is about replicating a topic between sites. So you'll have you'll have a large number of processes that are used to support Apache Kafka and dealing with that, you know, providing the ops support for that dealing with the physical servers the scalability etc is a real task. And Kafka on Kubernetes really simplifies what it takes to be able to deploy and manage a cluster like this with with a much lower operational overhead. So the focus is that, you know, we provide configuration as code through custom resources that I'll talk about an operators that manage those custom resources to interact with the Kafka components to do the deployment. Okay, next slide please. So, as we know, Kubernetes provides a number of underlying facilities for dealing with stateful components. But it's still a pretty complicated task so specifically Kafka needs a list of the things here like stable broker identities, a way to do discovery. Provisioning the management of durable state being able to reattach to durable state in the event of a failure. And you can, and there are raw capabilities, increasingly Kubernetes is moving to address stateful applications like this so there are these raw primitives that are provided, but it's still quite a complex task. And rather than have every, everyone that's looking to deploy Kafka on Kubernetes have to deal with these low level primitives, it makes a great deal of sense to provide a common way of doing this, which sort of lowers the barrier of entry for deploying and managing Kafka clusters. That's the premise. Next slide please. So, I mentioned operators, I'm sure most folks are familiar with operators that are part of this call, but essentially we use custom resource definitions to define the different entities that we're working with so the clusters topics users, etc. And then we use the operators to monitor those custom resources and make changes to the system make forward progress to the system to make the real implementation match the desired implementation that's provided in the custom resources. So we're observing we're comparing the current state and then we're acting on that. Thank you. Next slide. So we have three operators. There's the cluster operator. So this is responsible for when it's primary role is for managing the cluster. So here you provided a definition where the number of broken nodes that you would like configuration of those broken nodes and configuration of the storage in the form of a custom resource. And then the operator monitors those custom resources and will deploy or update or delete the cluster based upon based upon your wishes. When you have a when you have an operate when you have a cluster up and running. That's where the topic operator comes into play. So the topic operator uses a custom resource that describes a topic in terms of its name number of politicians by number of replicas, etc. And will work with the API's of Kafka to bring those topics into existence on the cluster. And there's an interesting technical point here in that using different features of Kafka it's possible for topics to be created in other ways. For example, if you're using the streams, the Kafka streams API, then that will result in topics being created on your behalf. One of the things that we do in the topic operator is do a three way diff to ensure consistency is maintained across the system. Hey David, this is Alexis. Can I interrupt for a sec? You may. Hi Alexis. Maybe I'm, hi, maybe I missed this but is the cluster operator also getting rid of some other zookeeper faff that Kafka sometimes comes with. The cluster operator manages the zookeeper faff for you so you don't have to deal with spinning up a manager managing zookeeper pods yourself. That's implicitly managed by the by the cluster operator and I'll show you a picture of that in a moment. Okay. And then finally the user operator is responsible for managing users. The cluster operator also looks after other components and so Kafka connect mirror maker components as well as the Kafka brokers themselves. Next slide please. So this is just emphasizing the point. So, you know, it's a Kubernetes definition a Kubernetes native definition of the different components of the system. So the, the first snippet here is the Kafka customer resource and then the middle we have the topic and on the right hand side we have the user. So this is what gets picked up by the operators. Thank you. Next slide. I think if you push the next slide, we might see some animation. Yeah. So, here what's happening is the operator is picking up the custom resource and is spinning up the zookeeper nodes. And then we'll spin up the Kafka broker nodes. It will also instantiate the topic and user operators on your behalf. So the only thing that you need to deploy is the cluster operator. Next slide please. And one more time I think. Yeah, and then when we make a change to the cluster and an update is required. The operator is embodied with the intelligence to do the, the appropriate rolling deployment of the various components. So this is something that requires a little bit of skill is essentially what we're, what we're doing here is taking knowledge that, that typically the Kafka operator, the human Kafka operator would have and we're trying to automate that embody the, the, the software operator to do these tasks on the user's behalf, therefore minimizing the amount of work required and lowering the barrier of entry. Next slide please. So the, so following off from that point, the ambition is to really take that to, to the limit. So to improve the system with smarts for dealing with automatic configure a reconfiguration so a concept called cluster balancing which is something that one typically needs to do the Kafka cluster. To provide automatic scaling to look for anomalies in configuration, etc. So the, the, the goal is to make it possible for anyone to be able to operate a Kafka cluster for a commercial production deployment with with a lot less specialist knowledge. Next slide please. So in terms of community. I've just got a couple of slides here similar to what we've seen in the other presentations. So the work began in October 2017 in earnest and you can see the, the data there. So it's a pretty popular project. And we've had consistent contribution through throughout that period. Next slide please. And similarly in terms of website growth, I don't have analytics before September 2018. So I can't show you what happened before that but in the time between then and now we've seen about a 250% growth in monthly visitors. So we've got a pretty active slack channel where folks that are using streaming streams in earnest come and ask questions and and get feedback on their configurations. Next slide please. I won't read through these I took these from the TOC issue so I think Chris has Chris will paste in the TOC issue perhaps so that everyone can see. You know you've we've got four red hat people on the call here I just wanted to give some quotes here from people outside of red hat just to emphasize that this isn't. It's not solely useful to to red hat folks or something like that. Next slide please. So why are we talking to you guys why do we think this is a good fit. Well, so firstly stringsy is fully open source. It's licensed with an Apache license. But it's, you know it's a pure open source thing in the sense that it's not the foundation to some open core bigger thing it's a pure open source project and the goal is to to satisfy all of the needs that folks will have of running Apache Kafka through through this project. As I pointed out before Kafka's usage on cube is significant and growing and increasingly we're seeing Kafka being used in other projects. So I mentioned here, K native so the K native eventing has the abstract notion of an abstract communication channel. I think many folks are looking at Kafka as an implementation of that of that eventing channel as a concrete example and we've integrated stringsy with K native eventing upstream. So what we're hoping to gain from the exercise. So we would like, I guess formally declare we'd like to become a sandbox project at CNCF. The main the main focus here is about increasing awareness. So whenever, whenever we present about stringsy or talk to people about stringsy and they play with it, the reaction is uniformly positive. I just wish we could have more people become aware of the work that that's happened here. So that's the that's the primary reason I think to to sort of increase awareness. And as part of that, you know, we would like to get greater community involvement. So we've, we've got a reasonable community, do you know the people that the quotes that I mentioned on the previous slides that people from other firms that have made contributions here and so it's not purely a red hat thing. But I really like this to become a true community project and and just become a neutral home, you know, so for stringsy. And I think that was it. So we'd be happy to take any questions. David, I've got some questions. It's Alexis here. Alexis. Hi. Hi. So do you think there are technical lessons to be learned from running Kafka on Kubernetes in this way that can be applied to other projects than Kafka that might want to run on Kubernetes but are not themselves a Q based or a log based system. Yeah, well, I think there's there's some general general lessons learned about, you know, you can look through stringsy and and see the, you know, just the challenges of dealing with a complex stateful system and and how to automate how to automate that. I think what the idea, you know, used to be the case if we rewind a couple of years used to be the case that just the idea of bringing something like Kafka to Kubernetes. You know, you'd be you'd be scared off of that, you know, when when stateful sets first arrived that was the thing that sort of made it potentially possible. But it's still a, you know, pretty complex task. I think what stringsy is shown is that, you know, it is possible to to build systems like this and and you know you get a lot of advantages by automating a lot of what would typically be done by operational experts that that you've employed to your, your cluster, you know, in the same way that you hire your database management system experts. I think that the fact that if you're able to, you know, look at systematically at the what the operational needs are and David, I mean, as an example, having previously tried to build a cues as a service thing myself, one of the things that you end up building is a as a quota system, so that you can allocate different quotas to different users of the system. You can imagine. Yeah, something other than Kafka. I mean, this I'm coming at this question that's popped up on the chat about this other there's other operators. Yeah, you should have a look at it. There's a Chris pointed out there are several other operators in the operator framework slash awesome operators, including there's also a confluent operator. That's right. We'd like to know, you know, what is your view about if you want to have the whole community and there's not be just the red hat thing. Yeah. And again, I think there's there needs to be a rationale which could be, well actually, you know, there are technical reasons to put this in close proximity with Kubernetes because there are other components that can be transposed to other projects. And, you know, it's fine to have multiple different operating implementations but ultimately, it's a good thing for this to be developed by people who are looking at Kubernetes as a whole rather than people who are looking at Kafka specifically. And this is a really important question for us as an organization because there's gonna if you if you wonder about what projects could we have that are Kubernetes for X. There's potentially a lot of X is out there and we can end up with billions of these things. So, you know, there's we've got to draw the line somewhere and we don't know where to draw it. So we've got to start asking tough questions about specifics. Yeah. They're good challenges to have right to to be in a popular position where the ecosystem is growing at such a rate that you have all of these projects looking to looking to bring them to CNCF. So with regard to the other operators that are out there, I know that there is I know Confluent Hat do have an operator. I haven't seen it. It's it's close source. So I don't know. I don't know a great deal about it. Others may, others may know. In terms of question, by the way. Okay, Quinton, go ahead. Yeah, I was just curious. You guys seem to have done, you know, some work running zookeeper as well as Kafka and the zookeeper stuff alone could be quite independently useful. I was just wondering if you've ever considered splitting that part out so that someone wanting to run zookeeper but not Kafka would be able to use that part of the project. We, we haven't done but it would be trivial to do so. I mean, that might be super useful. I mean, not necessarily as a, you know, blocking requirement, but in the future, being able to have the zookeeper part of it independently consumable would potentially be very useful. Yeah, we, you know, our for us zookeeper was a means to an end, you know, a prereq for for the cluster. But we could absolutely. If, if other folks thought thought that that was independently consumable independently valuable, we could definitely expose that. I think that could be the key to getting this thing into a good good state. It looks like some of the other operators may have kind of been experiments and the confluent being closed source obviously answers that question. I think that, I mean, I would like to put up my hand as a potential sponsor, because I'm very excited about this, this area. But I would like to know what is your step by step plan for this becoming a community neutral project, rather than, you know, just just the red hat thing. I think to be, to be fair, I think it's a community neutral project right now in the sense that, you know, we accept can contribute contributions from non red hat people and they've been. They've been a number and those comments that I plucked from the TOC they weren't from red hat people and they were like light band and we work and other firms that have been contributing to the operator. I, I know what you mean like we have a significant team that's working on this. So it is a, you know, you could form the perception that it's a red hat thing. And that's the, like I called out here that's one of the reasons that we want to bring it to CNCF to build a real community around it, you know, Red Hat we know, we know the value of multi vendor rich open source projects and we'd like to turn this into that. Yeah, Joe made a good point about open governance roadmap owned by the community. Yeah, we went through a similar evolution with with we've cortex, which is now a CNCF project. And we actually work on it with companies that we compete with. And that actually works really quite well in fact, but it the key stage was moving to open governance in a community and roadmap and encouraging that way of working. Yeah, I think we would be absolutely amenable to that. I think it would help just given because there are so many other operator implementations that a naive person might look at and say well how is this different from this. So, yeah, it would espouse our values in the right way. All right, thanks so much David that was great. In the interest of time we're a minute over going to want to be respectful for everyone's time here I kicked off discussions for both Keek, Locke and Strimsy on the TOC mailing list. So please move that discussion there and hopefully these projects will find to see sponsors and we'll go from there. So, other than that, I want to thank everyone for their time today and thank you for fitting in three projects today. Great. Take care all. Thank you.