DevSecOps for Cloud Native – Cloud Native Now Podcast EP19

Hello everybody, and welcome to the latest edition of the Cloud Native Now podcast. I'm Mike Vard, once again, I'm with Paul Nati, who is the practice lead for application development and DevOps for the Futureum Group. Paul, welcome.

Hey, Mike. Good to be here. We are talking about, well, it's a subject that keeps coming up DevSecOps, but in the context of Cloud Native, um, last week we saw that there were all these kinds of, uh, compromises of the GitHub repository that people are discovering, and a lot of that is embedded in our GI ops workflows that we use for cloud native applications.

And I'm wondering, you know, first of all, I'd like to get your sense of what is the overall state of DevSecOps, but as it applies to cloud native, do you think we're maybe doing a little better here or maybe a little worse here? Or is it all even? Yeah, Mike, it's a, it's a good question, and there's a lot happening in this space.

Obviously, this is a continuously evolving space, and it's, uh, it's happening for, on a number of different angles. One is the fact that, uh, organizations are under increased pressure to deliver more on their applications and such to get, uh, you know, code out the door, right? And, and meet their business KPIs.

But in turn, there's also, um, the risk of modernization, of taking those heritage applications and modernize 'em because of the risk of heritage, uh, security flaws, right? And what's happening with those security flaws, uh, could, could move forward with that new generation of code that's going out the door. So, with that said, a lot of organizations are trying to, uh, you know, do risk mitigation, trying to understand what is it that they need to do in order to, uh, you know, be effective, uh, uh, efficiently and move things out the door, but also understand that there's not, everything needs to be refactored, right?

'cause there's a, there's a, there's a, a challenge with that, with skill gap issues. There's a challenge with that, with resource allocation and keeping the wheels on the bus as you're driving down the road. I mean, there's just a lot happening.

So what a lot of organizations are looking at is, uh, repurposing code that's in repositories such as GitHub. And, and what we're seeing is bad actors are, are impacting those, uh, those GitHub repositories by infiltrating them, by putting bad code into those repositories, that code gets repurposed into, uh, organizations production applications. Um, so as I said before in other sessions that we've been on, that it's ultimately up to the organization's responsibility and accountability to make sure that they're pushing out code appropriately to, uh, and they have to check that code in order for it to go out the door.

It's, uh, it's their, their responsibility. So where they pull the, where the developers pull the code from, um, these repositories may be, um, you know, infiltrated with, with bad bad code, but they need to be, uh, checked before they put 'em and put 'em into production applications. Do you think there's more of this going on than we realize?

Uh, it seems like every time I turn around now, there's, there's a package has been infected somewhere that people are using, and now it looks like, uh, specific repositories and, you know, were compromised. And I can't help but wonder maybe the bad guys have been using this, uh, attack vector more aggressively than anybody realizes. Yeah.

The Trojan horse factor, right, Mike? I mean, it's like, uh, it's, they're putting the code in and you don't know about it until it's too late. Right?

Um, I, you know, I, I think on a previous episode we talked about the fact that I believe that the, the future of, uh, protecting, uh, security and securing code, the future of DevSecOps is not reactive. It's, it has to be proactive. And I know that there are some measures that organizations are putting in place that are proactive, or they, or they seem to be proactive.

But it almost feels like, to your point, it almost feels like the bad actors have one leg up and they're around the corner before you even know it. Right? And, and that's, uh, that's something we need to have a, a better lens on.

And, you know, I think this is where, uh, I challenge vendors in the space in order to go out there and put in, um, uh, functions that will test the code prior or test the activity before things happen, versus just giving a list of, here, these are the non vulnerabilities to make sure these check these vulnerabilities. 'cause that's just a, that's a, that's a reactive, uh, state, Right? We saw CrowdStrike get bit by that very thing.

I'm, I can't help but feel that maybe developers are, uh, too trusting. And we, we spent the last decade, uh, what, let's say 80% of every application is code that somebody downloaded from somewhere else and copy and paste it into a thing. 'cause they were like, why are we right or reinvent that same wheel, which makes sense.

But then it seems to turn out that we didn't really review that code and the bad guys are in there inserting malware. But do developers need to kind of change their mindset and assume that things are compromised? Yeah, like, that's really a good question, and I look at it kind of in a bifurcated way.

Uh, I think about it in the context of education versus trust, right? Um, the organizations are, let's look at the trust side of it first. Uh, developers are under incredible pressures, right?

Everything you hear, every, every organization is talking about shifting, left, pushing more to the developer. The developers is doing more and more every day. Uh, there's only so much there's a breaking point, right?

The developer can only do so much. So if they're challenged with pushing code out the door faster and building applications faster, there's a level of pulling, uh, operational efficiencies, right? How do you pull those code, that code base from, uh, repositories that are going to, uh, be effective to make the, make the job happen?

That level of trust is a trust slash um, need to get the job done faster. Uh, approach. That's one, one element.

The other side of it is education. If you don't know what to look for, then how do you know it's wrong? Right?

And, and when you look at, uh, pulling the code down, if the developer is, when we talk about this on many episodes of skill gap issues, if the developer is not, uh, up to the latest trends on what skills they need to be looking at the code, they may not even know what they're pulling down is, is bad code, right? And so that, that education piece is also very important. So the two takeaways and from, from my perspective is one is slow down and go faster, right?

That's a, that's a key factor. So make sure you're checking the code and then also understand the code that you're checking. You know, you have to be educated to understand and know what you're checking there.

So those are two things that I think, uh, developers really need to kind of have a, a better kind of handle on. But organizations need to give them a, a, a bit of relief to, in order to get that done. Are containers kind of exacerbating this issue a little bit?

Because it, well, it's so easy to encapsulate code and move it around that. Um, and maybe we're not even sure what code is running inside those containers, but, um, is this kind of a gut check moment on how we use containers? Yeah, I mean, that's a great point because I think when you look at containers, you have the ability to, you know, clone and, and reproduce and drop and, and, and, and again, you know, like we've said in our research, and we've seen in our research that producing applications now is far faster than just a few years ago with a fewer resources.

So when we look at containers, um, you know, there's, there's two parts to containers that I think either help and, and or hurt the, the story here, right? The narrative here, when you, when you look at it from the way it hurts the narrative, it's like, yeah, if you, if you replicate bag code and you continue to continuously clone it, yeah, that's a problem. That's gonna be an issue for your, uh, no matter what you're pushing out the door, uh, that that's gonna be an issue.

So, and it's easier to do on, in a, in a, um, containerized environment because you can clone those containers very rapidly. The other side of it is, is the way the pods are set up in these Kubernetes clusters is a way to, where, where there's an advantage is to break down the application to smaller pieces, reduce the attack surface, right? So if you slim down a container and you basically have that pod for the application broken into multiple microservices, and you have a smaller container that has, uh, the common elements that multiple applications can use, you can slim down that container.

So you don't have, uh, that, that full attack surface that you would have in a traditional application. So there's pros and cons, and again, it becomes to an architectural design. Yeah, I talked to some folks and they're kinda like quite literally tearing their hair out because they'll go fix a vulnerability, and then that same vulnerability will show up a week later in a different application because somebody downloaded something and they're like, didn't I just fix this vulnerability last week?

And now they're on this permanent, um, hamster wheel? Yeah. And that's largely due to if you have vulnerabilities in your gold image and you cone your gold image, then you're can have vulnerabilities in every application that runs that gold image.

So that's where you can kind of run into it. I think that that's something that, uh, needs to be addressed. I, I think that the, the pro side of what I was talking about by slimming down, if you carve up that gold image into smaller microservices, you can and, and have multiple applications using those different components within the pod, that gives you the ability to be more flexible and, and agile to adjust.

So if you have to make an update to one part of the pod, it will update multiple applications. So that's something to consider as a pro, uh, as a con, yeah, at the, the repeatability and clone ability, that goes back to, you know, days of virtualization, days of even heritage applications that are siloed. You know, if you can, if you make clones of your applications, you're gonna take whatever there, the good and the bad.

All right? I would look at it a little bit differently in the sense that, well, hey, if the gold image has vulnerabilities, perhaps it's not gold, but we'll see. All right.

I did want to shift gears here and, and get you a sense of, uh, what to look forward here. 31, they're on their usual cadence of three updates a year. But, um, as you look at this update, and there's a lot in there, um, including some cloud neutral capabilities, but what's sleeping out at you in terms of where we are?

31? Yeah, I think, uh, it's pretty exciting. You know, I think it's, it's always an evolution, right?

I mean, I like to see new releases come out 'cause it fixes the, or it enhances functionality from the previous versions, or even, you know, like I said, fixes the previous things. 31, uh, Kubernetes is, is basically enhanced definition. Uh, so the enhancement of definition implementation and stabilization, those are the three kind of focus areas.

And, and like you mentioned, cloud neutral is, is an area that's, uh, you know, that's basically being, um, being, uh, utilized and focused on, in, in order to, um, harmonize the distributed cloud environments that are out there. As, as I said in our previous conversations and research that we see, 94% of organizations are using two or more clouds. If you're using two or more clouds and you're not building a cloud neutral environment, that, that becomes very challenging.

What this does though, this is interesting because this historically, in order to harmonize across these multiple clouds, whether it is, you know, all the hyperscalers, uh, you know, Amazon or, or Microsoft or Google or anybody else, um, historically you had to use a kind of a, a platform to do that, right? You can use an OpenShift or a tan zu or something like that to do that, right? Um, where Kubernetes goes cloud neutral, it, it really does open up the fact that portability of applications across cloud platforms becomes, uh, more flexible and more usable.

And then when you have that con in combination with the number of clouds that our organizations are using, I mean, we see I mentioned 94% using two or more, 65% of organizations are using for and more clouds. And if they're going from different locales from core to edge to cloud, uh, and moving those applications around if they need to for development purposes, if they need to, for ebb and flow purposes, whatever it may be, having a Kubernetes environment that's cloud neutral allows for that flexibility. I mean, And this was kind of one of the original core promises of Kubernetes, and then I think when we went to implement it, we put all these extensions into the storage and the networking layer and everything else that, that promises never really been realized in a lush.

Maybe you did have OpenShift or Tanzi or something like that, but are, are we finally delivering on a promise that was made 10 years ago? Well, you know, I mean, I honestly think in general, um, Kubernetes generally is cloud neutral, right? Um, if you go with open source and the, the general distribution open source distribution of Kubernetes, if you want to use the special sauce that goes on top of Kubernetes for all these vendors that, uh, have their own distros, that's where there was a little bit of a, I don't know, call it a distribution war out there for a while, that people were saying their, their distri distro was better than somebody else's.

Um, frankly, that's what they were trying to do from a value add perspective. These vendors that why they're trying to do it now, there's, the vendors are realizing that, um, having a multi-vendor approach is where most organizations are at. So having the ability to be more agnostic, um, even if you are an AWS or an Azure or, uh, you know, A-A-G-C-P, if you have your own instantiation of Kubernetes, that only works on your hyperscaler, um, that limits the deployment.

So there's a desire to move forward. Now, granted, we all know that if you use the native integration for those individual hyperscalers, you're going to get the maximum functionality, right? We know that.

But the gain between the, um, version that's holistic across multiple clouds versus the, the gain that you get for running on a specific hyperscaler may be small enough that it might be worth not considering. So if you're going on, uh, an AWS environment and you're gonna get a 10% gain, but it's only gonna work for three or four of your applications, maybe you only put that for those that gain on those applications, but for the rest of the environment, you use a more cloud neutral approach. That's where I think this is going.

I think that's where the, um, uh, the market is understanding that, you know, cloud is cloud and it needs to be different levels, but if you're going on the top tier and you need that, uh, ultimate functionality, sure, go native integration. But if you need more holistic view across the entire cloud ecosystem, cloud neutral is the way to go. Well, hopefully that will happen, but it takes a while for organizations to kinda update their Kubernetes clusters to get to the latest version.

And, um, so probably may not be till this time next year when we actually see more of this. Um, but that brings us to our next story. There's, uh, uh, two outfits that I don't really know all that well.

Um, meta fee I think it's called, and, uh, tycoon. Um, and what was interesting to me about it is they're really talking about, well, there's platforms for data center automation that have existed forever, and now they're adding Kubernetes support to these things. And I think if I watched over the years, there's this whole cottage industry of platforms for managing Kubernetes, but as Kubernetes goes mainstream, do you think it's just gonna be an extension of the existing data center automation frameworks that people already have in place?

And so it's just gonna be one more No. In a larger party? Yeah.

I mean, obviously as more advanced functionalities of rollouts go, uh, within these architectures, uh, the maturity of organizations as they start taking on more and more automation is kind of that utopian view of where our, uh, organizations want to go. 'cause it reduces those, uh, remedial or t or tedious tasks that organizations have to take on. But it also takes the burden of, uh, the, the maintenance, typically the maintenance off of the, uh, developer so they can focus on more things that are more innovative to their environments.

In addition to that, you have the ability to move rapidly, um, and, and you take the human somewhat out of the loop, so you reduce the human error pieces of maybe, um, introducing, uh, error codes or whatever that, um, you may not have if you, if you build these templates and work and workflows. So I believe that, you know, know these, uh, these solutions that we're talking about with, with edify, uh, and, um, you know, it, it, it, it really, it does help with the automation aspect of it. Um, but it's, it's the stylization, I guess, that we're kind of looking at it, of taking a Kubernetes environment and making it work to fit those blueprints or those workflows to, uh, to help with that automation.

Think of it, think of it in the context of infrastructure as code, but also expanding it out to the, uh, the, the higher level of business logic as well. To me, this is just part of the larger trend where we're democratizing Kubernetes and mere mortal IT administrators that are using these automation platforms can now manage Kubernetes alongside everything else they have. Yeah, absolutely.

And, and you know, the other factor that that's interesting about this, this topic that we're talking about with the, with these vendors and approaches is, is historically Kubernetes managing Kubernetes was, is there's a number of ways to do it today, right? There's a lot of technology, a lot of platforms out there to kind of manage Kubernetes, but they stop at the business logic, they stop at the containers, they stop at the, the orchestration layer, which is fine. However, when you start looking at reaching down into the, say, the, the, the application stack and knowing what's going on at the, uh, at the configuration level, uh, some of that really does impact your business applications.

So if you need un an understanding of the, the system bios, for example, that's going to run the environment that needs to be understood, so you can take full advantage of the underlying architecture to support that business application above. That's where these, uh, these tech stacks that are kind of being introduced today are really, um, kind of expanding or bridging the gap from the, the just infrastructure to the application space, truly putting platform engineering into, into, uh, into play. Uh, of course, we now have a regular routine.

Now, I, we observability being so critical that cloud native that almost every week now we have something to talk about here, but, um, there's an outfit called CoreLogics and, um, they have extended an observability platform that they have to mobile applications, which is great, but the interesting thing underneath it to me was they already support Kubernetes, but the way they do it seems to be different than everybody else. They're using Kafka as kind of a messaging framework, and they're, uh, analyzing and processing the observability in flight, as it were, and there's no need for a database underneath that. And they're arguing that, that makes it simpler to observe.

And if you wanna store your logs, you can put those in an S3 file somewhere and access them as you see fit. But, um, what is your sense of these guys? And, you know, have we been approaching observability all wrong with a database centered view from the beginning?

You know, it's interesting. Curl Logic's brought me back, actually. I went, I went a little bit far back into, uh, a technology when I was thinking about the, the, uh, the realtime, uh, user kind of monitoring.

I was thinking back to the days when, when fog, fog computing was a thing, you know, like as kind of, that was like an initiative, then it kind of came down. Um, but you know, when I look at it from that perspective, it, it really, um, uh, you know, I, I think it, it really does matter. When we look at our research and we look at why organizations are doing what they're doing, why this is important, right?

Uh, Kafka is just a, a way to kind of communicate the information. But really what's more important is 62% of organizations that responded to our observability study say that they only use observability on high value at applications. There's a desire to go across the entire ecosystem.

They're not even using observability on their production applications, nevermind the mobile applications or the end user, the real time, uh, user monitoring, that's a big factor. So if organizations like CoreLogic can extend the observability solution out there to touch on these different things, uh, these different devices that may be out in the edge, or, uh, even the micro edge or, or even just, you know, the end user side, that's a, that's a really, uh, a desirable state. However, the one other factor that came into out our, out of our research is organizations use six to 15 different tools in order to gather organizational, uh, and I'm sorry, I'm sorry, observability data.

Those six to 15 tools introduce a tremendous amount of complexity. We also asked in the same study, are organizations looking to change their observability, uh, practices in tool sets, uh, in 2024 and 57% said yes. And so there's a reason that organizations are changing or looking to change their observability platforms because that, um, they want to have the holistic view from, from their production applications, their high value applications, their entire ecosystem, but also expand out to what CoreLogics is doing into the mobile applications in the real time user monitoring space.

That's something that they need to expand out to, but it's super complex right now. And I think that, uh, I think my opinion, um, CoreLogic's functionality here would be rolled nicely, rolled up into a an FSO, a full stack observability solution, uh, that would really help with, uh, a full, full deployment of, of observability across the entire business ecosystem. I don't know, we'll see how that plays out, but I often marvel, how the heck did we get so far without any observability?

Well, I think we did before, you know, we, we did. So there was a lot of alerting and monitoring that was going on, and I, and I joke around a lot saying that the, the number one, uh, the practice, uh, use case for the observability practice was the storage admins because they just collected a bunch of data and didn't know what to do with it, right? And that's the, uh, that's the challenge with alerting and monitoring, but this is where you take that alerting and monitoring and take actionable insights against it to understand how it's gonna fix your business.

That's really where the key, that's the special sauce to observability. All right, cool. And then finally our last subject for the week is web five.

Uh, Google's out talking about the rise of web five, which I guess is, uh, from their definition is more, uh, I guess identity is baked into the application framework more so that we can perhaps implement zero trust at the, at a deeper level. Um, I was kinda loosely aware of Web3, and I guess I missed web four altogether, but, um, what's your take on web five? Yeah, so, you know, like when we, when a Web3 came out, you, you introduced ai, you know, the AI functionalities into, into the, the web, uh, web environments, web four came out and really helped decentralized, uh, all the connections between the, the people and the machines and all the activity out there.

Web five actually brings in, um, all of that right from Web3 or web four, and then it gives you that control or identity and data, right? And I think that's important because as we start, you know, decentralizing and having, uh, these, these devices and, and connections from various points, you need to have the ability to, uh, understand who's accessing that information from where they're accessing it from. So without controls, it's just kind of the wild west.

Every, all the data's just out there, and it just kind of goes, goes wherever it goes, especially with a decentralized environment. But what if you have a way to do identity and, and data protection and for control? Now you con control what data that goes to which endpoints and which web connections.

I think this plays a lot into, um, decentralizing the identity, um, identity management, or there is a, uh, decentralization of, uh, uh, identity foundation, I think called DIF, that basically it's, uh, it's part of the Linux Foundation. And, and what they do is they, they, they basically are trying to put some standardization around this. And, and really, in my opinion, where this is all going is as I talk about my practice, I talk about past, present, and future and applications.

You have your monolithic or heritage applications, and you get containerization for present and microservices for present. But a lot of organizations are looking to the future, and when they take their refactoring efforts, they go, well, if we don't have the containerization or, uh, Kubernetes skillset on our bench, maybe they jump right over that and they go right to web assembly. And if they go to web assembly, you, you know, if you're starting to use your applications, your cloud native applications and web assembly, especially in, in, in 20 or 2023, the introduction of using multi-threaded in net applications, now web assembly opens up a whole plethora of new applications that can be refactored as web, uh, as web-based, or cloud native applications.

Identity management and protection is critical when you start migrating those applications forward. So that's why I think Web five plays a big factor in here and, and plays a big factor into not just, yeah, does somebody have access to looking at some information on their phone or whatever. It's really about if we start moving towards cloud native applications in, in these, in environments, you have to have the right identity management in order to get to those applications.

We could actually be looking at something that feels like a kumbaya moment between developers and cybersecurity folks, right? Because they'll be like, Hey, that's actually baked into the software. Yeah, absolutely.

Absolutely. And, you know, and, and, and, and that's what, you know, I I, I talked about web assembly, but I also think it has to do with the serverless side of the house as well, right? Because that's, that's a big factor.

And, and you're right, Mike, I mean, there's, there's the fact that, you know, developers are being asked to do more as we talked about. And security's part of that ask. And in order to do that, they, if they can, if they can leverage, um, uh, standards that are set within a platform that's gonna help them with their security protocols.

All right, folks, well, I have no idea if there's a web six, seven or coming behind this thing, but five sounds pretty good and maybe everybody should check that out, because otherwise we're just gonna have this continuing conversation about security forever in a day. Hey, Paul, as always, good talking to you. Likewise, Mike.

Thank you. All right. Thank you all for listening to the latest edition of this Cloud Native Now podcast.

You can find this episode and others on our website or Spotify or Apple. Check them all out till then. We'll see you next time.