 Good afternoon everybody and welcome to this session evolving the Cloud Native maturity model. I'm Simon Forster, I'm the founder and director of Stackogy UK based consultancy on dealing with Cloud Native technology. I'm Danielle Cook from Fairwinds. We are some of the co-organizers of the cartographist working group, which you'll learn about more later. I'm John Forman, master technology architect, Accenture. I'm Robbie Glenn, a delivery manager at Accenture. Okay. So the cartographist working group was founded in 2021, and the aim was to help end users navigate the Cloud Native landscape and the wider Cloud Native ecosystem. So far we've been working on the Cloud Native maturity model. Cartographos, by the way, is Greek and it stands for a navigator. Every captain or Kubernetes or governor needs a navigator. You guys may or may not be familiar, how we started the project cartographist working group. It all started with an initiative where all of us had different models that we're working on separately. Then together we came together from the CNCF to create cartographists as you see today. But whatever we had seen beyond that was the current journey to Cloud Native. Where first, we had to be great for DevOps. You guys remember that? No, I'm sorry. Back up one second. Journey to Cloud was first. Journey to Cloud, when everybody's J2C, everybody's going to the Cloud, we save money as well towards the Cloud. Then it was once we were in the Cloud, then we got developed. Then the whole DevOps journey began. It was a big culture change for everybody that we evolved into DevOps. Then the third one was when Cloud Native was starting to become more of a Kubernetes win, there was a rush of Kubernetes to the Cloud. But when we're doing this though, there was no handbook. Just in this life, there's no handbook. Everybody crashed into the Cloud. Nobody went gracefully with a process or framework, they just ran right into it. So the whole idea of cartographists, it's to give people the framework to go to the Cloud Native maturity in a policy-driven way. Next slide. So why did we need a maturity model? We've already touched on it a little bit before. We have the landscape, we have the trail map. They're very technology-centric, and that's not the whole piece of the puzzle. Who's actually developing these stuff? Who's actually implementing it? It's a lot of people. How are they doing it, process, and what are they doing? What are they allowed to do? So we took a different approach, and instead of just focusing on the technology aspects, we wanted to expand that and include other pieces. So we have plenty of challenges. So first of all, we're thinking about very large companies. Usually that's the size companies that we're typically working with, but we want this to be relevant to everybody, including down to individual developers or people just learning Kubernetes maybe to bring it into their organization. Maybe they're not a practitioner themselves. We also, on the left side, we are trying to avoid crowning any kingmaker in the industry or anything like that. So we try and be very technology-agnostic or as high-level as we can. We do have to make some references to CNCF projects in some cases so that we have something to a frame of reference. So the maturity model covers, as we were developing it, we realized that there were some key themes that were coming out. And throughout this conference so far, we've been hearing a lot about people, process, policy, technology, and business outcomes, I think, is a major point that we cover. Within each of, within the model, we talk through these five themes throughout every level, looking at what do your people need to do? How do they need to shift culturally? What processes do you have in place today? And as you move to Cloud Native, what does that look like? What sort of CICD pipelines do you need to put in place? What workflows? With policy, we dig into what compliance standards need to be put in place? How are you gonna automate this policy? Technology, of course, is, there's this whole ecosystem. We do not, as Robbie said, we don't make recommendations of use this technology or that, but we do say you're going to need tools like this. And then business outcomes and something that came up as we were, we were involved in a CTO summit yesterday, looking at what should you be communicating to your bosses with the business, the board, and whatnot? Like why are you doing this journey? So the model covers all of these five areas. And then the levels of the maturity are around, there's five different levels. So build is all about you are in pre-production, you're figuring this out, you're trialing it, there's lots of proof of concepts in this stage. Operate is level two, and that's when you get to production. Usually that's around one application, you're trying it out, you're maybe not doing something that is business critical. Scale is when you are now scaling up, looking at how you can get more applications in the cloud native space. Improving is where you're looking at decisions you made around security and policy, and compliance and revisiting them and looking at, well, maybe we need to do this a little bit better. And then optimize is really when you figured it all out, which is the Holy Grail, and there's not many of us who are here. And you're now going, well, what tools have I created that I could perhaps give back to the CNCF, or where are there areas where just a small little optimization will really help us out? So there is, and I'm just gonna mention it here, the link to our GitHub repo that goes into this, and you can get all the details and read through it at length. So what we wanted to do next was instead of kind of just go through a PowerPoint slides and details, we wanted to actually kind of have a little panel discussion about each one of these stages. And we invite all of you to, if you have questions as we go through it to raise your hand, ask them, and we will answer as we go along. So the first level is all around building, as I said, you're in pre-production. So the first question we have, and I don't have who I'm asking this to up in front of me, is around what should you be expecting of your team in this stage? John, why don't you take this? Thanks, well, in the past, everything started where, everything was in the basement, right? Cloud native started in the basement and most companies were developers that geeked up on Kubernetes, on the cloud, all those great things. But as you get real with the stuff to go to production, to be serious about this, a level one, more to take it from the basement to production, at least begin the journey anyway. Automation, at least later on, but we first get there, it's baby steps, it's a marathon to sprint to what you wanna call it, right, it's one day at a time. What you expect in the beginning is just a lot of training, leveling up, bringing in the right resources, a lot of times our clients will, you know, trade up the current resources or hire from outside to bring in cloud native resources. So what you expect from the team is you're building the team basically at level one. It builds, it's build the team, build the process, build the processes. And you're really, it's upskilling a lot too, preventing people, I know that was one of the themes that came out of the CTO Summit yesterday where it's a cultural shift and that is almost sometimes the hardest part about going to cloud native. Well, it's DevOps as well, the biggest journey with DevOps was culture, right, this is no different. So next up is around CICD. So it's talked about a lot, there's a lot of sessions on that. So Robbie, do you wanna kind of tell us what we should be expecting here in level one? Yeah, I mean, you're not gonna try and boil the ocean, right? You want to start with things that are comfortable to, for you to operate. You wanna automate those things quickly, things that you're gonna do often. Certainly, you know, a lot of times, especially in kind of the build phase, you're gonna focus more on automating your deployments rather than some kind of integration step because a lot of times you're a small team and you might not really have any kind of integration to do really, but you wanna make sure that the managing, you don't wanna be running Qubes ETL apply all the time, for example, you want something to manage that for you, provide that consistency. So you really wanna focus on things to make your life easier, right? But anything that you automate is gonna improve your life later on, so. Awesome, and so we talk policy being one of the key themes. So Simon, do you even care about policy in level one? Absolutely. So every organization exists within a context. There are very few organizations that are starting out from a Greenfield estate. And also, particularly if they're in, for example, the healthcare or the financial services industry, they're going to be subject to a lot of external regulation. Likewise, if an organization already has a large amount of existing policy that is in place, for example, regulations around who has access to what systems, you're going to need to know about that. It's wise to be aware of that at level one. And baseline technology, what do I need to have in place? More than potentially we would have assumed. With level one, we are building, attempting to build cloud-native applications, and we are not in production yet, but we still do require Kubernetes. We'll still be considering our source control. Many of these things we may already have. We'll also need to be thinking about what about our network zones, our infrastructure, our firewalls, because for many organizations, particularly if they are using public cloud service providers, they're going to need to get all of that access in place. So there will be a significant amount of investment and tooling required, even at that very first stage with development. And I think the final point in level one before we go on is around what you should be communicating to the business. And this is where I think as an industry and as technologists, like we don't always do a great job at. So here in level one, we really, the maturity model talks about setting KPIs that the business understands. So they're not going to get the nitty gritty of why you chose to pick this tech over that, but they should understand, okay, because we're doing this, we're going to be able to ship code faster by X amount of time and we're going to measure it and that's what we're putting in place in level one. You might not have all the answers to that or all the metrics yet, but definitely spend the time to put the KPIs in place that your business leaders are going to understand. So if we move on to level two, this is around operating. So I'm going to go back to you, Simon, and ask around what tech do I need here? So we're in production now. This is the very first step where we read our application. Potentially a very small use case will be live within production. We will need to have CI obviously in place and a means of releasing. We may still be using imperative cube control commands, particularly if it is a very small installation, but you may wish to be raising your eyes towards GitOps even at this point. So will you be considering a GitOps operator, for example, or one of the CNCF projects that occupy this space? Likewise, RBAC and other components, they'll also need to be in place almost certainly as well. And Robbie, this next one's for you around policy. How is it evolving as you move into the second level? Yeah, so you're gonna have more policies. It's, you're gonna see actually over kind of the full journey, you're gonna see a big explosion as you get to like level three, right? Of technologies, of tools, of code. And then over time, you're gonna start whittling that down, making it a little bit more streamlined. So at level two, you're piling on the policies. You're adding in maybe something like a policy controller of some sort, and there's tons of policy types out there. We don't need to go into all of them, but I would say that the more that you know, the better, right? So of course, you wanna be adding your monitoring tools in as well, but having those policies at least, even in kind of a dry run mode, it gives you a lot more visibility on what people are actually doing, what they need to do to do their jobs, because sometimes policies can get in the way. And so in terms like related with process, so what is part of the process? Like what should you be scanning for as you're doing change control, you're doing logging, you're doing all these things, but like what is there things you should be scanning for in stage two, level two? I mean a lot of it is the same stuff that you're scanning for, you're not turning off your intrusion detection or anything like that. A lot of times it's you're providing defense in depth, right? So you're taking your firewall rules that you have maybe defined on your network and pushing them maybe into your cluster as network policies or something like that. So you're taking all of those things that your organization already does and really trying to apply them in the Kubernetes world. And that takes a lot of kind of iteration. Actually, for a second, I think in level one, it's about scanning the containers during build time. But a guide to level two, I just want to scan them at rest as well. This is when I begin to really build the policies around my repository is creating my golden images, right? This is where that concept gets started within that as well, about scanning at rest as well as build time. At the same time, starting the image also becomes part of the process too. Because if I don't start my image, why am I scanning it, right? So those processes, you know, I need a level two to start the maturity level to really understand what that means. Except if I don't do it now, when I get to level three or four, it's basically dead. So I have thousands of vulnerabilities at the point that I can't even repair. So you guys thought that it's level two. Well, while you have the mic, John, what should you be expecting of your team and people in this stage? Yeah, no, it's a good question. It's a great question. So level one is upscaling what you have. Level two, it's about becoming more about a master of your domain, really understanding the technology very well to become more fluent with it. Where now, you know, in stage one, you are becoming, right, a cloud native engineer. And level two, you are a cloud native engineer. You got to mature at that level to believe you are at that level to achieve these goals. The biggest thing with this also is new technology is always coming out, right? There's always a new version of Kubernetes, a new version of Istio and everything else out there. And level two, it's important also to see what's new that's out there. That's when the new thing's coming out, I'm going to prepare for this as well. And we know the Let'scape CCF is evolving every day. To say on top of that, a loan is on job. But level two is you really want to begin focusing on that as well. And how do you know, and this one's for you, Robbie, how do you know that you're actually reached maturity in level two? Yeah, so there's a big tendency, we see this at some of our clients, to say, well, we are 90% at level two. So let's just say we're at level two, right? No, you're still at level whatever that you are at 100% coverage of. So if you have all the pieces in place, except for your policies or something like that, then you're never going to get to level three, that's for sure. You're never going to be able to scale. You're never going to be able to see what's even available to be able to scale. So putting those things in place early is important. Yeah. So before we move on to the next level, I was just curious if anyone had any questions about level one, level two. So one point, I guess, to finish on that is, like for example, we're at production maybe with one app, right? By the time we get to level three, we want to be scaled or to start scaling, be prepared to scale, right? So it's not going to be just enough, okay, we got one app to production, we're at level two, let's go to level three directly, right? There's still going to be maybe a long time at each individual level, where we're building on what got us to this level, we're building on that and kind of providing that, spreading it out across the organization. So the next thing, we're ready to scale. So Simon, this question is for you and it's around scale. So what does it really mean? Am I scaling one application? Am I scaling many? We look at scale within this model as being both. There's a simple answer. Within level two, we're really focusing on a single application or a certain center of excellence within your organization already. With level three, we're looking at, can we scale out individual applications horizontally or vertically? Can we bring in the load? Have we developed the level of trust and confidence in our cloud native platforms to be able to do that? Secondly, we may be scaling out to multiple applications as well. And that's a really vital part of it. This is the level at which we expect to see the most complexity within the environment. So that's interesting. So how are you solving for complexity at this stage? And this is open to anyone, if I'm seeing it all. So one thing that we talk about with the people aspect is, now is the time that you're gonna really start thinking about a center of excellence. I think John brought that up. You really wanna take that knowledge capital that you've built. You don't wanna have, not everybody's gonna be a security expert. I mean, a Kubernetes expert. Not everybody at your organization needs to have the CKA, for example. At some point, you really just need operators or people, you might have even abstraction layers that keep things very simple for your end users at this stage. So how do you manage that complexity? I think part of it is just centralizing a lot of that knowledge capital in something of a center of excellence. It doesn't have to be a formal role or a formal group. It can just be a designation of individuals who really provide that thought leadership within the organization. Well, and there was one end user that we were talking to yesterday. And what they do at their organization is they provide these pathways. So as you want your developers using Kubernetes, coding, all of that, they put this path together and you can choose, I want path A or B or C, but you have to stay on that path. There's guardrails established around it. So here, Simon, once you've reached this stage, what are things, how do you communicate the value to the business at this stage for scale? As much as you possibly can. It's really vital as we have a lot more complexity within our state, we realize that not one single individual or one single group is able to do everything. Because of the increasing level of maturity that we hope you'll be seeing within your platform, you'll be able to really take advantage of, for example, the operator ecosystem that we have within Kubernetes. And good examples are making sure that we take advantage of that for our applications as well as our platforms. So are we taking advantage of operators for applications? But what is absolutely vital is that senior people and decision makers are aware of this and what this means. As I'm sure we've all experienced, when we've taken a very complex application and done traditional installations of it, it's been a very long drawn out project. If we're able to take advantage of the capabilities of the platform, a good example, let's say the Strimsy operator off the top of my head for Kafka, we can really deliver a lot of value. And senior decision makers need to be aware of this. When I think there, there was another session that we attended where it was if you think you've communicated the business value, you should communicate it eight more times at least, like people need to hear it and it's super important. So moving on, so there's gonna be a ton of tech that you have in place at this stage. But what are two things that you might not have had in place that you really need in this stage? And I can throw that over to any of you. I think at this point, you wanna begin to create templates for things, begin that process of actually putting things to code, right, at level four, at that point I'll get there, but at level three I gotta be getting plenty of seeds to create my templates. Whether it's for a Terraform or my policy as code for Oprah or maybe I think starting that process right now with the policy as code, level three is critical to getting to that level. I have the skill also where I have multiple fleets or if my strategy is multi-cloud, which every client today, every company today is multi-cloud. Nobody's going to cloud anymore, right? So now if I have multi-cloud, that makes things complicated to extra more. So wouldn't it be kind of cool to have policies where everything's driven from one area that could push out to multiple clouds? So level three, I'm scaling, during scaling I gotta think about multi-cloud as well. What was my multi-cloud strategy? That's critical level three as well. Right, so just conscious of the time, we're gonna move on to the fourth level around improving. And so kind of starting with you, John, here. So what does it actually mean? Like what am I improving? Good question, Danielle. So level four, what you're improving is, we're from level three. So if you look at the training model from one to five, okay? Most clients are on level two. Of course, when I speak to them, they say, John, I'm on level four. I go, no, you're not. You're on level two. Most of between seriously between one and two today. But they want to get to a four to five to really become at that level. Level four was improving things. I started to do more things on scale. I could take my deployments now and begin my blue cream canary or my blue deployments at that point. Also, doing a multiple strategy again at scale to be able to push more policies across multiple ones. What it means to prove at level four is to be able to get my curious code up to par along with my ghost model. The set of excellence that I began in levels two and three is not becoming more mature as well. Or more processes, more procedures, more documented, whatever the conflict, whatever it is. At that point, everything is well positioned to the area right now. And so when you were talking about policy code and level three and this question's for you, Simon, and it's around, so now if I have some policy in place, like could you give me maybe an example policy or maybe not? And talk about how you enforce it at this stage. Because I think that becomes really important. We would hope that by the time that we've reached level four, we're really taking advantage again of the automation that we have within the platforms. We do have projects within the CNCF. We know of OPA. We understand gatekeeper. We have all of the admission controller ecosystem within the Kubernetes to take advantage of. We would expect to make sure that nothing that doesn't meet our policy requirements is able to submit to production. We would be enforcing this. And it actually helps us improve. It's actually part of the improving process because then we can unlock things like self-service. Like I just think if you could not have to pay a bunch of engineers to build your tools, you can just have them, your engineers fill out a form somewhere and something automatically takes care of it and it's all within your security and compliance. Well, I'd like to think about that as Kubernetes guardrails. So we're letting devs safely develop within the guardrails that we're giving. So I would like the picture of bowling where you have the guardrails and you can get the ball down and it gets there. So it's a good thing to make sure you have those in place when you're here. So now we're cruising through level four to level five around optimization. So you have people in place and you have gone through all this. Like what do I expect of my people? How have my teams evolved open to anyone? I guess it's open to me. Level five is where I'm fully mature. Again, a lot of interaction by people and our experts. And then that's SMEs. So I did my experts at this level. Now there are SMEs graduating from level one to level five at that level. So you expect at that point, for your staff to be experts in cloud native to take things to scale, anything new being developed is now cloud native. VMware and legacy stuff is now dead or it's dying anywhere, poor, sick death. But any new development is anything greenfield at this point is definitely going to be cloud native. Now with that it can be fully automated as well. And so Simon, I'm gonna go back to you for a second. So Simon works in heavy regulated industries. Leave it at that. And so now you're at level five, you're optimized. What about compliance? Like what are you changing in this stage? Our hope and our aim is to be able to see both internal and external regulations really reflected within the policies and the compliance that we have within our cloud environments. We wish that we want to be able to see all of the, I think that's probably the most important takeaway. And we would like to see regulation in code. And kind of final question on this stage is around how the tech stack has evolved. And we talk about how here you're revisiting decisions you made maybe in level one and level two. So are you contributing codes to projects or are you selecting new vendors? What's happening here? And that's open to anyone. I think one of the biggest things any company today is technical debt. Technical debt will start your growth to be cloud native. We all know that it's reality. But yet we have four, 10, 22 that do the same thing in our landscapes. So when it comes to tech evolution within my process of one to five, at level five, I'm gonna get very lean. I'm gonna start cutting that, trying to out technology basically at other levels. At level five, technical debt should be none. At the level where I have, you know, the best of the tools running my environment. So as my tech evolves, I need to take that point. And also keep in mind that most clients will not be a level five. I'm sorry to say that. If I'm Spotify, I'm born cloud native, technically. So I'm at level five. But most companies today, most clients say go into cloud native, later live between four and five, right? And possibly even closer to four. Because you still have the legacy in the background doing certain day-to-day certain processes to really not give you that entire level five. But at the same time, you may have different work streams. Some applications can be level five. Some may be level two and three and four. Don't think that, you know, it's all or nothing. It's not like if I'm at level five, everything's at level five. I can also mix with my environment as well. Awesome. So now we're gonna pass over to Simon to talk a little bit about where we're evolving the maturity model. So for us, we, this is an open, this is a CNCF initiative. We are a group within the CNCF. And we would like first off, we would love contributions. We are looking at publishing the artifacts. Right now they're in GitHub. Within our GitHub repo, we're looking at incorporating them into the CNCF website. We will also be continuing our partnership with the tags in order to go and reflect their work within the model and also assist them where they wish to go and baseline their technologies, processes, and people as well. And we would also like to get to a stage if possible of implementing scoring in code. We'd like to take ourselves to level five if we possibly can. Well, and I think what's really here if any of you are on a tag or whatnot, we wanna make sure that the maturity model becomes this repository of I can go here and I can access all the amazing content that everybody's working on because I think sometimes within the CNCF we think people know that something exists but it doesn't. So if everybody could use the maturity model and go there and be like, I know I'm gonna get the resources from tag security because there's links through in here or whatever the tag is. So that is the ultimate goal with this. So we'd really like you to check out the repository. It's on GitHub. We would love to see your issues and if there's anything you'd like to see changed, feel free to submit a pull request. We also hold community meetings every second Tuesday at 1 p.m. US Eastern time and we're also on CNCF Slack. We'd love to continue the conversation with you as well. And if you don't already have one we've got a pile of brochures up here and we also have a booth in the Pavilion era in the Project Pavilion. Thank you. I just wanna say one more thing. If anybody adopts the kind of graphics in their environment and actually have it running successfully, right? We invite you to understand what's with us to present it and that would be really super cool if somebody can do that, right? I would love to see that happen. I should do a use case of this model in real life. Now we've done it individually with the science and working models but I should take it from zero to hero of the strategy and it would be super cool to see. And if we do that, we also find the deltas and the gaps in our models as well. Something to think about.