Kubernetes Management – Cloud Native Now Podcast EP22

Hello, and welcome to the latest edition of the Cloud Native Now podcast. I'm your host, Mike Biard. And once again, we're with Paul Nati, practice lead for FU and group for application development.

31. Paul, welcome to the show. Hey, great to be here, Mike.

Yeah. Um, what is your sense of this release? 'cause I think there's a cadence starting to emerge.

We're, um, every, the third release is usually like a maintenance update with some additional capabilities added and maybe not stuff that is so earth shaking, and I'm trying to figure out where this release fits in that overall three updates a year. Cadence. Yeah, absolutely.

31. It really, um, does add in a number of enhancements, right? As we see that there's 45 different enhancements that have been brought into this release.

Um, 11 of them have graduated to stable, to your point, right? Like, what's, what's required and what's not required. Uh, 22 are, are entering beta and, and 12 of those, uh, enhancements are, uh, are in, uh, alpha project stage.

So, you know, when you look at those 45 enhancements that have been made for, uh, for Kubernetes, it's, it's really, um, working with the technical oversight committee for Kubernetes. Um, they, they basically understand what it is that's a priority, uh, why it's a prioritized, and then how you move those different functionalities up the stack for release. Um, I, I do believe that, uh, the, the, uh, the release of these, uh, additional enhancements are driving towards the, uh, the, the, the continuous adoption such as open container initiatives that help with, uh, imaging and, and artifacts.

Um, and then, and then also other, uh, areas around API integration as well. So, so there's definitely some, uh, some areas here that, that tie to, uh, the, the release of the functionality as well as what I'm seeing in research that says, this is what the audience is looking for. All time out for a second.

Audio is great. Stop moving. All right.

Oh, Sorry. I'm Italian. I Can't, there you go.

All right. Do the best you can. Um, all right, well, let's pick that up from here, because one of the things that has always perplexed me a little bit is the people who are behind Kubernetes are hardcore DevOps proponents, and they want everybody to stay current and can make sure they're doing their upgrades and minimizing technical debt.

The reality is quite different. Um, most of the enterprises I talk to have versions of clusters that go back as far as 12, maybe even earlier, and they're kind of hesitant to, um, upgrade 'em because they're worried that some API will go away. And, and then as a result, whatever application they have will break.

And, um, and it almost feels like they're just relatively content to stay where they are. And if they have a new project, they'll go to the latest version of Kubernetes, but they wind up with all these different flavors, and sometimes they have multiple distributions from different providers. Um, what is the current state of Kubernetes management in your mind?

Yeah, it's a fair question. I mean, I definitely think that the backwards compatibility across the, the, you know, bridging the gap between the old and new, it has to be there. Um, there has to be a frictionless way to move forward.

But we also, one of the things that you didn't touch on that I think is important to understand is the reason why a lot of times these, uh, releases happen, um, as frequent as they do, is to protect the, um, the, the application in the tech stack that's, that's going along with it. There's, uh, off sometimes security holes or phones, sometimes, uh, functionality is, is the APIs, like you were saying, are not working because those APIs are not working. Um, the, the, the patches may, uh, enhance that or fix that.

Um, but regression testing is important, obviously, when you're looking at the release of these development. Um, but seamless integration across the different, um, tech stacks, especially as, uh, you know, the, uh, different locations, different applications, different silos of applications within data centers, um, all have, uh, various versions of applications as they're running. Uh, on a previous episode, we talked about, you know, the, the integration between system of records and systems of engagement and new systems of engagement might be using the latest and greatest, uh, you know, uh, tech stack in order to kind of put out their, their solutions.

But they might be connecting to previous versions because those previous versions are just encapsulated and basically left to, to be used as a system of record. All right, well, um, are we getting to the point now where mere mortals can manage these Kubernetes clusters, or do we still need that kind of DevOps slash software engineering expertise to manage Kubernetes? And I think there's a lot hinging on this because the pace of adoption of these Kubernetes clusters is really, in my mind, not so much tied to the available budget as it is just the number of people with the skills required to manage these things.

Yeah. Well, you know, I think what we're seeing in this, in, in this landscape is, uh, definitely a driving factor for consolidation in the vendor space. And, and, and the vendor space is really what's happening to, uh, helping those or, uh, organizations and those individuals manage these classes.

For example, uh, D two IQ was acquired by, by, um, Nutanix, right? As an example, uh, D two IQ focused on the management of Kubernetes clusters. Um, there's a number of other technologies out there, like Raffa, for example, that that manages, uh, more than just Kubernetes clusters.

They manage the BMS now. Uh, but the, the business models that came out initially was to solve exactly to your point, how do you let, um, uh, organizations DevOps teams, platform engineering teams, um, easily manage their environments? Uh, and, and, and, and by using it as specific tech stack, they, they allow you to do it.

But what I'm seeing, Mike, is, is organizations are, uh, larger organizations are seeing the value of these, uh, emerging technology stacks, um, to, and to provide that ease of use for, uh, for Kubernetes clusters, uh, holistically. So you, I think what we're seeing is that consolidation in the market for, of the market landscape to bring in that tech stack into the larger opportunities that are out there All. Well, that kind of brings us to our next two subjects.

0. I think, uh, if I recall correctly, this project was kind of started by AWS back in the day, and it's supposed to make it simpler to manage, uh, the underlying compute infrastructure that Kubernetes is consuming. 0 and I, I think maybe this thing has been around for a year or two or more.

Um, what is your sense and where does this fit in the cloud native landscape? Yeah, you know, I Carpenter has, was announced a, a, a while ago as a, as an opportunity for, you know, to, to, uh, basically respond to, uh, adjustments in the, in the, in the, in this, in the underlying tech stack, the app, uh, working towards application loads and such. Um, I think that there has been some readjustments and some, some shifting because, um, when Carpenter first came out, it was really about driving towards a, uh, harmonized, or, or I, I'm sorry, like really a very focused delivery of, of tech that's within, um, uh, specific, uh, distribution.

What the, the re kind of, uh, uh, rebirth of it. I guess the reason why it took so long for it to kind of come out in my opinion, is there's an understanding of harmonization across multiple architectures, and there need to be, uh, a carbon and need to have that, uh, ability to offer that lower cluster compute cost, uh, across those different, um, underutilized nodes. And those underutilized nodes need to be, uh, driven across different architectures.

And that's where I think that there was, uh, some disruption in the delivery cycle of it. But I think it's all in all, uh, uh, it, it promises to be a way where developers can, you know, use the Amazon, uh, you know, EKS in order to, um, you know, uh, or, or, you know, use Carpenter to kind of use those clusters and, and deliver, um, adoption across EKS users, but also it has the ability to scale out across the multiple, uh, architectures as well. Mm-Hmm.

So are we starting to see the centralization of Kubernetes clusters then? Is that kinda, um, and I don't mean reducing the number as much as, I just mean kind of folks getting a, a control plane that kind of spans them all and lets them manage them regardless of version or distribution. Yeah, I, I mean, I think that that's the logical approach.

I mean, standardization, it reduces the number of tools. I mean, if you look at how carpenter drift is, is working, you know, it, it allows for that, uh, utilization of a desired state of, of, of using Amazon Machine instance and basically, um, moving away from a very specific delivery and, and, and using it across the entire ecosystem. I think that's really where, uh, developers will help balance that availability across the, the, not just the, the, um, utilization of resources, but also security requirements.

And I think that also has the ability to, you know, provide, um, consolidated functionality that you wouldn't necessarily get, um, by using these individual deployments. Alright. And now, shifting and gears slightly to raf, um, they just came out with the ability to essentially apply financial controls, AKA finops to your Kubernetes management framework.

Um, is there a difference in your mind in terms of what Rafa is providing that we wouldn't see in a lot of the open source tools and B um, has finance tools essentially become an extension of the management framework and or do we still need these kind of standalone finops tools? Yeah, I mean, this is a great one that, I kind of alluded to it a little bit earlier on the, on the different platform management of Kubernetes clusters. Uh, HA has, and, and Sean, uh, at, at at Rafa, um, I met with them, uh, not too long ago, probably a couple, maybe a week or two ago.

And we talked about, uh, the finops kind of play and what they're doing. But you know, it's not just about, um, the finops play. It's about that up level and Rafa, Rafa refa to be, um, more focused on, uh, adding additional value.

So this cost management is key. Um, but managing your entire ecosystem is also equally is, is important, right? Because again, one of the things that, um, Rafa when it first came out was about simplifying the, the Kubernetes cluster management.

And that was, you know, but over the, over the past year or so, there's been a pivot to move away from just the Kubernetes cluster management, which is important, by the way. Um, but to really focus on what it means to do cost, uh, and also understand that, um, looking at historical consumptions workloads, uh, and, and then also provide those chargeback models. So I think that they have additional value add here, uh, is really providing that, that functionality where automating cluster provisioning or automating infrastructure, uh, and, and basically providing self-service experience for developers are key areas, uh, for, um, for the, the developer productivity and for what Rafa can provide for this, for the, you know, for the latest offering.

It also seems like they're at, let me try that again. Right. It also seems like they're at, no, hold on.

It also seems like they're at the forefront of the democratization of Kubernetes 'cause their framework is accessible to your average IT administrator. And, um, and I wonder, um, there's a lot of work being done on these various other open source projects, and I know that Rafa is a commercial entity, but, um, at the end of the day, um, is cost really the big factor here for the management plane, or is that something people are willing to pay for? I, I think cost is part of the maturity, uh, the Kubernetes adoption, you know, once you actually have your, uh, clusters running and, and implemented, um, understanding the cost factors, uh, really does come into, into consideration.

Uh, I don't think it's the, The primary source of information. Like, I don't think that if you, uh, are starting to modernize or refactor your applications, the un unfortunately, the first thing that organizations, you know, they don't think about is cost. They think about how, what does it take to do this?

And they want some type of cost factor that, that allows us to say, this is what it means. But a lot of times the organizations that are doing the refactoring are looking at the resources needed and, and pro often overprovision those resources because they want to get to make sure that they need to get done what they need to get done. Um, but cost does come into a consideration once you start going into production.

And, you know, once you start running and production, you know, if you're running at, you know, 50, 50% of the provisioned resources, then you can easily give up some of those resources for other projects. That's where, um, you know, understanding what your, your Kubernetes clusters are doing really matters. But again, it's a part, I I would call that more of a phase two part of the maturity.

And most organizations open at it that way because phase one is understanding the skillset to do the actual refactoring. I call that the adult supervision phase. 'cause so many of the developers are, to your point, they over provision Kubernetes cluster.

'cause that's what they were used to doing in virtual machine environments. And they're like, you know, gimme the biggest, baddest amount of machine you can get. And, uh, you know, devil with the cost, that's not my concern.

I just wanna make sure my app is available. So if the resources are yeah, you know, available or rated one to 10, they're always out of 10. So I think that requires it people to come in behind them and make those adjustments.

And as long as the app doesn't crash the development, probably we'll never know. Yeah, exactly. And that's the, that's the thing is that if you put those cost controls in place and the, you know, the, the application developer or the DevOps team, um, you know, has, what they need is as long as they have what they need, there shouldn't be an issue.

Right? And that's where I think Rafa can come in and basically, uh, do an, an understanding of the environment and then right size or right provision the resources for, for those teams. That's really where I think this is comes in.

But again, in my mind, unfortunately, this is not top of mind when it comes to that modernization effort. It's really a kind of an after afterthought. And, and to me it really does need to be moved into the primary part of the refactoring.

It needs to be moved into that understanding what is it gonna cost to do this? What are the actual costs to deliver, Right? I mean, otherwise you're buying a house without really understanding what it means to live in it, right?

So there you go. Correct, Correct. Yeah.

I wanna shift a gear to, um, service meshes. And I don't think we've actually talked about this topic before, but there's a new update to linker D and they added support for IP six and a couple other nifty niceties in the ne networking space. Um, what is your sense of where are we with this stuff right now?

Because a lot of times I talk to folks and, and they need a lot of APIs before they wake up and say, I need a service mesh for as an API and Gateway, or, um, sometimes they'll just use the proxy software and um, and then they have a choice between linker D and Istio, and, um, it seems like Linker D does 80% or more of what I need, and Istio probably can do a few more things, but maybe only large enterprises care about those things. But there is a lightweight version of Istio. So where are we in this battle?

And there are other service meshes out there for that matter as well. Yeah, absolutely. I mean, this is a conversation that, um, you know, I've done a, i I have a number of, uh, data points and research around service mes.

I've done a lot of conversations with, you know, the likes of, uh, uh, the, the, the commercial versions of Istio and the commercial versions of Linker d whether it would be Summit by Solo or Kong or any of these other companies. Uh, there, there's a number of areas that, um, um, that I think is interesting when it comes to service meshes. Uh, a a a while back and maybe, maybe about a less than a year ago, or maybe so, uh, the analyst community, uh, when somebody from another analyst firm put out a, a report saying, you know, our service mesh is actually worthwhile and or worth the effort or work the problem.

And, and my opinion is, I believe service meshes are indeed an enabler for success. Um, and then that's allowing for not just that east, west and north south traffic or they using API gateways or service meshes to confer application communication, but it's also about streamlining the number of API calls API calls get expensive, alright? And they get super expensive.

So if you can streamline them with a service mesh in order to reduce the number of calls using, um, you know, uh, maybe linker D'S approach or, you know, an Istio approach, uh, using the, the, the, you know, Envoy as a proxy or, or you know, or not, um, that there's different ways to reduce those API calls. And if you can standardize that, that helps. Now, what I like about Anchor D is it has some heritage in the, um, uh, in the, in the, in the, I call it the legacy applications or the older applications, and has the ability to not just work with cloud native, but also work with those applications that are you mi maybe migrating away from.

And, and that's something that, uh, has been incredibly, um, important because it's, again, bridging the gap between your heritage applications in your new way of delivery. Uh, you need to have that way of communication between those applications, uh, while you're doing that work. If you don't, um, then you have these silos of tech stacks and then that increases your tech debt and, and if there's a desire for many organizations to reduce your tech debt, um, and, and, and start pulling back from the different, um, you know, multiple, multiple tech technologies to do the job.

So I think that there's a lot of, uh, power behind this linker d announcement. I think that there's a lot of interest around, uh, again, the way I view it is that bridging the gap between the old and new, but I think that there is also some, the, some of the new technologies that there are enhancements that they put in LINKERD that allows us for the cloud native deployments to be more efficient as well. So like what they're doing, um, like that it comes with, you know, support for JSON output.

So you can automate, you can bring that piece in. That's a, that's a cool feature that that's been, that that kind of drives toward that automation piece. Um, you know, uh, but there's definitely reasons to kind of go with the H approach.

I am a, I am for service mesh, um, you know, as an analyst, I, I definitely know that the research I've seen, uh, organizations are pulling to use service mesh. So I think that that's a, it's worth the investment. It's worth the time to think about it.

All right. And then lastly, there's an article on Cloud native now talking about, um, how to apply policies code to GKE. And I'm sure that's helpful to a lot of folks, but what is the state of policy as code right now?

We've been talking about this for a long time, but it's not clear to me that everybody gets it and some folks think it's just hard. I, Yeah, I mean, this is one of those things that's interesting. Policy as code is, uh, and the, the way I view it in the CI ICD pipeline is you have to have, um, a skilled or, you know, basically a high, uh, resource, higher value resource deliver, um, the, the, the workflows in order to imp implement your policy within your CICD pipeline.

Okay? But in order to streamline like everything that we're trying to do and deliver code faster and push applications up the door quickly in order to do that, um, implementing quote as code or policy as code, um, requires some type of version and control, but it also enables automated enhancements and integration within that CICD pipeline. So you can ensure that those policies are applied across the environment.

And as you've heard me say, you know, a thousand times that the accountability is, is on the organization pushing out the applications they need to be accountable for what they're delivering. And by putting in policy in AS code, it does reduce the, the human error part of it, but it also increases the ability to do automation. So again, I look at policy as code as part of that maturity cycle within organizations.

And if they can have a strong maturity across the CICD pipeline that allows 'em to do, um, more rapid del delivery of the, of the applications they're trying to push out the door. All right, folks, as always, we've been up and down that cloud native stack again. Um, and it remains complex, remains challenging, and the issues go well beyond Kubernetes clusters itself, but hey, they are becoming slowly but surely more accessible.

Hey, Paul, thanks for being on the show as always. Thank you, Mike. It's great to be here.

All right, and thank you all for listening to the latest edition of the Cloud Native Now podcast. You can find this on all your favorite outlets, and of course, you can find it on the homepage for cloud native now. Thank you all for listening, and we'll see you next time.