 Good afternoon, everybody, and welcome to the introduction to the Cloud Native Maturity Model from the Cartographos Working Group. My name's Simon Forster, and I'm director of Stackogy. And I'm Danielle Cook, and I'm a VP at Fairwinds. John Foreman, director at Accenture. And Robbie Glenn, a manager at Accenture. So the Cartographos Working Group, just to give you an overview of who we are, we were a group that came together last year to try and provide some tooling for the end-user community on what is this Cloud Native landscape? How do you navigate it? And we're a group that works. We meet regularly to talk through different pieces of content and really provide as many tools as possible to get people into Cloud Native and using it successfully. Our first piece is the Maturity Model, which we're here to talk to you about. Yeah, so why another model, right? We have the landscape. It's very good. We have the trail map. It teaches us how to get to Kubernetes, right? Well, the landscape is very hard to read, right? We have an interactive model where we can dive into bits and pieces, but it's constantly growing, it's constantly evolving. How do we keep up as an organization? How do we plan over two years while the landscape is exploding? The trail map is great for technical people. It's not going to be the right tool for business, right? And we have to incorporate our learnings from growing Kubernetes at different organizations so that we can take that knowledge and share it with our other clients. So it goes beyond the technology. So there are five stages to the Maturity Model. We have level one, which is build, level two, operate, level three, scale, level four, improve, and level five to optimize. It's important to recognize that at level one, where we start the journey is not a baseline. It's not a baseline of zero. You're not starting with nothing. Rather at level one, it's pre-production. Nondevelopment, we're testing, getting, starting to understand Kubernetes and related cloud-native technology. Level two, operate, is the first step into production. So Kubernetes is there. It's implemented. Level three is for scaling out. This is where really the organization is committed and well on its cloud-native journey. Level four is improve, where we get policy, process, and governance are really in place. And with level five, where we optimize, we're really looking to further incorporate developments that as the cloud-native landscape further matures and grows and really looking to cast our eyes into the future. Each of the five levels of the Maturity Model, as we were pulling it together, we realized there were key themes coming out. There were journeys that the people had to go on. What skills do they need? How do they need to establish their team and their framework? We saw a theme around policy. What do you need to put in place for compliance? What security regulations do you need to meet? There was the process of, OK, how are we going to organize our workflows? What are we going to do with CI-CD? And then there was the business outcomes. Why are you actually doing this? And in each stage, what should you be able to demonstrate to your business leaders, to your board, to your C-level, all of that presented itself? So within each of the five levels, we go through these five different areas. So Robin mentioned Maturity Models and Frameworks, all those great things. That's nice. But what we want to talk about is the journey. What is your journey to cloud-native? The CNCF is great with doing a great incubating new projects to production. But how do we take these things, actually, through something with it once it's out there in the world? So in the past, we had journeys to the cloud, but journeys to DevSecOps. But now, it's journey to cloud-native. And this has to be the discussion, is how do we get to cloud-native? And as we do this, though, one important aspect is technical debt, is that this early in the stage is you have to go through your landscape, understand what tools am I going to take on this journey in my new luggage, and what luggage am I going to leave at home? Only take what I need. Otherwise, it'll get more complex, and you're never going to get to the next journey level if you don't remove your technical debt. That's one thing you want to begin looking at early on in this. Another thing also is you want to start building a model for governance, right? Process procedures in your new stages. Because once you get further immature, you're going to really fall flat on your face, which I see every day by clients, by the way, they can't get to the next step because they didn't do it the right way. And you got to breathe, take a deep breath, and then go for it. Don't go straight from zero to here, it won't work, okay? And then, you know, also in your new stages, be manual. Don't go crazy in automating a day one. You'll get there, but right now you have a lot of gaps in your skills and your environment. So don't go too crazy, let's just begin this journey the right way. Yeah, by level two, you are moving into production. So you're taking all of those skills that you've built in level one, all that governance, and you're really trying to take that into production, and bring some value that you can show to your business that Kubernetes is real, we have this competency, and we can really change our business with this. There's gonna be a focus on still smaller teams, cross-functional teams, very bright people, right? And you're gonna get those pockets of strong skills in those cross-functional teams that you're gonna build your competency on, and that's gonna lead you to level three, which is scale, right? And it's not talking about scaling your workloads because you're already doing that, you're already in production, right? So we're talking about scaling your teams. How do we replicate this knowledge that we've incubated, right? And take that to other teams within your organization, how do we grow that, right? And so that's gonna be a bunch of different things, but a lot of it is around standardization, those very bright people and those cross-functional teams, they're going to be elevated to almost a center of excellence and they're gonna build some standardized tools that we can share with the rest of the organization so that they can bring themselves up to that level of skill very quickly. There's also going to be a heavy emphasis on the business side of it, because now this is something that we're able to use as our primary driving force behind our compute and the business has to be on board and really buy into that. So at this scale, what we did was improve, right? And on this journey, things, again, it's real. It's getting real now. I'm really becoming cloud native in my environment at this level. And I'm also being very competent with Kubernetes with cloud native. My staff is getting the skills in place, they're feeling more comfortable with new technologies and we're really moving ahead where we need to be. And at this point, I'm beginning to kind of level off. I'm very comfortable at this level. We're able to really scale at this point and really go full production, we're full DevSecOps and everything else that's going on. You can kind of consider this as you talk with state. When we talk to people out there in the industry, this is kind of where they want to hit. This is the goal is to be at this level. And during the process, you can even do things now, I can manage my things now, I can manage KPIs. I really measure things to see where we are really improving. Is cloud native worth it? Why am I here? I actually measure these things now. And the really cool things that I'm saying right now at this level is in the past, I would go to CXOs, they'd go, John, open source, get out. But today it's changing. They're not becoming the thought leaders now where the CEOs and CXOs have lost corporations are the thought leaders for cloud native because they went on this journey and they're adopting this today. And so it's kind of, from the basement, now it's gone to the water room completely at this level. So in level five, it's about optimization. So you have gone through the journey. You have made a bunch of decisions. You have improved those decisions. But now you've reached your master level. Your team is skilled. Everybody knows what they're doing. But you might have made some decisions that aren't necessarily the right decisions that you want to revisit. You might want to be looking at or you will be looking at, how do I automate as much of this as possible? You'll also, at that point, be figuring out what the new tools are in the market. Like we are rapidly evolving. There's new projects all the time. So you'll be revisiting those and looking what do you need to add to your system, your environment. And really here, this is where we want everybody to reach. And hopefully many of you are like, ah, I'm doing that now. Everything's good. And this is where we want contributions back to the community. What have you developed in your environment that you can give back to the CNCF or add to a new project? Join this working group. There's plenty of things to get involved in. The experience you have at this optimization phase, this level five, is vital to share with the community. So moving on, we start thinking about what are the challenges that we face. And there are a number of them. So first off, we have to be really careful about not picking champions, particularly amongst the CNCF and its projects. All of the projects that are there are there for a specific reason. And we cannot run the risk of attempting to infer one project over the other. That is absolutely not what we are setting out to do. Secondly, this model may fit an organization that's pretty large, might fit a Fortune 100 company. But we also need to make sure that it might cater for small or mid-sized organizations. And if we think about what is contained within it, it might even be relevant to individuals. We really need to keep making sure that the model stays relevant and changes. And then finally, we want to keep up with the leading edge of technology and what the CNCF has as its mission. And this means that we need to have contributions from people. We need to keep it fresh. And we would really like to encourage and invite all of you within the cloud-native community to contribute to this. We have a few next steps that we've outlined. So we want to look at the model. Is it still relevant? Do we like the structure of it? Is the layout adequate and will it age? We have a number of published artifacts. Everything that we've done within the working group is within the cartograph of repository in the CNCF organization and GitHub. And we do have a series of reference documents there that you're very welcome to read. And we encourage pull requests and issues as well. We'd love your feedback on that. We'll also be looking to integrate the model into the CNCF website, cncf.io, alongside, hopefully, the landscape and its guide, as well as potentially the trail map, those areas for future development. We also need to continue our ongoing process of outreach to the tags and to the projects within the CNCF. Again, we require their input. It's vital that we reflect them appropriately. And then finally, we are looking to implement potentially some scoring to look at how can you rank your organization or where you are amongst these key areas and amongst this level to help you in your own journey. So with that, it's also called for action as well. You may be thinking, you know, John, Robbie, Daniel, Simon, I'm not very technical, but I do want to contribute. The beautiful thing about this is it's documentation. It's not coding to build this model out. So everybody here in this room and whoever's listening from the interwebs can also contribute to this and we invite you to do that. You know, we have some new members as well to introduce. So we have from the top down, hopefully I pronounced your names correctly with my Brooklynese accent. And Elisa, Mochello and Jonathan. And your faces could be up here also next time but we do this as you guys get more involved with us as well. So welcome to the members to us. Yeah, I just wanted to echo what Simon and John said. Please join us. We need input from every level of organization, every step of the journey. We could use some help, so. We've just done a whistle stop tour, like the fastest speed dating version of this maturity model. There is a lot of material behind this. So you can go onto our GitHub page and there are, right now it's separated into the prologue, the people, the process, the tech, you can dig through it. We added business outcomes to it this year, so that's new in the model and we have been refining it. So there are a ton of links available but if you just go to our GitHub page you'll be able to get that and definitely get a layer of more depth than what we've talked through today. So just as a few final notes as well, we'll make sure that the slides are uploaded so you'll be able to get a copy of those. Furthermore, we have a little surprise here. Did I mention I'm an author? I may have mentioned that once or twice. Well, so is everybody else on the stage. So during this process, we actually wrote a book about this maturity model to make it more fun and if it'd be a friend's adventure, definitely go buy the book at this bookstore and maybe, if you're lucky enough, we've got to show up and maybe sign the book for you as well. Okay. We do have a booth here at KubeCon. It's within the CNCF project area and we'd love to see you afterwards. We do have extra printed copies of the model for those of you who didn't receive on when you came in. We have stickers and of course, if you have a copy of Admiral Basher's Island Adventure, we'll sign it for you as well. And with that, we're open for questions. Let us know if you have any questions. Feel free to, yep, we'll pass around a microphone. Thank you. I guess maybe a question for John. You said that you spoke with a lot of CXOs that when you say open source, they're like, no, get out. So I'm just wondering what were the conversations you had to have with them to convince them to take a step on this journey? So remember back in the day when everybody used to say, nobody got fired for buying IBM? Remember that? Well, I started to say nobody ever got fired for buying Kubernetes. And they said Kubernetes. I said Kubernetes. And I started the conversation with them, trying to position it at that level. It was, in the beginning, it was very difficult. In the beginning, the developers were making the stuff fun in the basement. And on top, they're like open source, we don't want it. It's scary. We're very comfortable doing this. People don't want change, they don't like change. But it was kind of forced to happen. I think that the developers really drove that to happen as well. I guess there's a follow-up question then. The reluctance, the scaredy-ness of open source technology, like, is it within the remit of the cartographos? Sorry. Group to kind of dictate parameters on specific projects itself, or is that something that's off-loaded to the CNCF incubation process? So we've tried to stay away from saying, this is the project you should use. Yeah, I don't mean a specific project. I mean, like, attributes of a project, like governance, like documentation, like these things that help convince the CXO to invest in CNCF. So that's why we added the business outcomes to the section. So we could, each area, we could say, this is how you need to be communicating the benefits of this. So that it isn't, it's some guidance that can inspire some ideas so that when you're starting on your journey, it might be one person, two people, a few people who have played around with some cloud-native tools and now they want to take it to the business. We have provided that language in it. Specific to the point of our relationship. So the charter of this group is that it does not in any way attempt to dictate to the CNCF any technical decisions or any decisions around projects. So we explicitly do not participate in that it's not a role of this group. It's rather to assemble artifacts to help in communicating that. So we're there to help provide what the CNCF already does in a format that might be helpful. At the same time, the model that we have here is attempted for a governance model. So as clients, as you guys, and your friends and families adopt cloud-native, you actually use this as a launch pad for your model of governance. It's already there. It's a cook and cook approach and from our knowledge and industry, it's very solid, we think. Of course, we need people to update and contribute as well, but that's what we're going for. And I think we draw from the group, the different either working groups and SIGs and the projects themselves. We invite members of the project teams to tell us how to incorporate the pieces of your project that are going to really bring value to the customer. So again, we're not making any kings, but if there's something new and valuable that we can incorporate as a feature, I think that that's really important for sure. Now, nobody can believe this room, by the way. You can pronounce the name of the group, by the way. So we're probably going to be checking that out. So we might be here for a while. A while. What are your thoughts and experiences regarding implementing this model in organizations who have similar initiatives like the OVASP SAM or the B-SIM? So are you suggesting building a custom model that integrates all of that, or would you recommend tracking this independently? Do you want to take that on this part? I think if you look at those models, they were not born in the cloud. This is born in the cloud. That's the difference. So if you take those initiatives, you can have, it's going to be very clunky, and you can make a wedge fit in a round hole, or a square peg in a round hole, if that's going to go, versus something that's built for the cloud already. Right, so it's kind of like, you know, that's one framework. Other frameworks, of course, will work with those as well to incorporate that as well. But I think this gives you that framework, you know, to be cloud native first. Because to me, that's critical. Because many clients fail today, going cloud native, because they're going back to the rack and stack, they're going back to all policies and procedures. That doesn't work any more cloud native. And the way the model was built, so the reason it's us sitting here, is we had all put together different maturity models, looking at it from different points of view. And so we came together from our skills at our organizations, having built environments for companies, and scaled them, and said, like, well, what are the common things that have happened? So with all of the three different models, we were able to pull together this kind of one umbrella, from experiences at our organizations. Great, thank you. I think there was one more over here. Oh, yeah, thank you. So obviously, software security is a big hot topic right now, and there's a lot of different efforts going on. So there's like the open SSF and the supply chain stuff, and there's this. How much do you all talk to each other and sort of try to dovetail your recommendations versus each working on your own piece and getting your own assessments? So two years ago, I led the group to create the CKIS exam. I actually, I spearheaded the development for CKIS, because of all the knowledge I have based on these things, and so I worked obviously with, I let them speak as well, but we kind of fused that knowledge along with our best knowledge to create that. And the day your security supply chain is very critical, security is never a first-class citizen. Even today, we speak to clients, they forget about security. It is never, it needs to be a first-class citizen, and that is a big part of our focus as we do these things. And you know, it's, you know, supply chain, if you go to KubeCon today, everything is about supply chain this year, as you score these, but... As part of our process, we reached out, so we did our initial launch of the cloud native maturity model, and then over the last six months, we met with all the tags and presented it to them and invited feedback, help us out. You're the expert in security, you're the expert in storage, whatever the tag group was, and so we're trying to get as much feedback from the tags as possible because we aren't the tag on security, so we need that input. And what we want to do, the goal, is to have the cloud native maturity model link to all of the content that the other organizations or the other groups within the CNCF are creating, so that as a user, you can go and go, okay, I understand that this is where I should be on my journey, here's this paper from the tag security, here's this paper from the tag storage group, and it's this kind of master repository, if you will. My question was actually slightly different than within the CNCF, it's that there seems to be a variety of different Linux foundation foundations, which are all tackling aspects of the security model, and so for example, if you're trying to do reproducible builds and things like that, maybe having features in a cluster make that easier or harder. If you look at those SolarWinds incident, they were compromised by malware that was sitting on the machine and was listening for MS build processes, and when it saw a particular build process, it would sub in the source files during the build process. What's the question? The question is how much are you talking with outside the CNCF, other organizations that are worried about security? At this point, we haven't conducted any presentations with the OpenSSF as a good example. We would really like to incorporate feedback and information from the OpenSSF. So... I was also wondering if they were incorporating your suggestions. Yeah. We'd love it to be a two-way street. Yeah. Thank you. Absolutely. Any other question? Question in the back. Thanks. I found your point about not picking a champion quite interesting. So if the project isn't a priority within the business of the company, how do you gain that resource allocation above other projects? I'm not sure I understand the question. Also, maybe I misunderstood the point. So, well, so within what we're trying to say within the model is there's all these cognitive technologies out there amongst the people, the process, et cetera. And so we're saying you need to look into, for example, CICD. So you will need tooling there. Or Kubernetes is absolutely mentioned in the model. Helm is absolutely mentioned in the model. We've incorporated the graduated projects, but when it comes to a sandbox project or something that we know you need to put policy in place, we're not being prescriptive with what that project might be. Exactly. Exactly. Yep. So we exactly, to that point, we don't specify and say you must choose OPA or Coverno. We don't specify those projects. Nor do we do, for example, Flux or Argo or attempt to infer one over the other. That's not an appropriate thing for us. What we can suggest is consider GitOps. Yeah. And it's something that I meant to mention and I even started in my notes and I forgot to mention when we went over this. But at level three, you're going to see an explosion of tools. You're gonna be trying different things. You might try directly Flux against Argo. You might try different ways to secure your supply chain, right? You have your center of excellence trying out different things to figure out how best to get to that next level of spreading, you know, of Kubernetes being the way that you deliver all of your workloads. Nobody ever said Kubernetes was easy. I don't think they ever said that. Yeah. You know, I've seen over the years people struggle with Kubernetes quite a bit. They don't get it right the first time. They try different tools until they get it. You know, but at the end of the day it's about industry best practices, industry best solutions, what all they, who knows what that even means, right? It's an opinion. But it's about the process. If you follow the process, most of the tools are gonna be very similar in the day anyway during this journey, as I'm calling this. And it's about, you know, again, the CNCF great job of creating this ecosystem. But now how do we manage this ecosystem? How do we go from zero to hero? How do we actually implement it? We need some kind of tool book to do that. Some kind of run book was hoping what this will be and become a standard. I want this to be the standard for the CNCF. That's my hope. Because we need it. We need something. We have a question here and a question here. I know. Mm-hmm. Okay, you step in. Thank you. Do you have any examples of companies or organizations that have successfully taken these recommendations and applied them and had good outcomes or are we like early on in this such that we're still kind of developing those examples today? So it's definitely early on in the development of implementing this and people being able to find it and use it and all that, right? That's part of us making sure you're all aware of it. I think what we all can say is we have been using it at organizations and that's why we created it because we realized that there were certain steps that an organization needs to take to get to, you know, a mature phase of this model. Over the last eight years, our center, you know, as I begin robbing up and creating this model, you know, the third one of the three, you know, we've implemented several clients already and it works. That's my answer. I can't tell you who they are, but. Right. Because I wanted to know. That's what I wanted to know. I have to tell you what, yeah, that's what we got here. Thanks. I think there's a question here. Thank you. My question is, if I understood it right, target audience is business in the end, right? And because things like a scoring model and everything like that is more targeting to CIO, CTOs and those technical management area more or less probably, but in the end, business wants to deliver value and right then, if they see benefit out of it, they want to deliver value faster and so on and so on. But it often seems that the optimize phase is never ending, right? Because there's, right, we had good ops, we have DevSec ops, and there's the next thing is coming in, right? And you cannot stop optimizing or even reworking your whole model. And in the end, there is no benefit for business because you keep doing so. And that's what I'm wondering if the target audience is still the business. So the target, we want this to be useful to a broad range of audiences. So if you are reading the in-depth information, there's a lot on the tech side. There's a lot on the process side. So depending on the areas you're reading, it is meant for a number of different stakeholders within your organization. I'm talking about business a lot because that's our newest area. But we also are, the way we put it together was so that the technical person can communicate to the business the value, right? Because it is very easy to be like, I want to do this cool tech. And it's always, I'm always gonna be working on, I'm always gonna be improving it. But there is, I'm gonna necessarily be beginning and end, but there is a journey to get the main value out of adopting Cloud Native. One problem that I see clients is that they'll start with one version of something, maybe OpenShift to give you an example. And then next year they go, oh, maybe EKS. Next year, how about AKS? And then next year, how about Rancher? You can't do that, right? You gotta go on this journey. Every time you do that, you stop and you start from number one again. One thing I can say to everybody is that what I've seen, and I've seen this a lot out there, is that people keep going back to level one again, right? They start Kubernetes, they start Cloud Native, they start going on the journey, but then some yahoo in the company says, hey, I want to replace this tool with that tool. And now the drop in the maturity amount. That doesn't work, you can't stay in that. Do you really, you have to be able to understand what is my future look like? What is my future direction, right? And if I'm on Kubernetes, that's great, let's make it happen, but you have to be able to understand how could I keep my maturity going and not go backwards? That's something I'm hoping that this maturity model will help to give you that path. There's also the challenge that I don't know, I'm sure that you've faced as well, that we face is that our clients want to be at a certain maturity level that they're not at, right? But we're in production, they say, and we're like, yeah, but you missed all of these steps before then, so this tries to bridge that gap and makes those conversations a little bit easier so that they have something, we have a frame of reference to point out in point two, so. And you might, one thing that we didn't mention earlier was you might have with one application reached maturity and then you decide you want to bring another application along and you're like, yeah, we're starting from maybe level two, maybe you've like advanced it, but you're gonna, as you migrate everything, it's gonna evolve and you might be at different phases at different times. It's that parallel, it's more linear than anything else. One final point to add to that as well is that we hope that this model also evolves and this is where we really also encourage the community to help us to continue to make it relevant. We started drafting this a year ago and then over that period of time, we've seen a significant amount of change within the cloud native landscape. So again, on that point, we'd love to invite your involvement and specifically for those of you too who don't feel that you're technical enough to contribute to a CNCF project but may have a lot of skill on the people, process or policy side, we'd really love your input too. It's five minutes past the hour. I definitely think you're gonna join, right? I can tell you're gonna join the group. So with that, if we can all thank you for coming along today. Thank you. Thank you.