Cloud Native Needs DevOps – Cloud Native Now Podcast EP20

Hello, and welcome to the latest edition of the Cloud Native Now podcast. I'm your host, Mike Viser. And once again, we're with Paul NTI from the Futurum Group, and we're talking about all things cloud native.

And as it turns out, there was a lot going on. Hey, Paul, how you doing? Good, Mike.

How you doing? All right. So Red Hat had its big conference, and, um, I don't know, I attempted to follow everything they were doing, but it all seemed to come back to OpenShift.

OpenShift went extended with this, a little bit of that. And you know about when I added it up, I think there was like 10 new capabilities rolled up into various announcements that they had. But, uh, you were there at the show.

What was your impression? Yeah, super exciting event. I mean, red Hat Summit and Ansible Fest is, it's always a great event.

I mean, what I liked about it and what I saw from the event was, uh, you know, the continuity from last year to this year was really exciting, right? We, there was a, uh, you know, a, a lot, I guess we'll start with the topics, right? There was a lot ai, everything, AI was everywhere.

Of course, that's, that's not surprising. But really the developer centric message and the developer focus was really key. Um, there is ex enhancements, tore l there was enhancements to OpenShift, there was enhancements to, uh, you know, the, the Ansible platform and automation.

Lots of things that were happening. Uh, what I, but when I look at the continuity and the messaging last year, there was an introduction of, of lights, uh, Lightspeed, right? And, and bringing Lightspeed into, uh, Ansible.

Cool, great, right? That was awesome. But now Lightspeed is being brought into r and Lightspeed is being brought into OpenShift, right?

So you have RL ai, OpenShift ai Lightspeed being brought in for workload automation, uh, really, really kind of cool, uh, optimizing that kind of, those tedious tasks that needs to happen. Another thing that was really interesting on the R front was image mode. Image mode came out, really allow you to do these containerized kind of approaches and having these, I'll call 'em golden images, right?

That you basically create these containers and have them rapidly deployed. So, really exciting stuff there. Poman came out, right?

Poman came out, allow you to do some, uh, development efforts, you know, and then growing into the, into the environment. But yeah, it's, um, lot's happening. Lot's happening.

I mean, I could, I could talk for, for a long time on this topic, so I'll, I'll give you the mic back and, and let you, uh, let you kinda have some dialogue there. Well, let's unpack Lightspeed a little bit. I almost feel in some ways Red Hat's a little mad 'cause they're not getting enough credit for the Gen AI stuff that they did much earlier than a lot of folks with Lightspeed and IBM the same way.

But maybe they just applied it too narrowly. Yeah, I, I mean, I think it was good. I think they're stepping to and get it introduced into the market was good because I mean, even with, uh, even within the last year, uh, light, the Lightspeed adoption was probably relatively low, right?

Even though, um, there was an adoption with Watson X, there was an adoption across the, the workflow automation. The question is, is when you look at Ansible and you look at that maturity curve of automation, um, how many people are on the far right of, of full maturity for automation? Probably not a lot, right?

So when you start looking at that, uh, light speed and, and optimizing the workflow and doing natural language to create these workflows, um, are these organizations even ready for that? Right? But you do, I think from a Red Hat perspective, you need to have the ability to say, we're future looking.

We're, we're helping you get to where you need to go, and we're meeting you where you are in your journey. And that's key to the success of, of any automation or any practice in general. But like, when it comes to automation, dipping your toe and getting started, getting ready, transferring those manual scripts into auto automated scripts is really important.

And then start using workflow automation like Lightspeed. That's really, really powerful. Um, bringing that to r and bringing that to OpenShift is another, another plus, I believe You mentioned AI workloads, and I'd love to get your impression on this.

'cause when we were at Q Con Europe, clearly AI was a big part of the discussion, and it was all about, well, of course, AI workloads are the deployed on Kubernetes. And I couldn't come to the conclusion whether or not that was because they wanted to or because they were, there wasn't really another option. But then the one that they were faced with was kind of hard to manage and complex, and there wasn't many data scientists in love with Kubernetes any more than developers.

And so that became a conversation was how do we make Kubernetes more accessible to data science teams? Was that a part of the conversation at Red Hat and what as well? I mean, is that what we're working towards?

Yeah, I mean, I, I guess a good way to kind of segue that conversation, AI workloads in, in Kubernetes, uh, where Red Hat was extending their alliances, so to speak, was really to, uh, work with the adding the support of large LA large language models, uh, to conveyor conveyor, right? It's an open source toolkit about how for helps for migrating source code, you know, to Kubernetes environments. So I think that's a good step in that direction to kind of say, Hey, we're we're working Red Hat's showing that they're working on this.

They're committing, they, you know, committing their support to it, and they're bringing those workloads into the environment. Also, the strategic relationship with Nvidia, uh, was, was, uh, was was out there as well. So there's a lot of utilizing the GPUs, utilizing the tech stack that supports it, and the LMS that kind of bring it all together.

And then building that all on top of a Kubernetes environment really does kind of, uh, really was a general message here, right? And then the one thing that kind of struck me as odd was, um, they're talking about the containerization of route. They're gonna put the entire operating system in a container, and part of their conversation there is, well, that'll make it easier to integrate it within a DevOps workflow.

I think it's a little ways off yet. It was more of a preview in, in terms of a capability. But what is your sense of, are we gonna containerize operating systems and why?

Yeah. So that was where I was kind of talking about with image mode, right? Uh, RL image mode, uh, really does allow for that containerization of RL, right?

And allowing for the workloads and the, and the, and the, and the, to, to, to be, I mean, I'm sorry, allowing for the operating system to, to be deployed. And if you do patches, it kind of gets rolled into it. But it was funny, I was having this conversation with, uh, Chris Wells and the, and the, and the Rel team and such, and, and I was saying like, you know, it's really surprising that what's old is new, right?

You know, so when we think about it, like what we did, you know, years ago we would take a, a golden image of a vm and that would be your image, and then, then you just deploy that VM across different areas. Well, we're doing the same thing here with image mode, uh, with RL similar, um, using containers, right? And so now we're taking containers and we're doing that golden image, and we're rolling it out to make sure that, uh, it's allow, integrates quickly into the DevOps ZICD pipeline.

So if you're looking at the whole flow, if you need to do deployments, if you need to push things out quickly, um, now you have a way to do that. And you can control what, what happens with those deployments. So I think it's important, especially when it comes to, uh, the branching out of the data center from core to edge to cloud, having the, uh, the, the, the team centralized management of those deployments.

It, it really helps with that, that, uh, that deployment model. Yeah. Yeah.

I wanna shift the gear to a topic that's related to this closely, and I know it's one that's, uh, near and dear to your heart, but application modernization, it's been around, we talk about it all the time. There's the five Rs and only one of those s directly results in applications being, uh, written rewritten as cloud native. What is your sense of what's going on here?

I mean, sometimes I talk to folks and they're like, wow, we'll break up a monolith into some subset pieces, but, you know, we're keeping the core monolith 'cause it's just really a big ass microservice. And, um, other folks are kinda like, you know, going whole hog here and everything's gonna be microservices from here on out, but then they discover there's thousands of these things and they end out how to manage 'em. So, uh, where's the Goldilocks moment here?

Yeah, that's a great, great, great point. Uh, three, you know, three to five years ago, everybody was, oh, everything's gonna move to cloud native, everything's moving to cloud native. We only have gonna have cloud native applications.

And that's simply not true, right? Um, what we have is organizations are looking at their heritage applications. There is a desire to modernize.

Of course, we're always looking at modernizing your heritage environments to a more, uh, robust kind of, uh, efficient way of doing business. Um, however, refactoring doesn't necessarily apply to every application. You may wanna just encapsulate the existing heritage application into a cloud ready state, move it to the cloud, maybe move it off your heritage infrastructure, and then move forward.

I mean, what we're seeing, Mike, in our research is that for cloud native refactoring, we're seeing only 11% of respondents in our recent survey are refactoring on-prem. But yet what we we see in the next two years is 30% of those, um, refactoring efforts on-prem are coming back on-prem. So there's re repatriation back from the cloud onto on-prem.

So what does that tell me? It tells me that there's a separation between the application logic and the infrastructure itself, and there's a modernization push for the infrastructure. And maybe what happens is you take that heritage siloed, uh, big monolithic micro or mega service, whatever you want to call it, right?

And put it into a container or put it into a VM and make it cloud ready, that becomes your system of record. You may never have to touch that again, right? But if you wanna move it back on-prem for performance reasons, regulations, compliance, cost factors, whatever it may be, you still may wanna build new applications, systems of engagement that access that existing system of record.

So I think that there is a, a Goldilocks movement of taking the, those heritage applications and applying them to the best use case and how you're going to optimize. Because keep in mind that modernization requires people to do it. And if the skills are being applied to applications that don't necessarily benefit from cloud native deployments, why do it?

Yeah. I look at it in a, maybe in more simplistic fashion, my first notion is, hey, a lot of these apps wound up in the cloud because, well, in the Covid era, there was nowhere else to go. And then they all looked at all that, and then now, and they're saying, you know what?

That stuff's expensive to run there. Let's move this back on premise. And then the second part of that equation is, um, a lot of those apps are accessing data that resides on premise, and people are starting to look at latency and they're going, holy cow, Batman, this thing is slow.

So I think, you know, sometimes it's just a practical issue. I'm not sure it's a philosophical issue as much as it's just kind like data gravity at work. Yeah, I, I mean, I agree.

I mean, I think that, you know, there's the, there's definitely the cost factor that comes into play, and tech debt is definitely an area that, you know, people wanna look at existing tech debt versus new tech debt that comes in. Um, there's definitely that, there's, there's also the ability to say like, if you're going to build a net new application, are you going to build it in a heritage way of building it, or are you gonna build it in today's current standards? And the answer for most organizations is today's current standards.

So, you know, those systems of heritage systems that are out there, they're probably going to stay intact and lead them intact until they age out. Um, look at, look at, you know, mainframe, right? Mainframe is still running, right?

And if you've ever traveled or banked or anything, you're still using a mainframe. People are, oh, mainframe's dead. It's, it's not dead.

There are still applications running it just modernized mainframe. And it's the same thing here. You, you're going to see that data centers are modernizing, but they're using the infrastructure that's available to them to fit the best need for their business outcomes.

Alright, I wanna shift a little bit of a gear, but you mentioned legacy technologies and there was, uh, uh, some updates made to this thing called the, uh, Apache Pinot database. It's a real time database built by the folks at LinkedIn who built it because the underlying databases that they were relying on for observability just didn't cut the mustard because, well, things are highly distributed and more complex, and then they open source this thing, and now there's an outfit called Star Tree that's providing services and software on top of this database. Have we reached some sort of point here where we really do need to get a whole different database architecture going and drive observability?

Uh, well, it's a, it's a great question. Um, you know, I will say that, uh, Sam Holshoe and I wrote an article on, on this, and it's on the future, uh, group's website that talks about star tree's, third eye service that kind of allows for that adding supportive metrics and logging and tracing, uh, uh, you know, across the Apache, uh, database here. But, you know, I, I guess I'll take a step back and I'll look at it from the context of, is there a need for this?

Well, when we look at observability, observability practices in most organizations is pretty much in its infancy, right? It's, and a lot, a lot of organizations, I, I kind of half joke when I talk about observability saying the largest consumer of observability practices is a storage admin because they just continuously grab data and grab logs and grab all these things and don't know what to do with it. So they kind of have a lot of storage, but don't know really what to do with it.

What I like about star tree's approach here and what I like about, uh, you know, the, the database approach that allows for the, uh, you know, scaling out and scaling down into it, is to really, um, understand what it is that you're looking at through those metrics and logs and traces, but also have the ability to take those actionable insights. So it allows for organizations to take their observability practice from, uh, call it a, uh, kind of a, I don't wanna insult, but an immature state, and bring it to more mature actions, right? To say, okay, well, we're gonna just not just collect a bunch of things, we're actually gonna take actions when we see these alerts and these things happen.

So I, I'm, I'm a big fan of it. I love to see where it's going. Um, it's definitely, uh, you know, star Tree and, and this kind of approach, it's definitely an alternative to other observability practices in the market and vendors in the market.

I love that there's a, a freedom of choice here. Um, and I also do love that, that it's, uh, heavily, uh, engaged in the open source community. Well, you mentioned this, so I'm just gonna broach it, but so how much do I trust versus verify?

'cause theoretically, if all this stuff is happening in real time, it's faster than my brain can comprehend. So do I just kind of hit the automatic push button, or do I like, stop this thing in real time? They have a half a second look at it and go, do I really wanna do that?

Yeah, it's a, it's good, it's a good question. You know, I mean, having a human in the loop is still always, uh, you know, preferred in many, uh, discussions. I meant the, the, the, the sense of automation is to take it to that point of if there wasn't a human in the loop, can you, uh, do you feel confident moving forward?

And when I look at like what star, TRE Cloud is doing, um, and you know, and, and with Apache here is, is really taking that database to optimization for real-time analytics, right? And, but I think by entering in those checkpoints and having that human in the loop to verify that will as, as, as long as those verification processes are working, um, and there people will build more confidence in it and letting the, uh, the automation take, not take over, but like really just kind of grow with the actions it's going to have to move to that direction, especially with the volume of, of, of actions that are coming with, you know, with, uh, with, with all the new apps that are being created across the DevOps teams. So, uh, you know, I, I think that automation is here, it's going to continue to grow, it's going to continue to be, well more adopted, but right now, a human in the loop is definitely, uh, where most organizations are looking at, at, at their, uh, their deployments.

Yeah. One area where there's a lot of humans in the loop today is spinoffs. And, um, this is an ongoing conversation between you and I, but um, I'm returning to it because I'm just trying to figure out, you know, how sloppy are we in cloud spending these days?

What's your sense? I mean, how much waste is there really versus, you know, be honest, you know, DevOps engineers are not, you know, knuckleheads. They're looking at these things and, you know, trying to optimize costs.

So, you know, are they doing a good job? Because on the one hand, some people will say, we do an awesome job, and other folks will point to the net income of the cloud service providers and go, clearly there's something amis here. 'cause these guys are making a fortune.

Yeah. You know, I, I think you're right. Um, you know, here, here's the thing.

I mean, when you decouple, um, the challenges that the DevOps teams have today from the cost associated for achieving those goals, a lot of organizations are like, okay, we just need to get this done, right? And they don't fully have a, the lens and the visibility into what's going on in the space, right? Like, so it's like, you know, DevOps, you know, not to their fault, but they're gonna over-provision for, you know, for the actions that they need to do.

And so in order to make it easier, in order to make it understandable, is really to have a clear understanding of what you're doing for budgeting purposes, for use purposes, et cetera. And it's not a, I hate to say it like this, but it's really not a manual process. It's too co too complex, too cumbersome, too many variables.

It's, it, it's really difficult to, on top of their day jobs, right? So to add that in, it's really, really difficult. But, you know, one thing that was encouraging here, Mike, is I was talking to, uh, Lauren.

Gil, he's, uh, uh, the, the, uh, uh, he worked, he's the, the founder at CAST ai, and I was really impressed with the way cast AI does their delivery of, of cost optimization. They understand the cost models, um, that are working with, uh, these, these cloud providers. And they're presenting the data saying, here's what you're using, here's your workloads and here's how to optimize.

So they give you all the tools by looking at it for, through this lens that is far more efficient than trying to manually go in and pull levers and try to figure out exactly what you need. So I'm a, I'm a huge fan of solutions like cast ai because I think that those are the, those are the ways to be more efficient when it comes to those finops solutions. All I think engineers are doing a better job than we give them credit for here, because most of them that I know, they're offended by waste and anything that's inefficient, they get annoyed so they go do something about it.

So, Right. But you have to identify the waste in order to know it's there. This is true, this is true.

As always, my friend enjoyed the chat. Thank you. It's been great.

I really appreciate the time. It's, uh, it's uh, been an exciting week and a lot of announcements this week. So yeah, definitely enjoy the chat today.

Thanks a lot. All Right. And thank you all for listening from the latest episode, the Cloud Native Now podcast.

We hope you enjoyed it. com for any thoughts or ideas you'd like us to discuss because well, Paul's giving out free advice here. Come on.

All right, everybody, stay safe and talk to you soon, Paul. Thanks again. Thank You.

Have a good day. Bye-Bye.