Kubernetes Becomes a Tweener – Cloud Native Now Podcast EP15

Hello and welcome to the latest edition of the Cloud Native Now podcast. I'm your host, Mike Baard. And guest, as always is Paul Nati, who's, uh, practice lead for application development for the FU and group.

Paul, good to see you again, Mike. Great to be here. All right.

Hey, guess what? We're having a birthday Kuber. He can you believe it?

I mean, did You bring up president? I, I dunno, I I didn't get invited to the party Exactly. So, uh, I'm catching up on it a little bit.

Um, I suppose the issue that I'm trying to wrestle with in my mind a little bit is, it's been 10 years, but I feel like its maturity curve is a lot lower and organizations are still kind of wrapping their arms around it. I feel like there's, on the one hand, it's becoming something of a defacto standard. A lot of the new applications seem to be deployed on Kubernetes, yet people still complain about managing it, develop route.

Most of 'em don't seem to like it. The data science crowd is now discovering and they don't much care for it either. So is this becoming rapidly, you know, the platform we love to hate?

What's going on? Well, you know, I, I think you, you touching on some really good points. I mean, when I think of the, the conversations I have in my practice, I, I focus on past, present, and future.

So there's a lot of applications that live in their, their heritage state, and they're still, believe it or not, trying to get out of their heritage state and move to the cloud, move to, uh, you know, different present state kind of deployment models. And those present state deployment models could be containerization or microservices. And of course, using Kubernetes to do the orchestration around it makes a lot of sense.

But, you know, I think that there's a, a, a clear adoption that's happening. Um, you know, with, with regards to net new applications, we see that 72% of databases are running in, uh, cloud native platforms. We see 67% are running analytics.

54% of AI and ML workloads are running on top of cloud native architectures all being built on top of Kubernetes. So this is all the net news stuff, or the, I should say, that current stuff that's being built is being built on top of the, the technology stack today. I think we've kind of come full circle in some ways.

I feel like most of the new applications, microservices based, um, are generally heading nowhere to Kubernetes. Not maybe a hundred percent, but seems to be that way. But now a lot of organizations are building out these kind of platform engineering teams, and there's a conversation about how to take those monolithic virtual machine applications and deploy them on Kubernetes.

I think in the wake of the Broadcom VM word deal, more people are at least interested in having that conversation. What's your sense of what's going on with our monolithic applications as it relates to Kubernetes? Yeah, it's a great, great question.

I mean, you know, I don't know how much of the, you know, the noise in the, in the market right now in the industry right now around Broadcom and VMware is, is CAU causing the move? I think the cause of the move is, uh, we see that 54% of organizations are looking to use Kubernetes to reduce infrastructure costs. And so when I look at it, there's a maturity, right?

And applications live in any one of these stages. There's your whole, your siloed, uh, monolithic applications. Then they get encapsulated into a vm From there, from a, they get moved into a fat container, right?

And then from a fat container to moved into a microservices and then fully elastic. So you have these five stages of applications and organizations have, uh, you know, any reason to move across those different phases for any one of those applications. It could be to move off your existing infrastructure.

It could be moving away from existing, uh, heritage licensing model, so like, you know, maybe virtualization and move towards more of a breakout that, that application to microservices. So you'll reduce your downtime and you have more, um, basically make it more modular. So there's a number of reasons from a tech perspective, um, but there's also a lot of vendors kind of going and converging on the market for this.

Right. Well, that brings us to our next topic. 'cause Docker has a survey out, and it was looking at the application architectures that are in use and, uh, more people than ever are building microservices, but there's just as many people building monoliths, and there's people who are maybe more twice as many who are doing some sort of hybrid thing.

And in some ways, I feel like monoliths are turning into big ass microservices and we're just trying to live with all this stuff as we go along. And, you know, you enunciated five stages. Some of us might call that five stages of grief.

Yeah, it could be, it could be. I mean, I think when I, uh, you know, when I was briefed by Docker and, you know, talking to them about some of the research, we, we were talking about the context of three quarters or 76% of respondents in the survey are using containers in the SDLC, right? And, and that's compared to, uh, basically 65 or 61% that are using testing and, and production respectively.

So there's like basically a, a shift of using the new containerization across the SDLC, but where they're using it from the context of docker is 71% of respondents indicate to using Docker compose. We see 57% of of organizations using Docker engine, then 42% using Kubernetes, uh, a a as native. Uh, but then there's a blend of Kubernetes with Docker desktop being 35% of the respondents.

So what does all this means? It means that, you know, there's, it means that I'm an analyst. I talk a lot about data, that's what I talk, but no, what it really means about it, it basically says that, you know, Kubernetes and the, uh, modernization of applications is occurring using the tech stack that's appropriate for your environment matters.

And when you have these, you call it five stages of grief, I call it five stages of maturity, I think that there is a, a blend there, right? I think that, um, some applications will never move away from phase one or phase or stat stage one, right? Some applications are going to be born in the cloud and be fully elastic, right out to chic, but there's going to be a blend in between of applications and organizations, and they have to have the skillset to adopt the, the different tech stack.

So to that point, um, the, I, and I think we've talked about this before, but it also seems like even with the containerized applications, there's more of those running outside of Kubernetes than on it. And a lot of it may seem to be just the developers kind of voting with their feet and saying, you know, we love containers in encapsulation, but um, you know, I can live without orchestration. So, um, you know, is that a moment in time or do you think everybody's gonna need orchestration?

Well, I mean, I think if you're moving into containerization, the sprawl of containers is far faster than the sprawl of just native applications. So if you don't have some type of orchestration platform to manage the sprawl, you'll easily lose control of all of those, uh, containers that are being developed in your environment. So that's, that's one kind of perspective.

I think that if you're building containers in a test environment and trying to maybe migrate applications or try different test suites as such, that's fine. But when you go into any large scale production environment, orchestration is key to success. And looking over the horizon, we see these things called, uh, wasm runtime starting to float around.

What is the relationship between wasm and containers and Kubernetes gonna be as we kind of march down this path, because some folks are saying, I'll orchestrate was and runtimes alongside containers using Kubernetes. And other folks are like saying, Nope, we're going a whole hog in a completely different direction. Yeah.

So this is a great conversation. I, I literally, um, have had many, many discussions and I've done keynote around was and such as you may, as you may remember to note, um, you know, look, I think that Wasm is another way to develop a cloud native application, okay? Wasm is attractive.

Web assembly is attractive for a number of reasons. Um, up until 2022, it was really great for like applications like Python applications, rust and Go applications and business analytic applications. But in 2023, there was an a, a addition of multi-threaded, um, uh, uh, adoption within the web assembly platform, which opened up dotnet support.

net support and, and web assembly, it opens up a, a another avenue to develop applications or modernize your heritage applications into a new modernized approach. net application, say, and you want to do that in web assembly, you don't need necessarily need to use containers or microservices to do so, you can use web assembly. Another advantage is you don't have to recompile based on the, on the, on the underlying tech, uh, architecture.

So if you're deploying at the edge and you may be running on Intel arm a MZ, whatever may be out there, you don't need to recompile the application. Also, you only need to focus on the 10% of the business logic and not worry about that 90% of the commonality between those applications and web assembly. So it's attractive.

However, when you build an application in WebAssembly or wasm, you still built an application. So if you're sprawling applications, you need some type of orchestration to layer on top of it. This is where Kubernetes does come into play.

That thing that Kubernetes comes into play for the orchestration and management of all those containerized applications as well as web assembly applications. And Pat brings us to our next topic, right? So what most of what's running around on the enterprise, despite all these programming languages that out there, especially on the backend, is Java.

And Oracle is banging a drum for this growl VM is kind of the new foundation for running these applications in a cloud native environment. And there's other tools to make that happen. And it doesn't seem like enterprises are giving up on Java anytime soon, but how do we get Java into a cloud native environment?

Is there a set of best practices, a path that makes sense to you? Because, uh, you know, I can pick any vendor I want, red Hat, IBM, Oracle, they're all, tell me something slightly different. Yeah, I mean, you know, I, I was, uh, briefed on the, uh, the ment from Oracle around Grow and, and, and the introduction, you know, and how it's going to, uh, uh, you know, leverage the Java developer kit in the cloud native development.

And, you know, when, when you think about it, I mean this, this goes back to like when Oracle bought Sun back in, what, 2009. So it goes back quite a ways. Um, you know, there's, there was a, uh, a large percent of applications running in Java, right?

So, you know, when you look at that, um, I think Oracle is trying to leverage this J Java development kit to help accelerate that cloud native development. And what they're doing is they're using growl VM to, to basically build and run processes to create those Java Cloud needed services. So you, you are basically generating or optimizing the compiler to generate code quickly and use those fewer compute, uh, resources to do so, which enables the microservices to start instantly, right?

So there is an advantage, it's almost like using web assembly to some extent to do the development because you, you basically can spin up very quickly. It remains to be seen, this is still very new to the market. Um, the adoption is there.

Um, they do have some strategic partnerships with Intel and others out there, uh, around this. So, um, it remains, remains to be seen on, on, um, on how this will be able to be adopted by the, the developers. All right.

And that kind of brings us to our last post for the week, but we have a guest post talking about how cloud native needs to be driven from the top. And I kind of understand that and I scratch my head a little bit, but, um, who does wake up in the morning and say, we need to go cloud native and we need to do all this stuff. 'cause a lot of developers will tell you it's hard.

Um, they, you know, microservices is not for the faint or heart. There's a lot of dependencies keeping track of all these relationships. And on paper it seems easy 'cause everything is isolated, but over time you wind up with hundreds of these things and, um, people are start tearing their hair out.

So remind us again why we're doing all this. Yeah, yeah. So, uh, you know, I, I read the article from NTT data and, uh, and, and how the focus on how CIOs are aligning to the cloud expectations.

You know, I, I, I think, I think when you look at the broader organizational goals and you look at what organizations are trying to do, so, so CIOs and, and and organizations overall are looking for operational efficiencies, right? And when we, you know, a few years ago, it's like, oh, everything goes to the cloud, it's gonna be better, faster, cheaper. And it wasn't right.

It was, it was harder because it was more skill required, but it was so it wasn't, it wasn't cheaper for resources perspective. So I think there is, uh, uh, I, I, I, when I was reading this information and I was going through it, it reminded me of the data that I have in my survey. It was showing that 20% of organizations required or said it was very, it was very, uh, important.

It, I'm sorry, it was critical, not very important. It was critical that their, uh, applications were portable and 67% said it was very important. Now, why is that?

Well, because we also find that 94% of organizations are running on their production workloads on two and more clouds, 65% are running on four more clouds. So if they're moving their workloads across from core to edge to cloud, multiple clouds, distributed clouds and distributed environments, having a cloud native, uh, application that's that portable has the ability to be flexible across these different locales and those different locations. That makes sense to me.

And if you want to not have vendor lock in also makes sense to me from a CIO perspective. It gives, it gives you the ability as a, as an organization to negotiate the best terms with your cloud provider. So that's something to consider.

As for, from a cloud first approach, um, I do think that those organizations are going, look, we don't have resources, we don't skill gap issues, et cetera. They should look to service delivery partners to help accelerate their, their cloud native initiatives. So that's where I was thinking NCT data was going with this, uh, kind of top down approach from the, from the cloud perspective, it was really about efficiencies and optimization in the organization, but also having the flexibility to work with those cloud service providers.

I'm not sure about the portability argument. I get the argument about resiliency and microservices and you should be able to reroute calls and your application won't crash. It just may run slower forever because you can't figure out where that issue is.

And so it takes time for our DevOps team to sort it. But when I talk to people about portability, very few of them seem to have actually done it. Um, they get, they like the theory of it, but once you get into it, you discover that, you know, AWS or wherever it is, has all kinds of hooks into the application that make it difficult to port.

There are APIs involving the networking layer and the storage layer and the dollar, you know, just isn't quite a full bolt lift and shift. And so, you know, just how important is portability do you think? Well, I mean, again, if I, if I as an analyst, I look at data, right?

And what the, all I can speak to is the response that I get back from my research reports, from our data, the customers that are responding, when 20% of a survey of just shy of 400 respondents indicate that it's, it's critical for them for their environment, that's a pretty big number for me to, to open my eyes and think about. Um, I, I do think that there's different approaches to harmonize the multi-cloud, distributed cloud environments. You don't have to walk into, uh, an AWS or GCP or an Azure.

So specific solution, you can use something to harmonize it like an OpenShift or like a tan Zoo for example. And you can harmonize across each one of these, these platforms, uh, holistically. And there's also the, um, understanding of, today we were asking these organizations if they were refactoring their, their, um, heritage applications to cloud native, only 11% said that they would do it on-prem.

But then we asked that same question in the, in the context of the next two years, over 30% said that they were repatriate back from the cloud to on-prem to do their refactoring and building their cloud native applications. So having the ability to move across different cloud platforms seems to be an attractive, um, point to many of the, of the respondents in these surveys. Yeah, and these same people will also tell you that, you know, one of the benefits of Kubernetes is that it allows you to scale up and down, but as far as I can tell, everybody scales up and hardly anybody scales down.

'cause they just treat it like it was a, you know, some sort of new fangled virtual machine. So do we all need to take a good hard look at ourselves and just say what exactly is it we think we're doing? Because, uh, there's a disconnect between what I see in the survey results and what I'm encountering in the, in the real world.

Yeah, I mean, you know, I think it's, uh, always important to understand from a, a quantitative and qualitative perspective from the research and from the data. If you look at the general industry landscape and you have the, a large percentage of survey respondents, and then you have individual customers that are saying that they do X, Y, and z say that's an interesting perspective to understand where the customers are actually deploying what we're seeing across the market industry challenges. Um, with that said, I think that, you know, when we, when we, when we blend and overlay those two data sets, you can see how, so how those use cases will, will apply.

So I, I think that there's, um, you know, the use for your businesses will, will change based on your business results and your a and really based on your application results. So you could have individual applications that are doing different, running different, different things. So it, it just, it me, you know, you have to do what's right for your business and how your organization's gonna adapt.

I think there's a gap between our aspirations in reality. I think when I get outta bed in the morning, I would love things to be portable and I would like my IT organization to be as efficient as possible. And that's what I answer in the survey.

But then I get into the day-today, you know, things where I gotta roll up my sleeve and the brass tacks, it's a, it's a much different world. It's a lot more complex and um, you know, and people are kind of sitting here going, boy, maybe AI will solve all this 'cause it's getting beyond our human minds to manage. Yeah, maybe, I mean, complexity definitely was the number one, uh, response in the challenges when it comes to cloud native adoption.

So that it does come out to your point, you're absolutely right. Complexity is a challenge and organizations are looking to vendors to solve those challenges. All right, folks, while you heard it here, if you're experiencing this issue, there's some things to be said about one thing, other people are as well.

So you're not crazy. So I think we'll, we'll collectively all move forward because moving backwards is not really an option anyway. Hey Paul, thanks for being on the show as always.

Thanks, Mike. All right. Thank you all for listening to the latest cloud native podcast you can find and this and others on our website, we invite to check them all out as well as on our favorite distribution networks, including Spotify.

All right, folks, be safe out there and we'll see you next time.