 to share this screen, right? So just to give you an overview of who we are. So I'm Danielle, I work at Fairwinds, and we put together a Kubernetes maturity model based on our experience helping manage Kubernetes for many companies. And so I was invited into this group because we had something as a foundation that we could use to build upon as well as Simon had similar. So over to Simon for your intro. Yeah. Hello everybody. My name is Simon Forster. I'm the founder of a small consultancy here located here in London in the UK called Stackogy. And I originally engaged with the CNCF through Cheryl Hung as it happened around some work that I've been doing around maturity models previously with a number of organizations. And as with Danielle, I'm a co-chair of the Cartographus working group. So John, do you want to introduce yourself? Hey, are you okay? Yep. This is my messy office. Is everybody doing today? I'm a director at Centra. I'm also a master technology architect as well. Been at Centra for eight years now. And over the over time, Robbie Glenn and I was on the call. So I built the maturity model for clients at Centra. We turned it to the cloud, turned it to Kubernetes. And it was pretty mature, you know, modeled. And I thought, Hey, this would be great to donate just the CNCF. And then that kind of created the bulls rolling and how we connected then with Danielle and Simon as well to make this reality. And then a QCon was launched. And it's pretty exciting so far. So best of microphone over to Robbie. Hey, Robbie Glenn. I work with John. And we built, you know, something of a maturity model for some of our organizations. And as he mentioned, that's kind of how we got involved in this. And instead of coming up with three, you know, distinct frameworks, we decided that we should combine them into one. So that's, that's where some of this came from. Nice. So we have just a few slides to talk through. And then again, the kind of ask and discussion on what we want from all of you. So over to John, he's going to start us off. Sure. So everybody is familiar with the eyesore on the screen, right? When they go to see CSIO, they just big, you know, screen of those little icons and what do they mean? How do I use these? How do I adopt these? So a big part of our thinking over here, when we went to kind of our office and in the maturity model, was how do we take all this and shape this into a landscape that people actually can use? And to embrace cloud native, to embrace CNCF, what does it really mean to be cloud native from a, from model one to five? How do we get one to five and within that, that the roadmap as well? Obviously, during the past several years, a trial map has also been defined as well. But how good is the trial map, even though the trial map is very confusing and not really guiding you to where you need to be? So we thought as a team collectively, how cool would it be to put together a true landscape, a true model, a true map of how to get there. And thus, that's how, again, how cartographers was, was created and developed. So over time, there's always been a journey, right? In the beginning, right, there was the journey to cloud. We all remember those days, we back when, right? We used to be Wackenstack servers in a day centers that we ran every day. And then the cloud happened. And then everybody said, during the cloud, let's go to the cloud. Yay. And that, that was going on for a very long time during the process. We went to VMs, the VMs was the cloud. That was that initial journey. And then, you know, this whole thing about DevOps begin to come up. How do we do DevSecOps in this new landscape? I'm used to doing DevOps in my own world, Wackenstack servers on premise. But what, how do I relate that to the cloud? How does that journey happen? And then over time, Kubernetes became more of a thing from swarm to Kubernetes, right, through the last several years. And then, yeah, Kubernetes has become the operating system of the cloud. Now that we have the operating system in the cloud, there's a new journey. And we believe that journey is that cloud native. A cloud native is born from these three roads on the left hand side, where, you know, from between cloud DevOps and the Kubernetes container journey, you will be involved today now to where we are. And this is the cloud native journey. And in my opinion, all opinion, the road always leads to cloud journey to the cloud native. So that's where we are. Next slide. You're up on some of these slides. Yeah. So we kind of touched on this before, but the idea is that, you know, we were individually kind of seen in the industry when we work with clients that we were building roadmaps over and over for them. And basically, you know, what we wanted to provide was not just not necessarily a single roadmap that's going to try and fit every, you know, a one size fits all, but really a framework for to, you know, provide some really good insight into how you might go from one maturity level to another, but also across the board, we wanted to, instead of just focusing on technology, which is oftentimes what we're focusing on when we talk about introducing, you know, a new technology into your organization, we wanted to actually look at other dimensions, including, you know, the people aspect of it, how your organization needs to change along the journey, the different types of policies you might need to implement along the way. There's a huge emphasis these days on policy, and there's a migration toward, you know, toward policy as, or I mean, infrastructure as policy almost. And then I, we wanted to make sure that we provided that kind of a, that kind of overall, you know, journey across multiple maturity levels that I sort of goes across those, those four dimensions. So this is just a much, you know, kind of a condensed version of the last slide. It's really around the tactical versus the aspirational components of this. So very tactically, we're trying to provide this framework. We have some documents in that we have pushed to GitHub that kind of give some overviews. We have some, we actually have a spreadsheet that we've worked in to really provide that kind of level of detail in terms of where, you know, either activities or events happen within the particular framework. But aspirationally, we're really trying to, you know, help users adopt these, this cloud native journey and build their own journey for themselves. Go through kind of what, excuse me, the maturity model looks like. So there's five main phases of the maturity model. And what we did is we built them up as to like, okay, where are you at? So in the first stage in the build, these are people who are in pre-production. They are trialing stuff, but they're in, they're not really, nothing's in production yet. They're experimenting. Then you move on to operating where you do have a foundation established and you're looking to deploy probably one app, an easy app into production. Stage three is about scaling. So the steps you need to make sure Kubernetes can work across your organization, across multiple apps. In the fourth stage, you're looking at improving everything. So that's where we have said, okay, you're going to be looking to improve your security, your policy, your governance. And then in stage five is where you can look back at everything you've built and done and how can you optimize it? What metrics do you need to be monitoring? And what do you need to do to make sure the infrastructure is optimized? So there are detailed descriptions of the five stages all on GitHub that you can look at. And then the kind of how the model is divided, which Robbie alluded to a little bit. And I'm sorry about background noise. My dogs have decided to fight right now. So good thing, you know, it's always on your call. So we broke it into four main divisions. So we looked at the people because when you move to cloud native and you're adopting the technology, it's also about how the people are going to interact with the technology, how it's going to work across your organization, how you're going to build teams. We then looked at like, well, what are the processes you're going to need to put in place to make sure cloud native is successful? What are the policies you need to translate from your existing infrastructure technology to the cloud native world? And then what is the technology that you're going to use? And I think for all of you on this call, we're really interested in the technology part. Because with the people, the process, the policy, we spent a lot of time looking at those aspects and doing a high level, like this is what you need to be thinking about. But in the technology, it's all of the expertise that, you know, you might be able to elaborate on for us. So Simon, you're going to talk about how everybody can get involved and help us make this maturity model so much better than it is. Yeah, thank you. So first off, and importantly, being a CNCF project, we do have a repository under the CNCF organization called Cutagraphos. It contains within there the main charter, of course, and how the group is put together and how to contribute. It also contains within there a series of documents as a prologue and also a document for the respective areas of people, process, policy, and technology, and the five levels and how they relate to all of those. We also have at FIPPIO, the book, Admiral Basher's Island Adventure as well, which came out. That book, the reason that I bring that up is that was based on much of the work that we did within the maturity model. It would be helpful if you wish to just have a brief review, if only if the prologue is all help you to gain a little more understanding of exactly what we're doing. At this point in time, what we haven't, we have not put together a graphical artifact, such as the like the trail map, northern landscape. We do see that something like that will be on the roadmap for us also, but we really appreciate your contribution. In terms of getting involved, we already have this meeting. We hold this actually every two weeks. Likewise, the details are available in the GitHub repo. What we'd really like now, because we're at the stage where we're trying to mature the maturity model, is we'd like to have involvement from your respective tags. If possible, we'd really appreciate having somebody who might be able to come along and help us liaise, a contact person, if nothing else. What we've put together a spreadsheet that contains just each of the levels and the levels 1 through 5 and where we hope each of the tags will be able to contribute. But I think the important thing for us is starting that conversation, and we also do have a channel on Slack. Also, thank you, Danielle. Thanks for bringing that up. What you can see there is we've got each of the five levels with their descriptions. We've got some areas. You'll see on the left-hand side, you can see the blue line. We've got people. Then under that, we've got a few various stakeholders. Then we come to process as well. You can see under process, we've got CICD, change control, some security and software supply chain. Then we have policy further down. Of course, technology. We've produced this in order to give you an idea of some of the rigor that we went through. We did go spend a significant chunk of this year working through each of the areas. Danielle, if you could just switch to the second tab template for TAG, just as a helpful reference as well, what we've identified is just the tags and just some thoughts. We're really after any guidance under the respective areas that you may be able to provide us with. If you're able to perhaps populate that, we can ensure you receive all of the details of this in plenty of time. Please feel free to ignore suggestions that you may see in there. For example, I can see some of the projects such as Coverno or Open Mentioned. We'd like to defer to you as to where you think some of these projects may come in. One of the really important task for the maturity model is to perhaps assist in setting a common baseline. Different people have ideas of the level of maturity around where you would bring in a project perhaps into an organization. We're really interested to get your thoughts on what are the prerequisites, clearly Kubernetes is a very early one for everybody, but with the projects in your respective area, where do you feel as an organization or institution embarks on its cloud-native maturity journey, where would it be worth bringing that in, and what would you like to see as a prerequisite as well? We'd really value your feedback there. We'll distribute this spreadsheet to all of you after this, and we do appreciate, of course, your effort to come along today. One of the things is that we're also able to meet with you separately. If this meeting time doesn't work, or you want to just pick our brains as to how we built the original spreadsheet or what we did, we're happy to get involved on your side when it's convenient. Just in terms of where this is with the CNCF, we did have a book published based on this, and it was mentioned at KubeCon in North America during the Keynotes. As we move into 2022, the CNCF wants this more matured so that they can continue to promote it, so that when people are coming to them, or end users are coming, going, what do we need to do? This is going to be the resource that the CNCF points them to, and the end users group is going to get visibility into this in detail in January. That's kind of what's in it for you. You can get end users to be thinking about your special areas early. Just to finish off, perhaps we've got to bring up the last slides there, Tenia. As you know, we've started the process of socializing this amongst the tags, and also we've been getting in touch with the end user groups as well. But the charter of the working group means that we can work on more than just the cloud native maturity model. We're really around also working to develop tools to help the community navigate the cloud native landscape. We are also interested in new ideas for artifacts. We have worked in coordination with the CNCF business value committee, and the CNCF landscape guide has been published. Some of you may be aware of that now at landscape.cncf.io. Of course, we always appreciate contributors coming along. So just on the last slide as well, just to finish up, we will distribute it again, but we do have the model. We've got four key areas of people process policy and technology, and we will distribute to you the spreadsheet. The core reason, of course, that we're here today and why we've invited you all is to start the conversation. We're really keen to make sure that we get as much input as we possibly can from the CNCF and its projects, and we believe that you're all absolutely critical to that mission, and we would love to help you. Thank you. So I think with that, if you have questions, want to ask about this, we're happy to discuss. The spreadsheet is the main part, or you talked about setting up meetings afterwards, and also that becomes part of the contributions or how to help basically. The spreadsheet is the main thing, so using that to kind of think through, okay, the five stages, what is important to the tag, and we put it in the spreadsheet because we thought that that was the easiest way for all of you to contribute, but we do have this all on GitHub, so if it's easier for you to do pull requests in the main documentation written up, then that works too. And again, if you're kind of going, okay, we're working on the spreadsheet, we'd love to have one of you attend a call just to make sure we're aligned with what needs to get done. We're happy to do that. Perfect. Thanks. Josh, you had a question? Yeah. My first question is, who exactly is going to be doing all of this analysis work? So that has been Robbie, John, Simon, and myself looking at and doing it. So the maturity model that's published and the one that the CNTF is promoting, we put together and then we shared with Simon, correct me of the name, the main people. So Cheryl Hung, Chris Anacet, also Katie Gimangy on the end user community side, so we socialized it throughout the CNTF. Yeah, I'm more concerned the actual collecting of information for each project because I'll tell you, being part of the CNTF already involves a ginormous amount of people paperwork time and adding one more ongoing set of information that has to be tracked is going to be a serious problem in the current environment. Yeah. So what we'll continue to work to collate and evolve the model, that's a core responsibility of this working group. We don't want to burden anybody with additional overhead. So the key thing is we're really interested in observations in starting the conversation and if there are sources of information that you think, oh, this is really relevant to what the working group is doing and to the maturity model, we're very happy to be pointed in the right direction. If all it is is popping a URL and snack and saying there's some great stuff here and we think you should know about it, that would be great. We want to foremost avoid any inaccuracy in what we're doing, so we just want to make sure that we don't put out incorrect information that you're not happy with. So you don't have to worry about rewording or submitting PRs. You have, of course you can, but we realize that there's a real overhead in that and we're happy to maintain that ownership of carrying out the updates to that. Now you do understand that this information you're assembling is going to be highly political, yes? Yes, we're doing. I want to just jump in for a second and just see a few things and if you look at overall sandbox and CNCF and Linux Foundation projects, it's a lot of coding. Everything is programs and development cycles and cool things that's been developed. When I first approached Cheryl Hunt about this approach for the maturity model, she said, well, John, there's no code in that. That's just documentation. I don't know if we can do this or not. We're going to say that it's a workout, but through weeks of discussions, we're able to make sense out of this. After I brought in Danielle and Simon to the party as well, so that we get traction on this thing. But at the end of the day, I truly don't think how native can fully mature and get out there without some kind of model behind it to do this. I'm very passionate about this as well as we are on this team to do this. And yes, there's a lot of overhead here. It may be very opinionated. A lot of things that I personally wrote on this thing is very opinionated. And I expect that there may be some religious roblox on things. But at the same time, we could further mature it to be more than one thought. We're going to bring other people in and we may balance as well. If that makes sense. So, Alex, one second. I think the big thing, Josh, is that in terms of political, I think people don't disagree that you're doing a migration with technology, that you need some process in place, you need people to adapt, you need the core foundation of it. It's like, yeah, those things are going to need to happen. Now, whether something is in phase one or phase three, that's debatable. That can be discussed. Things can be moved around. And that is why, you know, we know that the four of us brought opinions to this, put it in there. But now we need to make it more encompassing of the entire community. Alex, do you have something? So, two points. I was just thinking, and just maybe thinking a lot here, but I kind of think it's going to be, there is going to be a bit of a king making thing if we're putting projects in specific buckets. But if we, but I also kind of agree with John that some sort of roadmap and some sort of, you know, parts to follow is kind of obvious. And maybe there are a bunch of unspoken, you know, things there anyway, even if it's not official. But I'm kind of wondering if we can also just have some general guidelines around that, around, you know, saying, you know, graduated projects are better for level one and incubated projects are, you know, better for level two or something like that. But I think we're going to have a bit of a challenge if we just think about it from a project point of view. And honestly, I think we should be looking at this in a broader sense. So, some culture of the storage tag, and as you were talking, I was kind of thinking, well, what aspects of the technology would we also like to see there? So, for example, we could say at a certain level, you may want to consider using operators, or you may want to consider using a particular security policy for storage. And it's not just, you know, the technology side for a specific project, but it's actually how you would do day two operations in storage, you know, as well. And I can imagine the same is going to apply for, say, networking or security or anything else. Like, you know, the concept of GitOps isn't just a, you know, a runtime thing, it could also be a storage thing, it could also be a networking thing, etc. So, and I think we all agree with you. We put, and it's in GitHub, that we would only include reference to graduated projects, because we didn't want to get involved with, well, this is incubating, well, this is sandbox, and this is in here now and not in here. So, we were like, we're just doing that, and we're not including any commercial products in here. And I think, Alex, your point is very much how this is talking about. It's saying at this stage, you should be thinking about how you're integrating security. And you're probably going to be thinking about this, this, and that. So, likewise with storage, you know, in phase one, you're probably going to be, and I'm making this up, like the default storage settings that you can get in the cloud. But as you mature, you're going to want to think further down that. And I think the way we've worded it to date, and the way we'd like to have all of you contribute, is at that higher level of like, you should be thinking about these things now in this stage, but not giving necessarily going. And the answer is X, because we all know that everybody is deploying their cloud-native technologies differently. Like it is not uniform anywhere. No, right, exactly. And honestly, I'd love to tie this back to some of the work that we're also doing in the tag around, for example, you know, if you're like, for example, we have our white paper, and we can certainly plug a chunk of our landscape white paper into some of those different sections. But then, you know, we could also have at level three, you may want to consider, you know, benchmarking and performance analysis. And here's a link to the storage performance analysis document that we provided. And that's level four, you might want to consider disaster recovery. And here's a link to the cloud-native disaster recovery document that we provided, you know, those kind of things. I should hope people are considering disaster recovery before level four. Well, it's just an example. Yeah, I know. But I think that's exactly right. This could be, I mean, it's hard to find resources that everyone is creating, right? We're all out there creating different resources, and we want people to read them and digest them. Otherwise, we wouldn't spend all this energy creating them. So having the maturity model where we're linking to the different resources that have already been produced, I think is of extreme value. And then again, the CNCF can say, this is your handbook that you can consider with all of the resources interlinked. And I think, Alex, some of the subtle tree that you brought to that conversation just then is exactly what we would like to bring as well. And if we look at the trail map, for example, that mentions specific projects and is attempting in some respects to undertake that king-making role that we've spoken about and how troublesome that is. So it's precisely because of that challenge that we made sure we incorporated the other dimensions of people process and technology, people process and policy, I'm sorry, as well as technology. It's precisely for that point. So you're absolutely right. You fit the nail on the head and actually described a key motivation for us all with this. Yeah, I think that's going to be significantly more important. I mean, I'm sure it kind of applies differently to each of the different categories, but in storage, we've always had a little bit of a dilemma because there are storage covers a wide variety of things, everything from volumes of databases to object stores to key value stores and everything in between. And so we don't necessarily automatically have CNCF projects, which are graduated in all of those different fields. But the reality is most people do cloud native with a variety of cloud services and commercial projects and some projects which might be under different foundations as well. And so it's more important to kind of capture some of the attributes and some of the methodologies and the policies and the how to's rather than the than just, you know, say use this project because that's not necessarily going to like tick all the boxes for most people. Yeah, agreed on all of that. Cool. A couple of things to point out. First of all, I really liked Josh when you chimed in there and said that we want to, you know, we should be seeing DR earlier. That's the exact kind of, you know, guidance we're looking for. And I think that we probably did maybe, I don't know, maybe we maybe we didn't touch on DR has been a while since I looked, but that's the kind of interaction we're looking for. It helps us make sure that we're kind of, you know, honing in on the right maturity. I do want to point out, I guess, that, you know, there's a tendency, especially at organizations when we've brought these kind of things in the past, that they want to look at these in terms of their capabilities. So the maturity of their capabilities, that they can do this, that they can, you know, implement DevSecOps. But do they, have they hit that kind of saturation where every project that's running in Kubernetes is doing all of these great things? So I think that's another like aspect of the maturity models that we're trying to promote is that it's not, this is not about, you know, oh, we could do this. It's that we're doing it across the board as a baseline. So just to, I guess, finish that out is that many of the maturity levels, you can actually achieve a high degree of, you know, maturity within that level, right? So like, let's say you're level three, you're scaled out, but maybe you don't ever need to get to that optimized point. There's totally valid reasons to really, to make the goal, you know, not necessarily level five. Sorry, John. I just want to point out is one of the things that what I talked to, you know, companies that go on cloud native and Kubernetes and all those great things around that is that a lot of times they want a prescribed method. They want to know how to do it, you know, they're, they don't have the resource to do it themselves, right? And so they're really looking for a prescribed way of doing things. So the whole idea of the initial, one of my initial ideas of this cloud native maturity model was to give your clients, companies a roadmap, you know, a prescribed way of doing it because they're looking for that leadership, they're looking for that thought leadership. And if we take the best people in the community, help us build this out to have more, you know, perspectives, more opinions, more viewpoints on a prescribed method, the more mature it'll be. And, you know, yes, it may be political, but that's fine. I mean, that's, that's not a concern of mine, but that may be political at some point. But at the same, at the same point, though, you know, in order for this to evolve, this is needed. And like I said before, and so these viewpoints, I think will help balance that as well. If it is swung one way too far, you know, we could definitely maybe help swing more towards the middle with more opinions. You know, but again, driving a prescribed method approach is really what I'm, you know, one mission that we're on the path to. Can I just clarify one thing? So I like the concept of having this matrix where, you know, there's people policy, et cetera, and then the different technologies and in some ways, I'm probably showing my age here, but it kind of does remind me a little bit of, like, the Gardner infrastructure maturity models from the early 2000s, where you kind of had this grid and you can kind of write yourself across different lines. But ultimately, we want it, we want it to be guidance, but it, you know, you mentioned the prescribed model, but I think in reality, organizations will probably travel down the different levels and the different categories at different places. So they might be, you know, like a level five on people and level two on scaling, for example, right? Or whatever. Well, and they might also be at say level five across the board for one application, but be just starting a new application migration where they're like, okay, we're starting again. So yeah, it is, you know, it is going to differ, which is why we're like, we're just trying to put the guidance there and the resources there. Yeah. And I think, you know, the one point that I think is really super powerful for organizations in terms of which parts to go down is to look at the ratings, look at the sort of the assessments across different categories, and see where you've got big gaps. Because in, you know, it's kind of okay that almost every org is not going to be a straight line out in the middle, right? You're not going to be like a level two everywhere or a level three everywhere. But I think if you have a big gap where maybe you're level four in scaling, but you're only level one in security, you're going to have a big issue. And that's going to hit you in terms of, you know, either people problems or team problems or other sorts of reliability issues or whatever else. And I think that's, that's the more important thing to kind of try and keep a certain amount of evenness, so that you're not more than two levels out on any particular category or whatever. So I think, you know, I think that's all valid points, Alex. In terms of next steps, what we all like you to do is look over the content we'll send. We can email you all the resources if you don't have them, or share them in the CNZF Slack channel for your tag. But we'd like to understand like, if you are going to go away and work on the spreadsheet as a tag group, or if you would like to show up to our bi-weekly calls, and we all work and collaborate together, we're open to either. We just want to make sure that all of you who showed up today stay involved now. We got you. You're here. You're part of the group. Welcome to the Chronographus group. I'd actually like to talk about involving some other people, because within Tag App Delivery, we've been kicking around the idea of spinning off in-app modernization working group, basically modern migrations. And it feels like the people who are involved with that should also be very involved with this, because they've already been kind of writing out the here are the stages of migrating. That would be great. And you know, that's, again, like we kind of reached out to all of the tags to say, hey, please get involved. One of you, four of you, so and happy, we'll have the recording of this, so that if you do want to share this with anybody on your tag, you can do that. Yeah, we really welcome contributions from anybody. Feel free to spread the word. Absolutely. And if you'd like us to come along to one of your meetings as well, we're all in different time zones, so I'm sure we can work something out there also if that's of some use. That sounds good. I think just speaking for the storage tag, we'd probably like to work on this from a tag point of view, I think. You know, we might break up the work between a couple of different tech leads to try and make work happen in a realistic time frame. Otherwise, if it's too big a task, it might be overwhelming. But yeah, I would love to work on this together. Is there some sort of timeline for this? So we don't have a specific set date, but what we really want to do is be in a position where we're going to KubeCon EU and we are going, this is the latest maturity model, the tags have been involved. So it's likely that we're going to have a maintainer track session. And so we would look to kind of present this there. And again, like in North America, the end user Katie made a big splash around this group and the maturity model. So we're assuming similar is going to happen at the EU event. So I imagine that means realistically we're talking about content that's ready for review around March time. Yeah, yeah. Plenty of time. So Alex, having worked with you, you'll be getting it like March 31st or April 1st. No, there'll be a good amount of team efforts here, I'm sure. All right, well any other questions? Any other comments? Well, thank you. Yeah, how do I email you as a group when I want to connect somebody? So we don't have a group email at the moment. But we do have a Slack channel, which is the cartograph working group, so you can or cartograph dash WG, so you can get us there. Otherwise it's got individual email addresses. Yeah, so my email address, Danielle and John, we're all listed on the repo. So feel free to email any or all of us and we'll certainly circulate it as appropriate. Yeah, no trouble there. All right, anything else? All right, thank you all for showing up. Thank you for joining our group now that you're official members. Everyone, I appreciate it. Have a good rest of the day. Thank you. Thank you. Thank you.