The State of Kubernetes and Cloud Native – Cloud Native Now Podcast EP1

Welcome everyone to the inaugural episode of the Cloud Native Now podcast. I am Sharon Florentine, I'm the managing editor here at Cloud Native now, and this is my esteemed colleague Mike Ard. You wanna introduce yourself?

Hey folks. ai, and of course, tech Strong. Do t happy to be here?

Yeah, great to, uh, be here with you. So on the Cloud Native Now podcast, our plan is to cover everything and anything related to cloud native and the ecosystem around it. That includes apps built with microservices, uh, service mesh networking was Kubernetes.

Of course, we can't forget that. Um, and, uh, you know, wherever the conversation goes, we would like to take you with us. So first of all, I think it's important to start off by getting a baseline of what's the state of cloud native and, and Kubernetes today.

Where are we at? What are we looking at in 2024? I think we're at the point now where it's the tail of two cities, as it were.

On the one hand, we have a lot of folks that are deeply entrenched and they're starting to deploy fleets of Kubernetes clusters, and they're rather experienced on the other end of the spectrum. We have a lot of newbies who are just kind of discovering the platform, and I don't think there's much in between. I think, you know, it's, it's based on what we see in terms of how the content is consumed and would suggest that there is a pattern here.

I don't know, are you seeing the same? No, I, I absolutely am. And, uh, you know, I came on board here at Textron Group a a little while after, uh, cloud Native now, which used to be a container journal launched.

And, uh, you know, it, it seemed to me that the stuff that was getting traction was really more entry level topics. Um, you know, and that, that has progressed over the last few years, obviously. But it seems like, uh, you know, folks are, are just now starting to get in on the ground floor and make some progress, um, you know, with, with understanding the ecosystem and how to modernize their applications and then apply that in their organizations in a real tangible way.

Um, so yeah, I would say, I would say, um, it's surprising we've been at this Kubernetes thing now for the better part of half a decade, right? I mean, yeah. And the fact of the matter is it's probably one of the most powerful yet complex platforms ever to find its way into an enterprise IT environment.

I think some reports suggest we're making some progress. Uh, Fairwinds has a report out that kind of shows that people are getting a little bit better at managing the environment in terms of maybe not over provisioning it, and that just may be, we're a little more cost conscious these days, but they also seem to have, uh, indications that there's more skills and the folks that are running this are a little more adept and kind of get it. Um, at the same time there's issues down the road, um, is another report we published recently from Spectral Cloud talking about all the interoperability issues.

And it's not necessarily the platform itself, that's the problem. There's, Kubernetes, of course, has a consistent set of APIs, but the stack that sits above it seems to have all kinds of interesting components and none of those are standardized and you wind up with a lot of interoperability issues between those components. So I'm not quite clear, we're realizing the dream of Kubernetes.

What do you think? It, it really doesn't seem like it, um, all that much. Um, you know, one of the things that's interesting to me and, uh, we published a piece I think in the middle of last year, asking the question of whether Kubernetes was actually fit for purpose and if it really was the best tool for the job that folks are trying to make it do.

Um, and, and that's always been interesting to me. You know, is it, it obviously it started at, at Google as Borg and came out of this massive, massive enterprise situation. And so now when we see folks in small startups and really small organizations trying to figure out how to make it work, it's like, are you really sure that's the tool you wanna be using here?

Um, and yet it has kind of become this defacto standard for container orchestration. So how are those things, you know, really how do those two things mesh together? Um, it's, it's definitely speaks to the, the struggle that's, that's happening there.

I think, I'm not sure to what degree this is, uh, a platform issue or is it just simply a reflection of the IT organizations that employ it? Um, the fact of the matter is that a lot of them have, uh, versions of Kubernetes when it is running that go back to, I don't know, one point 13, 14, 15, um, and I think we're at 28 now or something like that. Um, a lot of folks are hesitant to upgrade 'cause they're afraid that APIs will break and whatever application is running will have to be refactored or tweaked and they don't wanna do that.

Um, I also think that outfits are still running different distributions of Kubernetes from different providers. 'cause different teams decide to do whatever. Um, 'cause a lot of this came from the bottom up.

It wasn't really a top down driven decision. I wonder if this year becomes the year of Kubernetes discipline where everybody kind of sits down and says, okay, this is how we're gonna run this. This is how we're gonna automate this and we need to be consistent in our approach.

And that's just a level of maturity That's entirely possible. Um, the other thing that keeps coming up are the security issues here. Um, you know, we, we just posted an article about dom, this kind of rampant level of insecurity around Kubernetes and um, you know, there's all sorts of, of attack vectors that through which it can be compromised.

Um, and I think that's also an issue that people are struggling with too. Um, you know, how can you lock it down? How can you secure this?

Um, especially if you are already struggling to deploy and manage and keep, keep it running much less the security, security aspects of it. Mm-Hmm. I think it would be fair to say that in the interest of making the platform more accessible, we didn't pay a lot of attention to the security side of it early on.

I think we are once again chasing the proverbial horse out of the barn. And the problem is that we've now reached a level of, uh, volume in terms of workloads running in production environments that a cybersecurity researchers are interested in looking into it. And b, cyber criminals are interested in looking into it, and they're both doing their darnedest to figure out where the weaknesses are.

Um, the researchers, I get it's a noble exercise, but sometimes you wish they weren't as efficient because well, when they publish that, the bad guys were probably their most ardent readers. Yeah, indeed. And then The how to manual.

Um, the second side of that whole equation though is, um, you know, at the end of the day we do have to figure out how to battle test this platform. And there's no way to do that other than running it live and see what happens. So, um, that's to be expected in a certain degree, but I, I'm with you.

I feel like every day now, at least at the beginning of this year, somebody is tossing out a, um, a new malware campaign aim that Kubernetes or containers that they just discovered. I think on the site there's probably as many stories about particular campaigns as there are reports about vulnerabilities that can be exploited. Um, we invite you to check those all out at, at your leisure, but the takeaway's all the same.

Um, ultimately we need security people to get to know Kubernetes and kinda help us to manage that, but it's hard enough to find people with Kubernetes expertise. People who have cybersecurity and Kubernetes expertise are even rarer. So it is gonna be a challenge for a while.

I don't have a great solution for it, but, um, other than the fact we need to pay more attention to it and somebody's gotta step up here. Yeah, no, absolutely. And I think that just like you said, there's already a skills gap and a shortage in cybersecurity in general and then, uh, specialization in cloud native or Kubernetes containers is just that much more difficult to find.

Yeah. And what drives people crazy here is that the attacks that are coming in aren't exactly rocket scientists. You know, that like, um, massive, you know, research done by nation states that are looking to exploit Kubernetes.

These are, you know, basic scripts that people are using to exploit generic weaknesses. I think one of the cystic reports noted that, uh, privileges on Kubernetes environments and containers are not well managed and it's easy to escalate. Um, not enough of the scans are running in the CICD pipelines that we're trying to run scans after the application's deployed, which is never a good outcome.

Yeah. These are fundamentals. I mean, it's not like we need to sit there and go, let me go find a great AI engine to fix all this.

But the issue is we just don't have the people the time and the resources and expertise. Unfortunately, the many of these environments are still provisioned by developers, and I know we wanna let those guys go as fast as they can, but the truth of the matter is, they were all absent that day when security training was given and they didn't like it in the first place. So they didn't take that course 'cause nobody made them and no, we basically throwing them in the deep end of the pool and then were surprised when there are issues, Right?

Yeah. Yeah. The interesting thing to me from the, I believe it was the SIG report that you just mentioned, was when they did the comparison between the Kubernetes versus the standard CI pipeline that the CI pipelines were still more secure by a, by a fairly decent amount.

And you know, in my head I thought, okay, well if, if that's still the case, why are we not, like you said, getting these fundamentals down first before we jump ahead and adopt an entirely new way of doing things if we can't even get the previous version right. Um, I am certain someone will yell at me for saying that, but Well, in theory, right? We're supposed to be embracing DevSecOps and shifting left and all that work is supposed to be done in the pipeline.

It's pretty clear it's not being done there. And there's probably a variety of reasons stemming from everything such as inertia to you just don't have the tools to accomplish that. And I don't have anybody to manage it.

So naturally we announced with great pride that this application has now been deployed in a production environment and then the security people come along and start poking at it. And so that's why more of the vulnerabilities are being discovered after deployment than before. Um, and that's kind of scary because that means that stuff's running live out there that can be exploited.

And the truth of the matter is, the bad guys are getting better at that by the minute. Uh, I think one of the issues, one of the fallacies of security in this space is people think their containers are only gonna run for a couple of minutes, so they're playing to hide and seek and they're basically sitting there going, well, I don't think the bad guys will find that one. And by the time they do, I'll take it down.

The issue is that the bad guys know how it works and they're sitting there waiting for you to rerun it and they're like, Ooh, no, there it is again. And well, yeah, This time. Yeah, absolutely.

And to kind that, that not only has, you know, security implications, but it also has cost implications, right? Because so many of these attacks, like you said, don't end up being rocket science. So many of them, um, just from the, the articles and the the features and stuff that I've edited and posted are crypto miners, right?

They're ja, they're crypto jacking attacks, they use the containers to run this and mine crypto. So, and then tangentially folks are saying, okay, well that's not a big security issue, so what I'm just gonna, you know, move on to something that's a little more pressing right now, but that is straining your resources and it's, it's really costly. Mm-Hmm.

And that's also something that folks, especially at the beginning of 20 24, 20 24, yeah, we're in 2024 still all year so far. Um, you know, folks are a lot more sensitive right now to that, those kind of cost concerns. So it all ties together.

Yeah, I mean, crypto jacking for a lot of folks is still considered a nuisance crime. Mm-Hmm. They're basically a couple of, you know, dollars here and there off the monthly bill for my cloud provider.

I've barely noticed. I think the finance team starts to notice now they're basically complaining about the cost of cloud computing and they wanna know what all this stuff is, and that begets that whole fit ops practice out there that we'll probably talk about another day. Yeah.

But, um, when I look at it, the issue too is like, look, in order to run the crypto jacking, somebody stole credentials. Do you think that they're just gonna like, you know, not use those credentials for something else more malicious? Uh, there are.

They already are. Yeah. So I think crypto jacking is a symptom of a bigger problem.

Agreed. Absolutely. Absolutely.

I think the only other thing that's been going on lately, and it's not directly related to this, but since this is all about cloud native and we should be tracking these things, dockers up to some interesting things in the land of application development. Mm-Hmm. Essentially they have created something called the Docker build cloud, and it uses some basic capabilities that were in the desktop platform and makes, turns 'em into a cloud service to manage your build.

The interesting thing is they're positioning that against quote unquote legacy continuous integration platforms, AKA DevOps platforms. And they're basically saying is, uh, developers can manage this process on their own and maybe don't need as much help from a DevOps team. They're all for working with CICD platforms.

So if you have one already, they're like, that's fine and dandy, but they're trying to build that process and take it into something that's a cloud service that, um, I don't know. You could argue it's an alternative form of continuous integration, but you know, in their, in their language, it's clearly something that they wanna position against. So it'll be interesting to see, you know, how much developers respond to that.

I think individual developers, small companies may like that approach. I think a lot of larger enterprises already have invested in the CICD platform, so they're gonna be like, why do I need to reinvent that wheel? But, um, it's an interesting time and I feel like there'll be a lot of discussion about this in the coming year.

I think so too. I agree. Maybe that, uh, we can look into that some more and, uh, continue the conversation next week.

Yeah. I'm hoping 2024 turns out to be the year we finally get this app dev thing for Kubernetes. Right.

And containers, but, uh, cross your fingers as they say. Yeah. We'll see, we thought that was gonna be 2023 too.

There you go. It seems like everything we do in this particular area is like just we're a year behind going full circle of the conversation. It all depends on where the people are in their journey.

Exactly. Exactly. But that folks is why we're here and we are excited to bring you along on this journey with us.

Um, as we are wrapping up, we want to invite you to please, uh, check out links to all of the content that we referenced in this conversation. We're gonna put them in the show notes at the bottom so you can go through, check those out at your leisure. And, uh, if there's something you want us to talk about here on the Cloud Native Now podcast going forward, please reach out and let us know.

We would love to hear from you and, uh, to know what you're thinking about in this space. com. I will also put that in the notes.

You can reach out to me and, uh, keep the conversation going. All right. So, uh, yeah, I think, um, any final thoughts you have here, Mike, as we're wrapping up our En enjoy the chat.

We're gonna also have a lot of guests on this podcast as we go forward in the, in the year, so stay tuned and we'll see you all next time. Sounds like a plan. Thanks so much.

Until next week.