 Hello everyone. Thank you for coming. We're here to talk about the cloud native maturity model. Yep, welcome to this maintainer trait session of the Cartagraphos working group. The group's mission is to provide artifacts to help navigate the cloud native landscape. And our first deliverable has been the cloud native maturity model. This is a maintainer session. We hope you'll be familiar with the maturity model, but no problem if you're not. We'll provide you with some information and also go through the latest updates. For those of you who aren't familiar with the model, we'll go through it. So my name is Simon Forster and I'm a co-chair of the working group and I'm a technical architect in financial services. And I'm Danielle Cook. I'm also a co-chair of the Cartagraphos working group. I run a virtual event called cube crash, which promotes a bunch of open source technology. So if you're interested in that, that will be happening in a few months. And I'm a VP at Fairwinds. So just to give a quick background on the Cartagraphos working group, so we launched this working group in 2021 with the goal of trying to provide a map, if you will, of how to adopt cloud native technologies. So really the driver of getting more people to adopt it. So we have been around for a while. And to kind of set the scene, we're going to give a little background about the maturity model. So there's five main levels that we go through with this. We have the kind of baseline that you've already decided to go cloud native before you even pick up the maturity model. So we're not starting from a point of should you do it or should you not. But the five levels are starting at build. So that's where you have kind of a baseline environment, but you're not in production. You're trialing it out. Lots of POV is trying to decide if it's for you and your organization. Level two is where you actually start operating. And so you move into production. You might be doing it with one application, a few applications, but it's not not scaled out yet. You're still proving the model to your business. Level three is really when you do start to scale. And that's when the organization has become fully committed to cloud native. Level four is where you start to improve all of those decisions you made in the very beginning. So you're looking at security, you're looking at compliance, you're looking at your cost, you're looking at all of those things and trying to maybe fix some of the things you made. And then finally at level five, that's really, we've renamed it to adapt. And that's where you're starting to adapt what you've done to further ways of working. So when we were building this model, we took several different models and pulled them all together. And what we started to notice that there were some key themes that came out and different patterns around people, process, technology, policy. And then we did have a subset of business outcomes on it. But it didn't really go truly into depth there. So as we started thinking about this presentation, we were thinking, okay, we don't want to just present the full maturity model, but we want to talk about kind of the main drivers for changing it. So there's lots of vendors out there who are just promoting, hey, ship applications faster, go cloud native. But we all know that maybe that's not necessarily the thing. Like maybe that's not the reason you're going to cloud native. So maybe that is not the benefit that you should be communicating to your business. Because reality is like going faster isn't necessarily the right thing to do. So as maintainers of technology, some of you are maintainers of open source technologies here, as trying to put this together, we wanted to make this model more about your goals. So if anybody has been watching the Beckham documentary or maybe you're a soccer fan or a football fan, however you want to say it, it's all about the goals. And so really cloud native and all of us need to do a better job of communicating the value of cloud native in terms of what the business goals are. So one of the first things we wanted to mention is that technology goals need to focus on the business outcomes that are expected. So outcomes are not just faster for its own sake, but rather they are to meet business demands while mitigating risk. And one thing that we noticed is that we can consider risk as being like the gravity, the opposing force to a business advantage. And so for every advantage, there is an equal and opposite risk if you want to go that far. So we then considered that we needed to have a much more in-depth review of business value that cloud provides. So you can see here the cloud native Parthenon as we have dubbed it just for today. We might be technologists, but in reality we're really serving a business. We do this through products and services that need to be released. Okay, the shipping faster. We do it to serve stakeholders, such as our sea level and our boards. Or it might be something just a little more ephemeral like a business model and simply serving competitive advantage. Either way, as technologists, we have to serve a business. And organizations don't want to just ship faster. We need to get products and services to market faster. So what we've done is just recalibrate or reorient the cloud native maturity model to really focus a little more on business value first and foremost. And then those outcomes are then supported by the people, process, policy and technology pillars that we see reflected here. So if we imagine ourselves sort of walking up those steps for our Acropolis, each step represents where we are within our cloud native journey and each of those pillars is one of those key areas that we will be levelling up and ideally at the same time, not always. So, oh, my mistake. We've now launched version three of the cloud native maturity model and this has gone live on the CNCF website. And we're going to walk through the five levels and show some of the new business value messaging. And you will find this new content at maturitymodel.cncf.io. So if we dig into it a little bit, we have a prologue section within the maturity model microsite. And we have a, in the prologue, the introduction, we've now included a summary table that outlines several examples. We've got two business to business examples and also business to consumer example. And what we can see here is how the business models reflect, again, people, process, policy and technology, they are still there. But we also start to emphasize key performance indicators. So in this table, we can provide examples of each, for each business model of a KPI for a given goal. So in our first example, we can see a business to business model with acne software sowing into the enterprise market and they have to demonstrate security and compliance and their KPIs will be around, say, vulnerability counts. We can see in the second row, KPI, zero policy violations. So we start to bring this out and start to attempt to give some concrete information on what to look for. Moving on as well, I just want, we can reiterate that as we look further down that chart, we can see process, policy and people remain key dimensions. And we can see that in the first column. So now we're going to dig into a little bit on each of the sections. And again, the business outcomes, you can totally go look at it on the website and see all the different levels on the tech and the policy and the people. And it's definitely worth reading. So last year when we were in Detroit, we sat in on the CTO summit and the clear thing that came out of the summit was that organizations need to understand what tangible benefits they're going to do because cloud native isn't just like, Hey, we're going cloud. It's cool. It's no problem. It takes a lot. And there's a lot of organizational changes that need to happen to make it real. So when you are in level one in the build stage, those are some considerations you need to take on. And that's why it's so important that this business value is communicated. So the first kind of point that we wanted to call out in this is really around prioritizing your goals and your issues. So what we find is that, you know, people want to do it. They want this technology that they want to use this open source project, you know, they want to need to get new resources and whatnot, but really you need to truly understand and prioritize the application you're moving first or what you're doing. And then also what tradeoffs you're going to make. So we go through in the maturity model, giving some examples of those. So in the build phase, you might have, you know, an application that you're like, we're going to move this one, we're going to trial it out. And our goal here is to improve customer satisfaction, let's call them one. And so yeah, you're going to go, what's our strategy to do that? We need faster response times. We need to make the customer happy because they're not waiting, whether it's internal or external. And then, you know, the technologist is going to go, okay, well, let's look at the tradeoffs. Like, so do we put it in a closer cloud region? Do we use Kubernetes at the edge? Or, you know, but those things are going to be expensive, they're going to take longer. So let's talk about expense versus the actual goal. The middle example is around cost effectiveness. So being able to communicate, hey, we know we're going cloud native because we want to do a cost reduction exercise, but like, it's not going to be cheaper first. So what does that look like? Okay, we're going to move to a cheaper cloud region, but we're going to have slower response times. So really here in the build phase, you need to understand those. You need to communicate the tradeoffs, but you need to communicate the tradeoffs in a way that does not just sound like, well, we want to use this technology and it's cool because it's cool. And actually speak the language of the business. The other thing we've done in the maturity model now is within each section, we've called out a cost area. Because I think that people say, we'll move to the cloud, it'll be cheaper, it'll be fine, but we know that that isn't the reality. So you need to have alignment on this is going to be expensive before it is cheaper, or we are, we can't just take a legacy, legacy product and move it over. We need to actually look at, well, what are the vendors? What is the open source? What's available to us here? We might have to spend some more money on it. So there needs to be some alignment. There needs to be an understanding that most likely you're going to be using whatever your legacy infrastructure is for a while. And if you're a net new company and your startup and it's all fresh and new, cool, but not everybody is like that. Obviously, there's a lot of large organizations that have to have inherited big systems that need to evolve. And as I point to said, mentioned like costs are not going to go down, but in this build stage and this level one, you shouldn't have crazy, you know, prices increase or cloud questions that go up dramatically because you're just trying to get out. You're just working on it locally, maybe, but in smaller environments. So for level two is a really critical part of the of the cloud native maturity model. It's where our first apps go into production. These are speedboat applications that have been identified. It requires a lot of people, process, policy, and again, technology to be there as a prerequisite in the first place. And if we think about it, when we carry out a migration, particularly to public cloud, we have to consider does our backup or I am strategy, for example, work? If we move, you know, we need to plan for a cascade of activities in order to build the foundations for those very first applications. So again, we have to really align with our business on what we're going to move. We need to think about where we're hurting and where will we benefit the most from migrating? What do we expect? Do we, will our non-functional capabilities, our capacity, our performance, our availability improve as a result? Or alternatively, will there be additional functionality that going cloud native will help us to implement? So as we're dealing with the business, we're going to obviously need to measure these types of things. We'll have to have key performance indicators and objectives and key results to find. And we're going to have to have good communication between the technology and the business units. And as we can see from the quote, this message was really brought home within the CTO Summit within KubeCon in Detroit. Many organizations get stuck at level two because they can't demonstrate how cloud native has actually helped achieve a business goal. So again, with money, when it comes to the money, costs are going to change, particularly when we're dealing with the public cloud. And consider one way is that instead of having a traditional CAPEX model, we're moving to OPEX. So instead of buying those servers outright, putting them in a data center and then depreciating them on the books and not necessarily having money go out of the organization for three years, instead with cloud, that money's going out monthly. There are invoices turning up. So it means that we can't necessarily sweat hardware in the same way that we would have previously. But because we're not paying for data center space, those depreciation costs will change. So again, it's important to talk to cloud service providers about discounts and understand those pricing models and also who has responsibility for those commercial relationships. It's surprising how it's difficult to find out who owns those relationships and who's negotiated with. So cost controls now everyone's responsibility. Real money's going out the door rather than just being expenses on the books. So now we're moving on to level three, the messy middle. You've heard it here first. I have coined it. I have coined it. So I have a brother and a sister and I am the youngest and I did many journeys in the car where I was in the middle being pushed in either direction and things weren't great. And so when we were talking about level three, we're talking about business outcomes, we're like, this is just a mass. This is where you're scaling and you want to use a bunch of different technologies and you have a bunch of people who know what they're doing and a bunch of people who don't know what they're doing and things are expensive and it's just kind of a mess. But what's important here is that you don't give up and that the business doesn't give up here either because really here you have decided that there is a lot of value and hopefully you'll have communicated that business value. So the business understands like, yes, we need to push through this area and get through it. So here you have, you know, one of the problems here is that it takes a lot of resources to get done what you want to do. So like you'll, when you get to this point, you'll have sprawl, you'll have a proliferation of tools, you'll be spending a lot of money. And so trying to get the business to understand like, this isn't our ideal situation. This is just kind of where we're at right now is really important. And for some, they'll skirt through this messy middle pretty quickly, depending on the size of your environment. But unfortunately for maybe large enterprise organizations, you might be here for a while. And that's my ideal. And cost again, it comes back to money. So as we can see from this pretty graph, the messy middle is a place where we can find a tremendous amount of pain. We run the risk of having both significant cloud native as well as legacy costs, particularly in the middle of an ongoing migration to public cloud. But your technical team may have solutions at hand. Good examples of that of this are sophisticated workload sizing or placement decisions. Your technical organization will need time to pay down that technical debt and to get those optimizations in place. So it's really incumbent at this point within a business that the business understands this and that there is clear communication between the technical organization and the business stakeholders to avoid this pain or to understand how it is and that it's not, it will come to an end. At level four, the technology now, we're really seeing a much more of an emphasis on business output and less of a focus necessarily on technology in and of itself. The improvements made should be focused on getting business value, going, getting better business value by reducing repeatable processes. We expect to see a lot more alignment and understanding again between the business stakeholders, finance, developers and operations. The time the tech team needs to pay down that technical debt that we've just spoken about in level three, we hope that that'll be pretty much complete and we expect to see a consolidation of technology. One of the characteristics of level three is that we have a wide variety of technology within the organization and there are maybe additional products and projects that have been brought in to the organization as it explores and finds its way through its transition towards cloud native. We expect at level four to start to see real consolidation. We also expect to see some effective automation of policy and compliance. Again, it's important to measure this. Remember the business loves key performance indicators. Legacy apps will still be around but they may only be there as a necessity, particularly for a specific regulatory requirement or they'll be left to simply age out. We do expect to see a reorientation at this point where our our attention is directed much more towards innovation and less to that support and firefighting that we can see in the earlier levels. So again, cost. Cost optimization rules here and we want to make sure that our infrastructure is optimized for that efficiency and we'll also need to again provide proof of this. The great thing is that we do have tools that can help demonstrate cloud and Kubernetes cost optimization. So level five is what we like to call utopia, which I'm sure most people aren't here. We loved this picture of this dog who's just so perfectly happy and content and everything's perfect and that's unfortunately not the reality. But level five is you've achieved all your business goals. Everything's great, but you need to adapt. So a business changes all the time. You know, I think we all work at organizations where, you know, six months, it's one thing. A year later, it's another goal, two years. So level five, you are looking at adapting, but you're really hopefully have all the foundations built. And when you're talking to the business, they've completely bought into cloud native. You've changed the way your organization operates. So when you're adapting, it's not this huge pivot like it once, you know, what it was when you were moving from what your legacy was to your cloud native. And then, you know, cost obviously in level five, it's utopia. So all costs are predictable. Everything's great. You know exactly what you're spending. And we know that that's not necessarily the reality at many places. So that's like a whistle stop tour of the model. But because this is a maintainer section, now this is where we talk to you all about next step. Yeah. There is a tremendous amount of work to be done. So the cloud native maturity model is a living artifact and it's open source. And we really welcome contributors and contributions. We have a few things on our agenda that we would like to continue doing. Some good examples are we want to further incorporate references to materials throughout the CNCF into the model and provide links. We want users of the maturity model to easily cross reference this with further resources within the CNCF. There are many within both the tags and the projects. We need to further develop the categories within the key areas of people, process, policy and technology. We would like to add in platform engineering. There's been a tremendous amount of work within the CNCF on this topic over the past year or so. And we really want to get that content incorporated in. There's also the platform maturity model. We've worked closely with the developers of that and it's been fantastic. And so we want to start to bring in some of the insights from that. And we see that the platform maturity model works incredibly well with the wider and broader cloud native maturity model. It's also other areas such as developer agility, security, as well as technical domains like storage that we would like to further flesh out. So we really appreciate contributions. So we would like new content. Finally, of course, as we all know, the landscape is consistently changing. And then some other points as well. We need new perspectives and yours is important. The model has a bias towards large organizations. And so can you help bring another perspective? When it was originally drafted, we wanted to make sure that individuals could use it as much as an enterprise. So it's a real opportunity, particularly for people who don't code to make no code contributions and become a contributor to the CNCF. So to finish up as well, the maturity model is available at maturitymodel.cncf.io. It's all in GitHub. So you can submit an issue or a pull request. And we'd be delighted to review that. We hold community meetings every two weeks. They're at 1 p.m. Eastern on a Tuesday. So please join up. Come along. You'll need to register at community.cncf.io. But come along and join us there. Well, and just to add to that, if you're like, I'm not ready to commit to an hour-long conversation, you can also just reach out to Simon, myself, or John Forman, who's down here, because he's also a co-organizer of the group. So we're all in Slack. You can start there if you want. Exactly. And with Fetch, get involved. And are there any questions? This was really helpful. And the first thing that I've noticed when I saw the topic was the Richardson maturity model for APIs. That's what came to my mind. And I saw a correlation between maybe potentially this can be that type of a model for cloud native space, whereas the Richardson model is for APIs. So today, like in the industry, especially I do it for my projects, is that I use that Richardson model as a level of where the maturity of APIs are. So when I saw this, I assumed that that's what basically answered for me is that potentially this can be something that in my organization and corporation, that now I can say what level of maturity model projects, teams, groups, and departments are, and where do they land? What do they need in order for them to move up? So on that, is that the intention of making this as popular as what the Richardson model for APIs became? I mean, we would love that. That would be fantastic. We do already know from attending this conference that there are people who are using it like this. They have, whether it's a managed service provider that's calling into somebody and saying, well, let's let's figure out where you are. And you might be here in this level for this application, but not this, or we need to upskill your people and using it like that. You know, I think one of the topics we talked about at this event is could we build a spreadsheet where people could just tick off where they're at and where they're at the journey and give it to their boss at an organization or externally to other companies. So absolutely. And if you want to participate, we'd love the help. Yeah, that's something that I can definitely do and work with you guys and advocate like in my company and teams. The other thing is in the first levels, I saw the importance of OKRs that play. And at the end, I saw you guys listing up some of the on the on the development side and the resources side were which kind of come in afterwards. So I think that OKR and the concept of OKR is important to also be built inside this in that first or second level of this because and that becomes a dependency item because it makes sense with the measurable concept and the usage and you guys brought it up a couple of times too. So I was waiting to see if it comes up as a bullet point and it kind of did not like explicitly do, but it was more implicit. So I think that it will be nice if we can also have that concrete that OKR is important for you to pass that type of a level in order to move up. So I love that. We did a in the in the grid that we showed, we do have a level that's like here's some sample OKRs you could have here and here's some sample and here's and they change based on what the business goal is. And at one point, when we're talking about the B2C example, we're talking about it's really what's your net promoter score? What is that? And so we have it, but more, you know, we would welcome more feedback on where can we have some really specific examples of those. And the reason I bring this up, the only reason I bring this up is some organizations and some companies have used OKRs inside their systems, like and some have not yet adapted yet. So if this is if we can explicitly say this, it can make that organization or company or team start adapting OKRs. I feel OKRs are very helpful for any organization. It sets up your quarterly goals, measurable, tangible. And we talked about how important tangibility is, and it gets lost inside engineering. So we map that to business and OKRs do a very good job. Those companies that still have not adapted OKRs, this can become something that they start adapting it and they need to adapt it in order to pass that level versus no, you could use it. No, you have to use it. Yeah. Well, thank you all for coming. I hope you have a great time in Chicago tonight and thanks.