Cloud Native Application Protection Platforms

Exploring Cloud Native Application Protection Platforms (CNAPPs)

James Lewis: Hello there and welcome to GOTO Book Club, which is coming to you in January 2025. So, Happy New Year, everyone. And today, I joined... I'm delighted actually to be joined by an old friend of mine, Russ Miles. Welcome, Russ, and Happy New Year.

Russ Miles: Happy New Year. Very happy to be here, my friend.

James Lewis: Thanks for joining us. It's taken a while to get us together. So, finally, at the start of 2025, we get to talk about your new book, Cloud Native Application Protection Platforms. That's just released now? Was it just before Christmas?

Russ Miles: It's been out for a little while. I think it was sort of middish, sort of maybe two-thirds of the way through last year.

James Lewis: In which case, this is something that has sort of passed me by a little bit until I heard you talking about it or touching on it briefly in GOTO Copenhagen. You brought that into your talk there. Well, maybe you can tell us a bit about the book, a bit about what it's about. What sort of made you decide to write it?

Russ Miles: Well, it is one of those entertaining topic areas where initially I was talking to Taylor and Steve, the co-authors on it. And I think they've been trying to construct a book around Cloud Native Application Protection Platforms, or CNAPPs, and the struggle that I think they were having was telling the story of what the tooling and the platform brings. And actually, this is a common message for any platform in my experience is there's a story to it. There's somebody that benefits. There's: who is that audience that's going to get the biggest impact out of the platform?

And I think because Steve and Taylor were coming from a very strong open-source background of working in the product set, they were struggling to go, "Okay, what does this mean to some users? What are they going to get from..." They knew. They're very close to their users, but it was still difficult to come up with a story.

What I could add to the mix, because they were very much down in the details, writing all of the different recognition algorithms and things to find the security problems across the whole broad landscape of a Cloud native application. They were on top of that. Whereas on the other side of things, what that means to how a user interacts with the platform and how they interact with other people through the platform, that sort of collaborative nature of it was something that I could add. I could sort of unpack that.

I was very fortunate, actually, to very early days come up with a story for it. There was this sort of recollection of many, many years ago, as I'm sure you are full of stories like this, James Lewis, in your work, where you go, "There's a thing that happened, and I was close to it. How much of it can I share before I get in trouble?" And that was one of the things that led to the sort of structure of the book, the stories that we tell throughout. There's actually one consistent story throughout that has its roots in reality with an awful lot of organizational names and individual names obfuscated.

James Lewis: Oh, that sounds interesting. Is it worth you touching on some of that now? Could you give us a brief sort of preview of that?

Russ Miles: Well, it's in the book, so I can't get out of it now. But it was back when I was working in various organizations around defense. And there was this moment where a very well-informed agency contacted the organization, the security department of the organization, and said... And I remember very distinctly, I remember my security expert's face when he came off the call. It wasn't a face that usually emoted a whole lot because he had a huge beard. But when he came off that call, I've never seen a face that's more emotive in my life, which was, "We've been told not to stop something happening with our systems."

There were two problems with that statement, really. First of all, we didn't know it was happening. That was the first thing. So, this external agency was informing us. They didn't know it, but they were informing us of what was happening. And the other side of it was that we now had to find it and not stop it because the security service were using it as a mechanism to track down certain activity on these systems.

So, yes, it was a brilliant education in the lack of awareness that we have of these complicated systems, sometimes complex when you throw in the people around them. And it was one of those moments where somebody else is giving... It was the worst-case scenario. It was where our customers, our clients, or in this case, somebody completely external was telling us what was happening with our systems, and we had no knowledge of it from a security perspective.

Recommended talk: The Art of Strategy • Erik Schoen • GOTO 2020

Collaboration and OODA Loops in Cloud Native Security

James Lewis: I can't pretend to have worked a lot in this space myself. I started off as a cable monkey. That's about as close as I get to this, I guess. Cable crimpers and all that. Buying rolls of Cat 6. Well, Cat 5 at a time. But one of the things you mentioned just now is this idea of collaboration. Now, actually, everyone's got lots of stories when they've been in the industry for a while. And I remember one where we were running like a Red-Blue Team exercise with a government organization. The idea was to try and understand what it takes to build a secure, critical national infrastructure, cloud native application platform. And one of the things I remember that fundamentally came down to was people and collaboration. And that's very much the theme of this book, isn't it? One of the very strong themes of this book. So, how did that come about? How did you end up with that message?

Russ Miles: Well, I was kind of lucky, actually. you'll relate to this in terms of when you've come to the first half of the book. That beginner's mind to the subject area is very helpful when you're writing. And I came to this subject area going, "Well, I know about security, some aspects." It's an incredibly broad area. And then it was like, "Well, this must be at the application level, and it must be how we construct our cloud, making a huge stack of software that goes into what seems a very simple Docker image and a Docker runtime." And I thought, "Well, I can see where some of this is."

So attacking it from the technical level, there was plenty to play with. I wouldn't say there wasn't. There were loads to get your head around. But the people's side of it is always what fascinates me about any technical subject, particularly these days. A few years ago, I got very ill, and that kind of rebased my perspective on technology, and I kind of realized that the reason you're here is the difference it can make to people's lives. And so I was looking for it. From the word go I was like, "Okay, who is this for?"

The beautiful thing about cloud native application protection platforms is they're primarily a proposition to help several groups collaborate, as you say. And those groups are everything from the developers themselves through to the sort of DevOps pipelines, if you have people working in that space of trying to automate the delivery and make sure it happens in a cohesive and careful, safe manner. Right through to the security engineers who are going, "Okay, what should we be worried about? And what does it mean in the larger context of the advisories and the different sources of security information that's out there?" And how do we then also bring that to the runtime, the SecOps? What's happening when these things are being used?

Although we call it, and it is the cloud native perspective, the actual problem area, the challenge area, is all of these different groups having to work together where cloud native systems evolve so much quicker than systems have perhaps done in the past. And not just evolve purely at the application level, but evolve throughout the entire stack. With an enormous amount of open source usage in cloud native, then you also got the evolution of those critical underpinnings. Or even not underpinnings. They can be right up at the top of the stack.

So given all that breadth and depth and the speed of the software development lifecycle, that's kind of what we look for out of cloud native systems in the first place. But the downside is that the security profile of it all is evolving so quickly that you need help across all of those groups to help them work together, to help them understand and prioritize. And one of the mechanisms I used in the book was to distill collaboration down to OODA loops and say, "Okay, who needs to see what, in what context, so they're orienting in the right direction, so they can make good decisions about what this means to then make the best possible action with all of that context-sensitive help?"

The OODA loop became a key mechanism to understand how the cloud native application platform interacts with the different groups and the different people to see the difference compared to what you would have if you didn't have one. I guess one of the things I learned, and I've been still learning for the last few years working in platform engineering, is that a platform is best declared in terms of its value in terms of the OODA loops it enables, the ones that were not there before.

This was one of those very big lessons for me about writing this book was that you immediately saw that there were no OODA loops before. There were these little silos where OODA was possible, but there was no crosstalk. You could see the paucity of the information that some groups were having to work with in terms of making sure they're looking in the right direction and making right decisions and actions. So, yeah, that became the story of the book. It became less about the cloud- native stack and more about, "Okay, how do these people potentially work much better together using a platform that is absolutely tuned to help them do this in the best possible way?"

James Lewis: I love the use of OODA, by the way. I think it's actually a theme that runs through a lot of your writing, actually, is how you can bring observer-oriented design acts into how you're thinking about delivering software. I think there's a really interesting sort of difference in some senses between if you're talking about a developer experience platform or if you're talking about a business platform, a capability platform that's providing extra services to the rest of the organization or to developers or whatever. Maybe into those pipelines.

And the OODA loop you're enabling there is fast flow. You're enabling this ability for the people using the platform to go through their own feedback loops faster, right? And that's your job. Whereas, I guess with when you're talking about security in particular, when you're talking about providing this tooling to the rest of the organization so that they can collaborate, you're really talking about going through your own OODA loop super, super fast as well, right? Because the people who are trying to take advantage of your platform, they're trying to go as quickly as possible as well, which is in some ways closer to the original sort of idea behind who can execute this loop the fastest way.

Russ Miles: Very much so. Because my background way, way back, many, many years, naturally informed some of the story that I use in the book, was obviously in defense systems. And I used to work on fast jets. And I think the oldest one I worked on was the Harrier Jump Jet. I worked on an upgrade to the weapon systems not long before. To be honest, it was probably made obsolete. But anyway, it was good fun. I managed to get a chance to use the simulator at one of the air bases. And I'll never forget just how easy it is to put a Harrier in a flat spin when trying to land it on a carrier.

James Lewis: It's a lot harder than Arnold Schwarzenegger makes it look out in "True Lies," right?

Russ Miles: I watched that movie, and I was like, "No. No. I'm so sorry. That's..." Because you can imagine you've got this thing that's perfect for going forwards, and you're saying, "Don't. Just hold on there." And it just did it easily. And it was so mechanical as well, working with the Harrier. Sorry. I'm getting offbeat.

James Lewis: My fault. Sorry. Total derail. Let's be back.

Russ Miles: But OODA loops were a big thing then because at different points in my career, I've worked with different pilots who would relate to these things very much so. It was the differentiator. And I worked on several systems for the Eurofighter that became the Typhoon. And those were very much about speeding up the individual OODA loops.

The collaborative OODA loop, which is what we talk about in cloud native application protection platforms, is much more informed by my work with intelligence services, where we have a potentially enormous amount of diverse information, including, in place of CNAPPs, you're including with that the industry's awareness of threats and various problems. And you're bringing that in as a situational picture, which back in the command center days where I used to work, that would be exactly the same as a fast-moving situation happening out there, and there is a threat. There is somebody trying to win the battle or to dominate in the theater.

And it's the same with CNAPPs, and it's very much the same in security where you are trying to move your pieces. I don't want to get too Simon Wardley on this, but you're moving the pieces so that you have the best possible strategy. And to do that, you need the fastest OODA loops, and you need the fastest collaborative OODA loops as well. So, great information is important, but also how do we then take that enormous wealth of information and make good decisions with it? So, it was very natural. As soon as I saw the different diverse groups involved in working with the CNAPP and touching it at different points, I could go, "Okay, this feels like a command center problem."

And I was very fortunate. I was talking to a lot of great security engineers, and they were saying, "Why don't people listen to us? We've got these things that we need to describe. We can take a set of information out of the general awareness of the industry, and we can make it custom and tuned to what our company needs to be concerned about and the different prioritizing agents or schemes for that. Then how do we make that awareness... How do we bring that to the developer teams so that they can make sensible calls about their backlogs and make sure they're working on the right thing at the right time, prioritizing security at the right moment?"

And you can see, actually, when a CNAPP is not present, you can see the way this collaboration is much harder because you see a lot of people in those circumstances really frustrated that the security systems are saying, "There's this much on fire, so you need to fix it all." And you're sitting there going, "But we still need to ship things." As soon as I hear that dynamic, I go, "You could probably benefit from understanding, at least, what a CNAPP is supposed to bring, because it should help you prioritize." It should help you go, "These things are not just high risk. They're a high risk for us in our context." And so the CNAPP is trying to help the community of security engineers to communicate and collaborate around what's important to us. And then all the other different players that might be touching everything from the code to the runtime that are going, "Okay, we now can operate well with that contextual knowledge."

Recommended talk: Beyond Storytelling: A Deep Dive into Wardley Mapping • Simon Wardley & Charles Humble • GOTO 2025

Bridging the Gap Between Security and Development

James Lewis: You mentioned security engineering and the security engineers. You can look at it from one of two ways, right? So, security has maybe a bad reputation if you're sitting in the development team and you get, "Oh, the security folks are moaning again about a thing. Do we really need to do that? Oh, God, they just always moan. And all they ever do is come up with checklists at the end of a project. And why can't they help us out?" Etc.

And then on the other side, you've got somebody looking in from the other side. You've got a bunch of some really awesome security folks who are going, "My God, these developers, they're just not listening. We're not about checklists. We're about pragmatism. We're about actually protecting the way we do stuff here and making sure that the way we do stuff isn't putting us at risk and so on."

It's at the heart of the cultural problems that we see in software engineering in general, isn't it? That sort of difference between different groups with different tensions between them.

Russ Miles: Absolutely. And I can't say that a CNAPP completely overcomes every single challenge you might encounter. If you have cultural issues, they will... I mean, it's kind of a weird version of Conway's Law, but it will manifest in your platform as well. So, I would never be the person that says that the tool will overcome the cultural problems. I think I've been in this industry long enough, as have you, my good friend, to go, "Yeah, it's not the tool that will solve that one."

However, if you do genuinely have people that want to work closely together, and they frequently do in some of the best places I've worked in, but they lack the bridge between their different domains. And that's what a CNAPP can build is it gives you the bridge between the security engineer worried about policies, worried about the different risk sensitivities, and everything else they can play with to build those policies. And then you've got the engineering teams that are worried about how that translates into what I should be doing next. And in some circumstances, depending on the CNAPP, it can be an automatic button click to go, "Well, can you please fix this for me to a large degree?" Which, by the way, changes the dynamic very quickly from, "Okay. Yeah, sure, we'll do those things," rather than, "You're making my life hard."

I think I'm very, very fortunate in more recent times to work with some incredible security engineers that really push these things and try to make that happen. And what I would say, actually, is a little addition, is if you're working in Sec Eng, it's a bit like DevOps back in the day when it was Dev and Ops. Go and take people out for a coffee. My team, where I currently am, get taken out for a coffee quite regularly as a little sort of Microsoft Teams call. But we all get on with it, and we talk about what's important to each of us, and we get to know one another.

No platform is going to do that for you, but it's so enormous to understand people are behind this. People are trying to wrestle with it. And then when you've got the beginnings of that shared understanding, that's when a CNAPP can step in and go, "Right. We can codify how you can work well together." All right? And you can get these nice quick loops in this way.

James Lewis: That's actually, that's a simple thing, right? Go and have a coffee. But it's actually a profound thing, too. I don't know. That sounds like a hyperbole, but I genuinely think it is. There's one person I used to work with. You probably know Joe Warns. He was at Thoughtworks for a little while. He moved on to many other places since or to the Unicorns. One of the things he used to do at Google, because apparently in Google, different teams have different candy, different types of candy. So, he used to basically, if he wanted to meet people or he wanted to kind of go and kind of improve collaboration, he would take their candy and go and share their candy with the other teams because it's just a really human thing, right? "Hey, I've got candy. Let's have a chat about X or Y." And that sort of collaboration, that sowing those seeds of working together, is a very human thing, I think, to do. But I think we often forget it. And we often forget it now in the age of hybrid working and remote sort of...

Russ Miles: And AI, of course.

James Lewis: And AI.

Russ Miles: So, we had this idea that the AIs are going to stop us having to talk to one another. I mean, it's kind of a joke, and I have it in the back of my head a lot of times. When I first got into software engineering, I can remember finding a very appealing story I heard about an engineer at Microsoft who lived in a darkened room and had his headphones on, playing heavy metal music, coding away all day long. And I thought, "That's the job for me." I genuinely, at that age and that point in my life, I'm not sure I was that bought into other people, so I was kind of very happy with that idea. Then now I find myself realizing the collaborative game that it is.

In fact, that's a message that we kind of missed. We didn't miss, but we kind of toned it down a little bit in the book. And I kind of wish we hadn't because in the early parts of the book, we talk about it being a game. You are playing this game of security where you're trying to outmaneuver the folks out there that have a lot of potential scope for coming at you and speeding up, obviously, your game to work with that. But there's quite a lot of people that don't realize that it's such a... Software engineering, building cloud- native systems, in fact, building any software system is a game. When you view it that way, it's a collaborative game. We're having a lot of fun with it. And the better you play, the more that you need to get on with your teammates, and your teammates can be very, very broad and diverse.

I mean, one of the things I sometimes challenge is that there's a lot of pseudoscience around how teams can be constructed and play well with each other. I think there's a lot of people in the industry coming up with mighty fine ideas without really testing them against the complexities of team dynamics. But at the same time, it is the right place to put your attention. It's like, "How do we play this game better? It's a game. How do we play it?"

I think the CNAPPs, we embraced it a little in the CNAPP book. In fact, my previous book, which was about financial services, would have even benefited even more from emphasizing the fact that it is kind of a game that we're playing. We're trying to improve the stakes of how we play it. And in fact, if it was hard to convince the folks in security to treat it more like a game. When I got to the financial services people, "No, no, it's serious. It's financial. It's not a game." That's kind of the message I got.

But again, I do see this as a game we play together. It's not to make it trivial because it sometimes is extremely non-trivial. If I'm working on a certain defense system that has critical potentialities in the world, I don't treat it as just fun. But in the end, we play better because we know each other. We know each other's strengths and weaknesses. And hopefully a platform can then take advantage of that and help that collaboration rather than getting in the way.

James Lewis: It is interesting, when you talk about a game, fundamentally, it is a game. And in fact, hopefully this is about making it not a zero-sum game, right? Because it's about collaboration. It's not about... And this is actually where a lot of folks have been operating for a long period of time is people on either side of the fence operating as if it's a zero-sum game. "If I lose, you win. If you win..." etc., etc. So, actually, it's about changing that dynamic and making people come together.

Russ Miles: It's the avoiding the "Not my problem, mate" kind of thing is the way I used to put it. And that comes actually from a story when I was very early in my career. I had an incredible boss who... I was working at Ask Jeeves at the time. And I don't think anyone has told me about TDD. And I'd certainly seen the testers, but they sat on another table.

James Lewis: Ask Jeeves.

Russ Miles: So, I was okay with this, right? You can see where this is going.

James Lewis: Yep. I definitely do.

Russ Miles: I think it was a Friday, if I'm being honest. I think it was about 4:00 on a Friday. I just got my work done for the day. And I was like, "Okay, I'm done." Right? And I checked it all in. And I can remember getting up. And this boss, he had a really good accent. I can't remember which accent it is, but he had a really strong accent. And he was just like, "Are you done?" And I was like, "Yes." He said, "Are you sure?" And I said, "Yes." And he said, "But it works then? Does it really work?" And I'm like, "Yeah." And he could see me slowing down as I headed for the door. There's no doubt. And it was just one of those moments where I could be dragged back and go, "No, no, I'm not sure. I'm not sure about it. I don't have this confidence whatsoever."

Facets like security had the same role to play in this. I think a lot of what we do is avoiding the old dynamics of, "It's not my problem." It is your problem. You're building something or you're running something that is our game. We're in this together. I do think sometimes we overegg the sports dimension to games because games obviously in mathematics are not really like that. They think about the dynamics of what winning can look like. And it, like you said, doesn't have to be, "We win. They lose." But I found actually studying game theory just a little bit really helpful to understand what playing a game can be and how you can actually play a game with a competitor, and actually, we both look to win.

When it comes to security, we all lose if we're not doing right. Same with resiliency, and to be honest, it's the same with most things. I've recently been having conversations with product managers who are saying, "How do I get my team to pay attention to what I want to build?" And I'm like, "You need to stop thinking of them as just a team and you. All right?" What is the thing we all care about? And why do we care? We need to understand that. It's why I've been a big pusher of technical product owners in the industry.

As much as I can, I did talk at GOTO about why TPO is one of the best jobs in the world, because you've got to understand the tech. And partially that's because of the collaboration. Okay? You could be an expert on the domain of a product and how it's going to impact the marketplace, but if someone can't sit down with you and say, actually, this really difficult little top technical piece is a problem and a worry, and you're not open to that and you're open to learn about it, then you end up with that dynamic of, well, the PO wins, but the team are hating what they've built or the other way around.

Recommended talk: Learning to Love your Non-functionals • Russ Miles • GOTO 2018

James Lewis: Well, I'm in the same way with platform engineering as well, right? Hey, the platform team are delighted because they've offered all these new features, and the team's going, "Yeah, that's great." But surely I could just use like the cloud version of it, and I wouldn't have to put up with all this stuff you've done to limit what I can do, or, even worse, just ignore you completely and just go off and do their own thing somewhere else. So, yeah, very much so.

Russ Miles: I'm smiling so much because it is something that's occurred. And I had it as a wonderful directive from several champions out there when you're building a platform. You look for your champions. And by champions, they're not the ones selling what you do. They're the ones that are going to tell you with the most candor, the most brutality, that what you've got sucks.

I found my champions, and one of them is Pedro, one of my colleagues. And he's the one that will turn around to me and say, "Russ, please don't make it too special sauce. It's great that you're building this platform, but if you build a platform that no one understands when they join the company and anyone who gets dependent on it and goes anywhere else is going to not have transferable skills..." Has an enormous sort of emphasis on the product to make sure it doesn't breed, doesn't provide a habitat. I thought about my platform being a habitat. "Don't create a habitat that is so specialized and so perfect in some respects that it reduces the value of the people using it beyond the current context." And that's been a real balancing act.

James Lewis: A really good metaphor. Actually, I do really enjoy that metaphor because you can extend it in all sorts of different lovely ways. You talk about, are you going to be able to use these or use the skills you've developed elsewhere? We can extend that metaphor of habitat to be, are you going to evolve into such a niche, like with the Galapagos Islands, that you've not been able to survive in another habitat? We inhabit the Earth. We can't survive on Mars. You don't build something that is going to work on Mars if you want to live on the Earth in the future. I really like that analogy.

Russ Miles: You see that with great engineers that I used to tell people. People are a little wary of taking great engineers from, say, Google, if they're going to come and work on your startup or, even worse, work in your enterprise, where they're going to encounter a habitat that is extremely foreign to them. And I do think this idea of treating it as a habitat whose sole purpose is to help creative people do incredible work. It changes. It flips the perspective on things. If rather than just guardrails, you're trying to build an environment where people can have fun. They can be inventive. They can be innovative.

We talk a lot about this in my current company. We talk a lot about how in financial services our differentiator is the innovative qualities of our engineers. So, when we're building a platform, we're not building a set of layers that people just use. We're trying to consider what is the habitat that we establish for these people that we know that we can sit with as an internal platform. I have to find it funny that we did questionnaires and everything else. It's great, but we can actually go and tap them on the shoulder. And which we did now. We sit down with them and go, "Okay, what do you hate about this? What's making this better for you?"

We hear all sorts of feedback from people going, "Actually, my day would be so much better. I'd feel so much better about my contribution if the platform did this and didn't do that." And so knowing that that's the win for a great platform, it's other people going, "This helps me do great work." There's a lovely book called "Badass" by Kathy Sierra. And one of the things that I know Kathy believes from the heart is it's about how your users feel. Okay. What are you leading them to feel about your product when they work with it? And we do that with our platforms.

If you're really looking to make a platform that people love, then you're looking at, okay, how does it help them feel when they're doing their contribution? Do they feel like a drone? Do they feel like you're giving them yet another spreadsheet to fill out, another checkbox, another PR to review, yada yada? Or are you helping them be more productive and more creative than they have been before? I'm always a little wary of the word productive because you can make people very productive by doing very boring things. But I'd love to make them more creative, because I think that's where software engineering really is. So, yeah, when we're building these platforms, we're trying to create a habitat that genuinely helps people thrive in a creative environment. And I don't always think we realize that.

Creating Platforms that Foster Innovation and Collaboration

James Lewis: You used the phrase guardrails, which is one of these things that we talk about a lot with respect to platforms, the paved paths, and all these sorts of things. I had this lovely observation from Gregor Hope about platforms. I don't know if you've come across this. I'm going to try and quote it, probably more like a paraphrase, where he says, "Guardrails are not necessarily what you want because guardrails imply that you're bouncing off of them the whole time." It's kind of like that's no fun. That journey is no fun if you're just bouncing off one thing to another, right? There's no kind of pleasurable kind of experience of traveling in the right direction to get your stuff done. You're just constantly veering from one crash to another, essentially.

Russ Miles: It's friction and frustration, right? So, the phrase we use internally, and I'm a proponent of this, is if they've hit a guardrail, then that's wrong. That's bad. All right? We needed to give them a lot more warning before they got anywhere near that point. And again, it's those OODA loops, right? You go, "Okay, what can you help people observe to know that they're deviating before they hit something?" And treat people like they're clever.

This is another thing that Kathy Sierra opened my eyes to back when I was writing my Head First book, she said, "One of the principles the headfirst series is created around is that the readers are smart, right? Don't dumb it down for your readers. They are clever. Take them on a journey where they get even more clever. That's great. But they are really clever people and treat them that way." And you do that with a platform. You hear about it a lot, actually. And CNAPPs have the same property or same danger, shall we say.

If we dumb it down too much, then people get frustrated because they're banging against these barriers, and they'll find their ways around it. It'll be like the character in Jurassic Park. Life will find a way around your platform. And so what you're trying to do is say where you are is fun. Where you are is creative and not being frustrated.

James Lewis: And where you are, you can innovate. You can innovate where you are. You don't have to go outside.

Recommended talk: Platform Strategy • Gregor Hohpe & James Lewis • GOTO 2024

Russ Miles: Yes, absolutely. And you can extend it. You can own it yourself. We put a lot of effort internally into making sure the platform has extendable positions so that people can go, "Okay, I can make it my own here." And that takes some doing as well. I'm sure Gregor's book is enormous on exactly how you do it. I've read his book about a year ago now when it was in its early doors before I think it was professionally edited and all that sort of thing. He's got some great teams working on his books these days. But yeah, even then it was fabulous for helping me take those messages and make sure that we were not creating frustration. That means people look elsewhere.

We used to use a metaphor, by the way, and we still do sometimes. We used to say when you're building a platform, internal developer platform, you're trying to build a ski resort. All right? The mountain's already there, but everyone's getting lost. It's costing a fortune in search and rescue. And it's painful. People are being hurt on the mountain. So, what we're doing is creating ski slopes, not to stop people taking risks when they feel ready. So, we've got our different ski slopes, but genuinely, they'll enjoy picking where they should be on those ski slopes. And yes, we've got guardrails. Yes, we've got safeguards. That's to stop you heading off into the woods by accident. But generally, you know you're getting close to those things.

When you're building these platforms... And CNAPPs, to bring it back to the book. The CNAPPs have the same thing. You're putting guardrails and giving safety buffers in there, but genuinely, when people are able to collaborate that way, they don't always need the guardrails. They can actually find themselves comfortably innovating on the ski slopes. And we don't talk about après-ski too much, just in case.

James Lewis: We're all getting older.

Russ Miles: True enough.

Building or Buying a CNAPP: Navigating the Path to Cloud Native Security

James Lewis: As you say, coming back to the book. What I've noticed recently is a lot of... Well, first of all, there was a big explosion in the vendor space around these sorts of platforms. Then, I think, clearly the big cloud providers have taken that on board, and they're now offering their own, much more extensive, I guess, subsets of maybe what you'd call a platform in this space. So, in your sort of recommendation and your co-authors' recommendation, where do you sort of start if you realize that you need to invest a bit more time, spend a bit more money, and go down the route of investing in a cloud- native application protection platform?

Russ Miles: There are probably several ways of getting there quite well. Now, certain vendors will absolutely say you need to buy the solution that has it all. Okay? And there is some truth in that. Okay? Because it's one of those force multipliers. If you actually have something that is encompassing, isn't point solutions... We talk about point solutions in the book. Point solutions only go so far, and they can build silos by accident. And if they don't talk to one another, then you don't have a CNAPP. So, I have known organizations that are gradually curating their own CNAPP, but the challenge they face is getting these pieces to talk to one another. And they also face the challenge of refining that picture well enough that it speaks to all of those different audiences, all those different participants.

Whereas a vendor of a real CNAPP should ideally already have those things as part of their proposition. So, you won't have to curate, and you won't have to somehow make these things communicate. And also you won't... There's an enormous amount of benefits that some of the CNAPPs as package solutions offer because they start from the get-go of it's all going to be one. It's all going to be there. So, they already put refinement, and they give you early templates for different business domains.

So you're working in finance. Your CNAPP can say, "Right. Here's what we think is a good package of security engineering policies. And then how does that affect your developers? What does it feed into their feedback cycles into their tools?" That's certainly a big benefit that some of the bigger vendors in the space can bring because they start from that position of it will be the rug that pulls the room together.

Coming up the other way and trying to craft one yourself, I think, is possible, but it's a lot of work. And I would argue... And I'm not trying to sell anyone on a CNAPP, right? I should point this out there. One of the benefits of writing for O'Reilly and some of the other great publishers is you're not writing a book to sell a product ever. What you're doing is saying, "Here's a way of working, and it's best enabled with products that have certain properties or tools that have certain properties."

And so the properties here can be curated and created by composing a platform. And I'm a big fan of composing platforms. For many years, I was in the platform engineering space around chaos engineering. And I think the best chaos engineering platforms I've experienced are ones that respect the different domains and the different groups that have to interact with them and are usually curated in the environment. Now, I mean, it's a hard lesson for me to learn as a chaos engineering vendor at one point, but really the best platform is a curated one in my experience.

When it comes to CNAPPs, I think the domain is slightly more mature, and so, buying one off the shelf is a good starting point. Curating one is a starting point. It's just that you have to remember what you're trying to do. Because the thing is, you can get very wedded into the point solutions, that this little thing here is doing a great job of scanning my code bases on my terraform, right? But you forget that in a CNAPP what you're trying to do is build the context around that to go, "What does that mean to my domain and my world?" And a CNAPP should help you build that, but that isn't always obvious from just the point solutions alone. So, when you're curating one, you have to bear that bigger picture, that bigger mission, in mind.

James Lewis: That’s interesting. We're seeing a lot, well, we're seeing movement as well towards the release of things like domain-specific Kubernetes packaging. So, there's Welkin. I think they've renamed themselves, which is Elastisys Compliant. And that's like, kind of, hey, if you use package Kubernetes this way, then you'll get GDPR out of the box. You'll get all this kind of interesting stuff out of the box. So, I guess you're getting some of the same benefits of that. You're getting the tick already.

Russ Miles: Just very quickly on that. I think that that's possibly the way that the commercial proposition of great platform engineering could really take off. If you can build a platform that speaks to a very lucrative niche and make that available publicly... This is the Amazon model to some degree. So, you're working in a bank. You create a platform for doing regulated apps, and then you can make that platform available to other people to develop regulated apps. That's a great proposition. And I think there's many other areas where it's going to be really nice. I think if it happens, it'll be really nice and competitive as the commodity point drifts up and up to the point... Back to Simon Wardley again. So, yeah, it gets up to the point where the differentiator is back again: can you create your apps quickly and run them on it? And then we're choosing that platform that really punches strong for your particular challenge.

Recommended talk: Bugs in Collaboration: "Learning from Incidents" Edition • Russ Miles • YOW! 2022

Predictions for Platform Engineering and AI in 2025

James Lewis: Well, thank you very much, Russ. I guess I'm going to finish with one last question, which is, 2025, your predictions for 2025. Do you have any?

Russ Miles: Oh, that's a good one. Predictions. Well, I think it relates back to the platform engineering side of things. I think platform engineering has potentially been really overhyped, not by wonderful folks like Gregor, to be honest. But I think the industry has got a lot of new vendors that have, like every new vendor, what they do is they have to make it a bigger deal than perhaps it's ready to be. And I think that there's going to be a little bit of kickback on that.

But what I see is a great hope for platform engineering to become a commercial proposition. It isn't just what we do internally to save money or to make things consistently and need less people to manage it. It will become, I hope, something where it's actually a commercial strategy more potently externally, like Amazon, like AWS does. They treat the platform like a commercial proposition. Sometimes they don't even use themselves for the rest of their products, but they put it out there because it's useful to others. I think there'll be a lot... I hope there'll be a lot more of that.

The other thing I'm very excited about is and I'll be very gentle and careful around this, is some of those OODA loops can be enormously enhanced by the effective use of specialized LLMs and AI technology. So, I am not an AI advocate by any stretch of the imagination. I'm a writer. I find that I have to be a little careful with the position of AI and writing as a craft. However, when it comes to helping people knowing that they're in the right place at the right moment, doing the right thing at the right time, I actually think AI has a place to augment the human in this case.

I'm hoping there's more perspective delivered on that in 2025 so that we start looking a little as fearfully at it taking over jobs or stealing developers' jobs. And we realize actually it's helping developers and engineers and specialized people and people like yourself who are super intelligent, help them be more creative. Back to that habitat. Where does AI fit in the habitat? I think it's there as a supportive and helpful element to help people know they're in the right place, pointing in the right direction, making right decisions, and performing the right actions.

James Lewis: Cool. Well, thank you very much, Russ. You heard it here first. So, Gen AI as an integral part of our software engineering habitats, and platform engineering kicking on and taking over the world, to be hyperbolic about it.

Thanks very much. Thanks very much, Russ, for joining us at GOTO. This has been another GOTO Book Club. This time we've been talking about Cloud- Native Application Protection Platforms, or CNAPPs.

Russ Miles: It's a mouthful.

James Lewis: So, thanks very much, Russ Miles, and have a great 2025. And see you soon, I hope.

Russ Miles: Absolutely, my friend. Cheers.