Viktor
00:00:00.000
And you have two choices. Replicate that behavior. I'm not saying make it the same. Replicate it. Make it irrelevant whether it's Kubernetes behind that something or something else. I mean, use Kubernetes. That's the only thing that makes sense. But that's implementation detail for people. Make it Heroku like experience. And if you cannot do that, that's fine. This is DevOps Paradox, episode number 3 0 7. Kubernetes in 2025.
Darin
00:01:25.732
We're going to continue our thoughts on things that are happening in 2025. Today, we're going to be taking a look at a blog post from Fairwinds about Kubernetes in 2025. Viktor's taken a quick look at it. I've taken a quick look at it, but quick being the operative word. So we're going to, the link to this article is going to be down in the episode description. It'll be interesting to see how it plays out. It starts with the lead of, now Kubernetes is 10 years old. Okay, Kubernetes is no longer a toddler.
Viktor
00:01:57.732
No, definitely not. The adoption tells it all, right? I don't know the numbers and all those things, but it's massive, it's massive. People are running it in production, seriously. Not like three servers, five servers now, we are talking about large scale,
Darin
00:02:25.907
Well, let's hold on clusters because that comes up in this, but the first point is containers and container management. And I'm not going to read the whole thing. I'm going to read the one line that's bolded. So if you're reading along with us, check it out. Expect Docker and Kubernetes use in development and production environments to continue to rise as the technology and ecosystem mature. Well
Darin
00:02:52.207
Container use has grown consistently over the years and is now holding steady at about 84%.
Viktor
00:03:00.602
Yes, so how much more do you expect it to grow? I'm now referring to the second sentence. It will continue, uh, where was it, continue to rise as the technology and ecosystem mature. It's already at 84%, according to you. It's not going much higher than that, unless we defy statistics.
Darin
00:03:25.117
Yeah. At 84%. I might see it going up to 90, but I don't, I I don't think it's gonna get beyond 90. You're, we are not gonna be at a hundred percent runtime on Kubernetes ever.
Viktor
00:03:37.442
Absolutely not. And to be honest, I honestly doubt that it's 84%. I would be skeptical if it said even 50. Because we still have a lot of legacy systems, right?
Viktor
00:03:56.462
Yeah, mobile apps, or, hey, we have mainframes still running, right? I'm not saying that mainframes are 90%, but there is a lot of tech. Things are So I would guess that if somebody says 84 percent of companies are using containers, yes, I would have no doubt about that. 84 percent and that's what really matters of workloads are in containers, absolutely not. And if you understand it like that, then yes, it will continue to rise.
Viktor
00:04:37.057
It's not a novelty anymore, right? Everybody knows about it. Everybody's using it. There is hardly a person who doesn't use Docker these days.
Darin
00:04:45.977
Okay. Containers going to keep growing. That's pretty much a no brainer. We agree with that. Even I, the anti container person, Just saying, yeah, that makes sense. Okay. Kubernetes use cases. Again, I'm going to fast forward to the big, bold line. Expect these use cases to remain stable. So we're talking about all the typical use cases, hybrid, multi cloud, new cloud native apps, modernizing existing apps, okay, right. That's going to keep happening. And AI, ML, and Internet of Things use cases to rise in the year ahead. Again, that sort of feels, well, sure, because IoT and AIML is what everybody else is working on nowadays.
Viktor
00:05:36.482
Yeah, it's very misleading. What they should have said is that we will see the rise in ML and Edge workloads in the future. Because that will be happening, right? And then, yeah, they will be in containers, of course, right, mostly, predominantly. But it's just the result. It's not that. It's not that. There is a lot of AI and ML and edge that is currently not in containers and we are moving it to containers. That's how somebody could interpret that. But what really that means, or at least I hope it means, is we will see the rise of those. There will be many more of those in the future. And they will be running as containers, maybe FASM, in Kubernetes. Then yes. With that clarification, I agree completely.
Darin
00:06:32.727
Yeah. And okay. AIML, sure. We're going to have node sizes that have all the cool chips from NVIDIA and everybody else created. But I think with Wasm for edge stuff, again, we've talked about Wasm not being a thing still for 2025. If we're not doing Wasm on the edge, what are we doing? Anything just straight C? Oh, containers. Okay. Fair enough. I guess we can do that.
Viktor
00:07:02.252
It's not as if it's an overhead significant or anything like that, right? Kubernetes on edge, that's a challenge that we still need to pass, but containers themselves, that's not a problem.
Darin
00:07:12.842
Fair enough. Okay. Number three, developer sentiment. Okay. This is one I didn't even take a look at. So, cause again, we said we looked really close or not really close.
Darin
00:07:26.202
Okay, good. We'll, we'll live here just a little bit. So development teams continue to struggle with some aspects of Kubernetes. Really development teams continue to struggle with some as aspects of mainframe. Okay. Whoever wrote this at Fairwinds, I'm sorry. Um, I'm, I'm poking it a little bit and lemme go ahead. Uh, Andy, I apologize right now if you're listening to this, I am, I'm doing this in fun and in jest, but yes, these, this is one of those replace a word type podcasts today is replace Kubernetes with whatever you want. Love the scalability. Okay. I'm gonna fast forward. In the year ahead, dev teams are going to push back on the requirement to learn Kubernetes and ask for managed Kubernetes as a service and tools to make deploying to Kubernetes infrastructure easier so they can focus on building application and services. Um, I think that's happened since day one, isn't it? How is that
Viktor
00:08:22.662
it didn't because what was happening and is still happening is, and I don't think that to begin with, I don't think that this story changes whether it's managed Kubernetes as a service or not managed, right? That's not the concern of developers. What is really concerned is that since Kubernetes exploded, we switched to Kubernetes. We gave that Kubernetes as is to developers and say, ship. Ship your stuff over there. And that's bad. That's just bad, right? Because we are basically making their lives more complicated, more miserable, instead of improving their lives, improving their productivity. Nobody should give developers Kubernetes as is period. Either make it a platform where developers can easily deploy and observe and manage applications and whatever else they're doing, do it yourself, or choose that as a service. So if you cannot do it, and most people cannot, then don't go for Kubernetes. Go for Azure Container Apps, go for Google Cloud Run, go for FlyIO, go for something that did what you were supposed to do. And what you're not supposed to do is give. People kube config and say, go, please don't do that. That's not, that's not the end game. That's not the goal. I understand you got impressed with Kubernetes. I'm impressed with Kubernetes. But Kubernetes is supposed to be the base on top of which you create or you buy something that helps developers be more productive without forcing them to learn more. It took me years to master Kubernetes, and I cannot expect everybody else to spend years to stop doing what they're doing and spend years getting on the same level. Please don't.
Darin
00:10:35.115
new? It seems like, so are you stating or suggesting that that sentence should be rephrased as Dev teams are going to push back on the requirement and ask for platform engineering.
Viktor
00:10:46.290
Yes. Yes. Now, that's a, no, not for platform engineering. That's too narrow, too specific. Ask for something as a service. And when I say something as a service, I don't mean Kubernetes as a service. I mean, you know. Database as a service, application as a service, something, kind of, okay, so what do you need from me? You need, you need to know the version of my application, you need to know where the source code is, you need to know those five other things. Here it goes. Here it goes. Here it goes. Ship it. People should be, developers should be expecting Heroku like experience. And guess what? Have you used Darin and Heroku?
Viktor
00:11:37.185
Okay. Did you learn the details of how Heroku works, the inner architecture? Did you go through the code of Heroku?
Darin
00:11:48.470
No. I said, here's the YAML file that told me to put it in my repository, put it in there, configured it that I needed to do and pushed it. And off it went.
Viktor
00:11:59.635
Exactly. And that happened, what was it, like 10 years ago? 15? Nobody knows. Long time ago, right? That's the expectation. They set the bar. And you have two choices. Replicate that behavior. I'm not saying make it the same. Replicate it. Make it irrelevant whether it's Kubernetes behind that something or something else. I mean, use Kubernetes. That's the only thing that makes sense. But that's implementation detail for people. Make it Heroku like experience. And if you cannot do that, that's fine. Allow them to use a service that does that. Allow them to use Heroku if you cannot make your own Heroku. Or FlyEye, or Google Cloud, or whatever you want, it doesn't matter, right? Either you do it, or let them use a service from somebody who did it. I don't want to listen to Kubernetes for, uh, for developers. Kubernetes is something that we should build a solution for developers, not give them Kubernetes. That was a rant. Did I sound angry? Probably, a little bit.
Darin
00:13:09.840
It could be, uh, for history purposes, Heroku started in 2007. So it's 17, 18 years old.
Viktor
00:13:19.495
There we go. And I remember when I saw it, man. Something clicked in my head. That was a light bulb. That was Yes. This is the thing. This is what I want.
Viktor
00:13:36.872
That type of experience, yeah. I'm not saying that I want Heroku per se, but yeah, that's the experience I want. I want to be able to give the information, provide the information that matters, and get the result I expect.
Darin
00:13:53.626
18 years later, you still want the same thing that you wanted back then. Again, details are a little bit different, but the concept, you still want that experience.
Viktor
00:14:02.011
If I would be a developer, I'm not a developer, just to be clear, or not that type of developer, right? I'm a Kubernetes guy. I want Kubernetes, Kubernetes, right? But if I would be a Node. js developer, that's what I would want.
Viktor
00:14:16.993
Yeah. As if that makes a difference. What's the difference between you setting up on prem Kubernetes and managed Kubernetes? It's equally nonsensical. To me, this thing in bold kind of like, ask for managed Kubernetes as a service. No, they're not going to ask for manage Kubernetes as a service, they're going to ask for not to see Kubernetes. It's implementation detail. Now, just to be clear, I don't want people listening to this to get the wrong message. I'm not saying that there shouldn't be Kubernetes, just to make it clear. I'm all in on Kubernetes, there should be Kubernetes, I just don't think that people should be seeing it.
Darin
00:15:02.276
It's like an engine in a car. You want it there, but you don't need to go under and work on it every day. You don't want to go in and work on it every day.
Viktor
00:15:11.551
You know, I always use that, not always, often that example. That example is hypervisor. I haven't seen hypervisor in a long, long time, and whomever doesn't know what hypervisor is. Great. That proves the point. But I can tell you that you're using hypervisor. If you don't know what it is, I can just tell you that you're using it and I'm glad that you don't know what it is
Darin
00:15:37.472
Let's move on to the next one. I have a feeling we might come back to that though. Monitoring and observability. I'm going to lead with the first sentence. Kubernetes is a dynamic and distributed environment which can make it more difficult to get insights into application performance, health, and resource utilization. Mainframes are a dynamic and distributed environment which can make it more difficult to get insights into application performance, health, and resource utilization. Okay. Again, we can swap that out. Fast forward. Right AI are for anomaly detection. And performance analysis. Okay. But we expect this to change as more companies adopt AI enabled tools to help them make the most of their Kubernetes investment.
Viktor
00:16:26.487
Such a nonsensical, sensical sentence. I mean, I agree. Let's start. I agree with the first half. AIR for anomaly detection and performance analysis, yes, that's, I think that that's a reality. I'm not sure how good they are at those things, but that's where we see most results, right? Hey, tell me what's wrong with this. That's my summary of that, right?
Viktor
00:16:54.787
Uh, now, change as more companies adopt AI enabled tools to help them make the most of their Kubernetes investment. I honestly don't know what that means.
Viktor
00:17:09.250
What I can tell you is the end goal, yeah, the end goal is not for me to ask AI what's wrong. The end goal must be within this context, not AI in general. It must be, I fixed the problem for you, or I don't know how to do this. Can you come, come and help? Same thing as junior developer, right? Just fix it. Don't ask me questions. Thanks. Call me when, when it's something that you're not capable of fixing.
Viktor
00:17:48.095
yeah, but slowly it will take time within the context of what we're doing ops, you know, in a sense, we already spoke in the previous episode about development, right? Within ops, what I feel must happen is some level of performing actions. Not, let me ask you, is there something wrong with my pods? Yeah, useful, but not a thing.
Viktor
00:18:21.152
Yeah, especially And I don't see that happening much, I might be wrong, if that operator can learn from me. You saw me restart this pod five times to fix this issue. How about you restarting it the sixth time? You figured out the behavior, you learned from me. I'm not even asking AI to know what to do. I'm asking AI to learn from what I'm doing. And then do that instead of me.
Viktor
00:18:59.607
Exactly the same. Hey, did you watch me do this five times? Joe? Yeah? You did? Excellent. How about you don't call me the sixth time? When that exact thing happens.
Viktor
00:19:18.320
Yeah. You saw the operations and you s So, you saw the calls, you saw the operations, and you saw the, the end result. Right? Now, when you observe the same behavior, perform the same operations, and And call me if the outcome is not the same, and I'll jump in. And you will keep learning, and more, the more time passes, the more you learn, the less you need me. Wouldn't that be awesome?
Darin
00:19:56.220
That would be awesome. Moving on to the next one, Kubernetes impact on other development trends. We'll go through this one a little bit quicker because we have yet to reach their predictions for 2025. So the first sub point of this is cost optimization. In 2025, we expect IAC and cloud optimization currently at 56 percent to rise significantly as well as failover and disaster recovery. Uh, yeah, people have gotten burned and they need to have failover because they never put failover in before because Kubernetes, you don't need failover. No, you do. We're now at the operational point in Kubernetes lifecycle.
Viktor
00:20:38.160
You know, I have a serious beef with the name of that thing. I don't like the name cost optimization. It's not cost optimization, it's resource optimization. Cost reduction is just a side effect. I know I'm nitpicking here, but that's what we're really doing. We're trying to figure out how much memory and how much CPU this thing needs. And we adjust it so that it uses just the right amount of compute. That's what we're doing. It's resource optimization. And guess what? It might result in higher cost or lower cost. It might cost more, just to be clear. We don't know, but we are doing resource optimization. It just doesn't sell so well, right? You cannot sell for a lot of money if you go to a company and say, you know, would you like to pay me a lot of money to do resource optimization? They say, no. But if you say, hey, would you give me money if I reduce your costs? That's so much easier to sell.
Darin
00:22:01.036
Next up, point security. Again, going to the bold. While most organizations may not have encountered a problem with Kubernetes security in 2024, expect malicious attackers to focus more on targeting Kubernetes infrastructure as enterprises increasingly deploy mission critical applications to production. Yes.
Viktor
00:22:20.391
Yes, again, I always have a problem with the part in bold, with the final sentence. While most organizations may not have encountered a problem with Kubernetes security in 2024, you did. I am not sure whom you asked, but they did. They did experience security issues. Everybody did. To some extent or another, right? And uh, yeah, malicious attacker will be focusing more on targeting Kubernetes infrastructure. Uh, but not as enterprises increasingly deploy mission critical applications to production. We already concluded at the first point that majority of enterprises are running in production Kubernetes. There was 84 percent some figure over there, right?
Darin
00:23:18.721
Last sub point, microservices. Again, straight to the bold. In 2025, expect the use of microservices on Kubernetes to remain the same unless a new technology emerges to change the game. Well, in theory, Wasm was the technology to change that game, right?
Viktor
00:23:33.023
Yeah, but I agree with general sentiment. This is rare for me to agree, actually, something with this article, but yeah, we reached the pinnacle of microservices. I still think that you should be doing microservices, unless you're a very small shop, but I think that we reached kind of the point where you're either doing it or you're not. I don't think that companies are now focused on, oh, let me, let me move to microservices if I'm not already there, right?
Darin
00:24:01.008
If I take a monolith and break it apart to 75 microservices, I probably did it wrong.
Viktor
00:24:12.023
Same thing like with containers. If you haven't moved your applications to containers so far, you're not moving it tomorrow, right? I mean, somebody might, but that will not be a significant increase.
Darin
00:24:25.041
here are five other predictions. The use of Carpenter, the open source project from AWS, will explode, helping users improve both application availability and cluster efficiency, based on application workloads in AWS environments.
Darin
00:24:42.206
Sure. Sounds good. This is the point that I've been waiting to get to the whole time. Organizations using Kubernetes will consolidate clusters to increase efficiency and simplify management.
Viktor
00:24:54.895
Am I interpreting it right? And I know that you don't have a definitive answer, meaning that we're not going to have hundreds of clusters for no good reason anymore. We're going to consolidate it in a few. And if that's what it means, then 100 percent yes.
Darin
00:25:09.337
That takes us back to the cost optimization, even though you were saying resource optimization. This is interchangeable for this one point, I think.
Viktor
00:25:17.769
yeah, because there are two things in play there. First, each Kubernetes cluster requires additional resources or nodes for control plane, right? So hundred clusters means 300 nodes, just doing the, not running your workload. Right? Uh, so less clusters means, Less control plane nodes. They might become slightly bigger, but still less. Second, the bigger the nodes and the more nodes that are in the same cluster, the better job tools will do at distributing those across that cluster, right? You will have less potential, less wasted CPU and memory in smaller number of clusters and with bigger nodes.
Darin
00:26:13.012
This is a variation of when we bin packed applications onto servers before Kubernetes existed.
Viktor
00:26:20.231
Here's a simple math. This is a very ridiculously simple and say you have a node with five gig. You have applications that require two gigs of memory, right? You have two nodes of 5 gigs or one node of 10 gig, which one is going to be more efficient?
Viktor
00:26:43.591
Because that node of 5 gig and applications require two is wasting one gig on every single node.
Viktor
00:27:02.351
Yeah, of course. Never have less than three nodes if that's what we're talking about. But yes.
Darin
00:27:08.131
but that's also sort of the key point to this is, okay, what are your trade offs? Because earlier we were talking about, okay, failover and disaster recovery is coming more into play. So maybe you weren't doing that in the past. Maybe you were running that single node cluster
Viktor
00:27:24.016
Oh yeah, here's another secret. If you have a single node Kubernetes cluster, you shouldn't be using Kubernetes.
Darin
00:27:29.589
don't disagree. Next point, uh, our clients speaking of fair winds and others relying on Kubernetes infrastructure will experiment more with multi cloud and hybrid strategies, as well as with on prem and bare metal deployments. I would have probably said in mid 2024, I probably would have agreed with this. I'm going to have to disagree with this. I think money's going to be getting tighter this year, and I don't think you're gonna be playing around as much.
Viktor
00:27:57.069
I think that people's fantasies about multi cloud are going to end, hopefully soon, and they will realize that it's just too expensive to run things in both Azure and Google Cloud and AWS at the same time, on many different levels. First experience. Right. Second, uh, it simply doesn't make sense. Right? Kind of, what they, what they're doing. What I do see happening is that there are companies acquiring other companies, and then you're at AWS shop, and then you acquire a company that has everything in Azure, and then you say, Hey, I'm going to keep your stuff there, right? That's kind of fine, because it's cost too much to move from one to another. But, uh, I think that the benefits of multi cloud as a design choice are just. Now, what I do agree completely, and that's hybrid strategies in terms of cloud and on prem, for many different reasons. One of those being that you cannot just move, if you're a bigger shop, everything from on prem to cloud. Right? You simply cannot. And if you can, it's going to take a lot of time, so you need a strategy how to run in both. and then there are other benefits. Say I already have hardware, I need cloud for peak loads and so on and so forth. Or I need cloud for this specific service because they do it great, but I'm confident with something else running it myself. So that I can, I would buy more hybrid as in on prem and cloud than multiple clouds. I see more benefits there.
Darin
00:29:59.901
Next point, VMware clients will begin migrating away from the platform due to rising cost, licensing changes, support, concerns, and vendor lock-in. Those looking for alternatives now have mature and robust virtualization alternatives that support the shift to cloud native and containerization. Those choosing, oh, the last sentence. So those choosing to migrate to Kubernetes will find the journey worthwhile. That could this is yes, , everything was
Viktor
00:30:29.906
Yeah, kind of, uh, will they be, will somebody move from VMware as being their provider, no matter whether we're talking about Kubernetes, like Tanzu, or virtualization, or something else? Yeah, maybe, who knows. But then that's not the same as choosing to migrate to Kubernetes. You can stay with VMware and migrate to Kubernetes. There's something called Tanzu, that's perfectly fine. I
Darin
00:30:58.319
And finally, modern DevOps teams will augment teams with external expertise. Remember, Fairwinds is a vendor to allow key SREs time to focus on application tuning, reliability, and developer experience. This takes me back to the AI point, right? The AI should be able to just do those application tuning and reliability and not developer experience, but do SREs really need to be doing developer experience?
Viktor
00:31:23.703
mean, does that mean Will modern DevOps teams will continue asking for consulting services from consulting companies? Probably, I don't know. Should they? Probably not. Will they? Probably they will.
Darin
00:31:41.956
So anyway, out of all these, I think the Consolidating clusters out of everything I've seen here. That's the big point
Darin
00:31:50.491
people are tired of paying the extra however much. Plus if you're on AWS and you're not keeping upgraded and you're having to pay the, the premium fee for the control plane, you know, there's there's a lot of money that could just be lost.
Viktor
00:32:07.022
part of the reason why we saw explosion in a number of clusters, sometimes that makes sense, sometimes it doesn't, but part of the reason I feel lies in confidence. Right? I have this Kubernetes cluster, and I'm not really confident that everything works as expected, that everything is isolated as it should be, and so on and so forth. So when somebody asks me to move their stuff to a cluster, it's more comfortable for me to say, here's a new cluster for you, than to actually plug that team into an existing cluster. It's fear, in part.
Darin
00:33:02.284
If you've had time to prove it out, then the answer is yes. If you're just now starting with, you haven't gone through that cycle yet. So how do you rate this, Viktor? The post.
Darin
00:33:27.278
No, we don't even get nines or tens. We're doing good to get a five, right? Depending on where we're at in that time. Yeah. So what do you think? Do any of these ideas, these predictions from Fairwinds make sense to you? Do they say, boy, they've been reading my mail? Head over to the Slack workspace, look for episode number three zero seven in the podcast channel and leave your comments there. We hope this episode was helpful to you. If you want to discuss it or ask a question, please reach out to us, our contact information and a link to the Slack workspace or at DevOps paradox.com/contact if you subscribe through Apple Podcast. Be sure to leave us a review there that helps other people discover this podcast. Go Sign up right now at DevOps paradox.com to receive an email whenever we drop the latest episode. Thank you for listening to DevOps Paradox.