Accelerating Cloud Native Transition Using Gen AI – Cloud Native Now Podcast EP23

Hello everybody, and welcome back to the latest edition of the Cloud Native Now podcast. I'm your host, Mike Bazar today where we're here with Paul nti once again, whose practice lead for application development for the Futura Group. Hey, Paul, how are you?

Good, Mike. Good to be here. We have a story up on cloud native now that I'd really like because it kind of pokes at some of the fundamentals of this whole migration to the cloud.

Um, it's about, you know, how we might use AI one day to accelerate application modernization and making that transition to cloud native. And this has always driven me somewhat crazy because people made these migrations to the cloud. They lifted and shifted these monolithic applications and they dropped them in on virtual machines.

And that's about as far as they got. And essentially, um, you know, they move their mess to somewhere else, and sometimes it costs more because the nature of the applications they were running, um, are long running, shall we say. And that why is it consuming more in the cloud than they might have in an on-premise environment.

But somebody told 'em that they needed to move to the cloud regardless. And so here we are, and then I feel like we all just got stuck. So, Paul, where are we on this modernization effort?

What does it take to turn these model edits into something that is more, uh, cloud native, microservices driven, and that theoretically will take advantage of things like Kubernetes to be less costly to run? Yeah. Wow.

Mike, there's a lot there to talk about. There's a, you know, when we look at, um, you know, the, the practice that I, that I run here at, at the future room group, I, I kind of frame up the applications as past, present, and future. And what you talk about is kind of the, the goal of many organizations is to modernize their heritage applications or, you know, their, their legacy environments to kind of move off, um, old infrastructure and move off legacy, uh, software that may have security holes or not optimized properly, et cetera, et cetera.

And there's a number of reasons why, uh, moving to the cloud, uh, requires, uh, some thought, right? And it's not just everything moves to the cloud and everything goes, it gets refactored and everything becomes cloud native, and you're using, you know, fully elasticity of the cloud to kind of get you where you need to go to. Um, it really does require understanding what those applications are doing, because when you look at modernization efforts and you're taking a heritage application, and the last thing an organization wants to do is refactor spend all this time and energy and money and, and, and, and effort to move to the cloud, and then all of a sudden realize that their application is running slower, it's not performing better.

It's, it's, uh, it's not, it doesn't have the same functionality as the, as the heritage application had. That's all really not a good place to be. So many organizations are looking at, um, deciding what the, what to do with their, uh, heritage applications, whether they encapsulate that and move it into a vm, make that a system of record, build new applications of engagement in the front end that access those, those systems of record.

There's a number of ways, and there's, and not every application requires, uh, you know, uh, to do all of this. So organizations have applications that live with and within, I call it five phases of the maturity model of these applications. And those five phases are basically the heritage or siloed applications.

Then it's phase two would be a, a, a VM or encapsulated vm, then maybe phase three, moving to a, a fac container, them to microservices and phase four, and then fully elastic and phase five. But keep in mind like that, organizations need to, uh, look at all of these applications and any of their applications could fit in any one of those phases. So it's not an all or nothing.

Right? The other thing that's interesting, um, you know, about this article that, uh, we, I'm cloud native now is the introduction of ai. I can't believe we, we started this conversation within three minutes.

We're back on ai shocker, right? We're gonna talk about ai, but AI really is going to provide, um, the ability to move quickly, move faster, right? Uh, what we see is the acceleration of migration of, of monetization is really a top of mind for a lot of organizations, but skill gaps are, are typically an issue.

Um, with that, the skill gaps not just, uh, be an issue, but also what applications need to be done. So if you put the proper workflows in place for ai, it can help evaluate, but I still believe at this moment there still needs to be a human in the loop as part of that activity. If we don't have a human in the loop as part of that activity, it could potentially introduce, uh, additional holes.

So all this to say, Mike, that modernization of applications is, uh, a necessity for many organizations. Not because, uh, it's the cool thing to do or why, you know, why, you know, Hey, I just wanna move to the cloud, but it's because those heritage applications either are not performing or not up to speed and not have a competitive advantage, but also more importantly, uh, introduce a security a whole, and those security holes could potentially be, uh, the downside of your business. So that's why a lot of these companies are saying, look, we need to move forward.

We have all these applications and we need the tool set to do so. And AI has helped accelerating that migration process. I'm all for people in that loop, but whose people is the one I'm always a little bit scratching my head about.

Because I think we've all heard the horror stories where people are like, oh, we're gonna modernize our application. And we hired this global system integrator to do that, and two weeks later, a bus showed up with all these college kids who moved in for a year and we wound up paying them a fortune. And a year and a half later, we still haven't finalized this thing because it's manual.

And, uh, nobody can understand the spaghetti code in the first place. And it just became, you know, too unwieldy to do. So.

I'm a little optimistic that, you know, I've at least heard of stories where people are moving apps and re-engineering them with the help ai, and it doesn't require a small army of people. Yeah. I mean, look, skill gaps industry, right?

We know that. And it's not even a skill gap on necessarily, it could be just resources or an issue. I mean, there's, you know, we're seeing in our research, um, that, uh, 50% of applications are being actually, there's a, a a number of applications, 50% of applications, um, are being developed now, more so now than just three years ago with the, with half or, uh, with at least half or not, uh, uh, the resources that are available was either the same or half what they had, uh, just a few years ago.

So to kind of clarify what I just said there, which I knew that was kind of confusing, but it's basically there's a, there's far more applications being created now, uh, with fewer or the same resources, and it's just going to accelerate. So I agree with you that utilizing AI to help accelerate that process is important. Utilizing the right tools for the right job is important.

Um, but it's also, you have to know what you're putting in place in order to make it work. And that's what those resources, you know, uh, you know, a number of people coming to your site and staying on site for a while, it has to be managed appropriately. And, um, that's, that's what I'm seeing with a lot of these organizations in our research.

Bornstein could mean that billing a new application to replace the old application is still faster than rewriting the old application, but we'll see how that turns out. We also have some articles related to AI run DevOps, but I wanted to call 'em out here because they speak to how AI will be applied to testing. And of course, that's always an issue with any kind, uh, microservices based application 'cause of all the dependencies that are involved.

It's highly complex. Um, this article talks about, uh, AI and Lambda test. It's one of several tools and platforms that are coming out there that apply gen AI and machine learning algorithms to testing.

What do you think is the maturity of all this stuff? Can we rely on this stuff or is it gonna be, you know, it's nice to have it, it kinda speeds things along a little bit, but is it gonna fundamentally change the equation? Yeah, Mike, you know, I've been doing, um, uh, trending data for, uh, distributed cloud or, or multi-cloud environments for the last four years or so.

And, uh, you know, what's interesting is, um, a couple years ago I did a study 2022, and I did a study that was focused around, uh, the testing, continuous integration testing within the CICD pipeline. And what we found was, uh, only 29% of respondents, uh, in a four, 400 plus person study indicated that they were doing continuous integrated testing, um, within their CICD pipeline. Fast forward to 2023, that number jumped to 66%.

And now in 2024, that number has jumped up again as well. Now, the reason it's jumped up is because a couple of reasons. One, um, when you look at testing, testing it, it was, uh, there's been a big push to, uh, move some of that testing from, uh, coverage shifting left of the for, for testing, right?

Moving it closer to the engineer. Closer to the developer. Um, prior to 23, what we were seeing was DevOps was, uh, responsible for getting code out the door fast, right?

Um, what we find in our research also is 24% of of organizations want to release code on an hourly basis, but yet only 8% are able to do so. And so with that said, the business KPI was push code out the door fast, uh, regardless of the, the qa, 'cause QA is raising area going, there's a problem here. We need to slow down the process, but to DevOps, like our KP is pushed the code out the door, right?

And they push the code out the door. And the problem, uh, the, the, the resolution that I'm hearing from a lot of companies is, well, we do sprint reviews every two weeks, uh, and if we find a problem, we just update that. But the problem is, is, you know, if you're releasing an application, uh, there's so much, so many applications in the competitive landscape that if you want to release an application and it doesn't perform properly, you're probably gonna lose that, that prospect or client, uh, because there's other applications behind it.

And that's where I think that the testing, um, fits into the model. And then now enter the age of AI testing and lambda tests as an example. Um, AI testing is only going to help accelerate the testing cycle for the CICD pipeline.

So taking those actionable insights and moving it quickly so it's no longer QA reason a is a problem here. It's the AI can address the problem before it gets published. So I, I really like where it's going.

I don't believe it's there just yet. Mm-Hmm. Yeah, I think, um, the part that I like where it's going is ideally it should enable more testing at the point where the developer is actually writing on the code.

I think too much of what goes on today is, um, somebody runs a test on the back end somewhere, and by the time they get around and share the results to the developer, the developer's two or three projects down the loop somewhere and is scrunching their head going, I can't remember what I was thinking at this moment or moment in time. And I think if we get that AI to kind of be almost like, you know, the second part of that two in a box kind of thing where the AI is right there all the time, and it will help the developers. 'cause nobody's deliberately going out their way to write bad code.

It's just that people have good days and bad days and, but they need an AI buddy. And I think that that's how this has gotta evolve. And the AI buddy, I think one of the primary jobs is gonna be testing, right?

Yeah, I, I agree. I I think if you, if you, uh, that goes back to my comment of shifting left and moving it closer to the developer. If you have the checks and balances earlier in the lifecycle of the code release process, then you can catch it earlier, obviously.

But, um, but again, you know, developers are sitting there, you know, they're not sitting there with a catcher sm waiting for the ball to be thrown to them. They, they have so much put on them right now that you just can't keep shifting everything left and expect a developer to get everything done. It's just, it's, it's far too much when you're pushing this code, this, this level of code off the door.

I do think the quote AI buddy is a good, um, idea to help drive that, but I also think that, that, that quote, AI needs to have the right workflows and methodologies in place in order for it to work. All right, moving on. We have another topic that's near and dear to my heart these days.

It's platform engineering and people are talking about, well, the first thing we ought to do is go build an internal developer portal and kind of like, okay, self-service for developers. I don't think that's necessarily a new idea, but I wonder if platform engineering teams might be a little too rigid in their thinking, because it seems to me that everybody's gonna want an IDP that's optimized for their project at the moment. So that lends itself according to this article, more towards virtual clusters that I can, uh, you know, spin up and take down on demand.

Well, that brings us kind of to our next topic, which is this whole notion of platform engineering and internal developer platforms that these folks are building that provide self-service capabilities to developers. Conceptually, I, I like the idea, but I think the devil's always gonna be in the details. And a lot of the projects that people work on are more fluid there, and they're, they're not these kind of like, I'm gonna build one IDP for everybody that there is out there.

Everybody's got this kind of different set of tools, different set of platforms and capabilities they need to invoke for each project. So this article on cloud native now was arguing that the IDP should be deployed on a virtual CL kubernetes cluster that can be, uh, spun up and taken down relatively easily. And that allowed us the infrastructure resources to be more efficiently used, shall we say.

Um, I guess Paul, you know, you've been kicking it outta this platform engineering topic. I mean, sometimes I think it smells a little bit of, you know, here comes centralized it again, and a lot of people are suspicious. So what does platform engineering need to do to be responsive in the age of cloud native development?

Yeah, Mike, this is really an important point. I mean, I think when we talk about, as we were, as we were kind of leading up to this, uh, there's a lot of desire for organizations to, and not desire, but the business KPIs, the businesses run on the frequency and the cadence of releasing code, the days of submitting a help desk to get waiting three days for something to change in the environment is long since gone, right? I mean, that's just not optimal.

It's not how businesses work, and it doesn't match to business KPIs or SLOs, right? What we see across the industry and in research in the industry shown that 80% of of organizations software, uh, development organizations, what basically establish platform engineering tools and, and, and basically establish them as the internal, uh, provider of those reusable services, right? So basically you'll have the ability to kind of shift and move, uh, resources that are appropriate, but it's no longer going to be the underlying infrastructure pieces that are being moved.

That's all going to be kind of, uh, seamless to the, the DevOps teams, the platform engineering teams. The, the idea around creating a a, a modern IDP, um, and and utilizing these virtual clusters is, is really made to be the, the, call it the golden path for the developer because it allows the developer to take a snapshot of an image, use that image, and then you reproduce it and after they, if they want to use it or remove it if they don't need it. But it basically allows it to be very rapid at creating those, uh, those buyouts that need to create customizable for the air environment, but also, uh, rapid deployment.

Historically, it took a long time to build up these, these IDP environments for developers, but now it's, it's, uh, it's basically the ability to do it on a, on a virtual cluster allows for that fast deployment. And then you and I were both at the VMware Explore Conference, and that kind of ties into our next story on what Broadcom is up to. And one of the things that they were stressing is that their Zu platform is aimed at folks who are embracing platform engineering.

They're kind of not interested in the do it yourself crowd, and they're betting that tho that crowd will get tired of supporting all that stuff. And so, are we kind of moving towards some sort of, uh, more integrated platform selection where all the piece parts are kinda come prefabricated, shall we say, or, you know, is the cloud native era is always gonna have a significant percentage of folks who are just like, I'm, I'm building my own. Thank you very much.

Yeah, I, you know, I think that, look, I mean, if you have A-A-A-D-I-Y kind of environment for your, for your, uh, infrastructure, it, it, you know, the, the challenge with it is, is if you do that, you own it, right? You own all of it, you own the support, you own the calls at two o'clock in the morning, you own everything that goes along with it, right? And if you don't have, uh, uh, the backing of a, an enterprise level will support agreement in place, then you have to figure this out.

This all out so requires a tremendous amount of bench strength. And also the devils are in the organizations like VMware with the, with Cloud Foundation and VCF and Tan Zu and, and what, what their acknowledgement of Tan Zu 10, um, for the platform, it really is aimed at taking that burden off the shoulders of the development team and organization so they don't have to know all the, the nuances to make sure things are working properly. Also, it gives you the support that you need that, that's needed.

If you get that call at two o'clock in the morning, you have something that go back to and, and help you walk through it. Well, we find in our research is, um, most organizations want to work with vendors that sponsor open source initiatives, but they want to also work with the vendors that have enterprise level support for those open source initiatives. So they want the level of doing it themselves, but they also want to make sure they have a belt and suspenders that they can go back and help.

And it's not just community support to help 'em through it. So I think that the, uh, you know, the, the approach here that Broadcom Zu is taking around platform engineering is to make it more frictionless and making the deal, making the, uh, uh, implementation far more, uh, streamlined and, and easier to, to deploy. The main theme that I kind of took out of explore this year was simplify, simplify, simplify, right?

It was all about with what VCF and Tan Zu is to simplify the deployment and not provide a bag of bits to provide, here's the platform, here's a product, you deploy it, it works, and you don't have to think about it when it's, when it's running. It's just, it's up and running and you don't have to kind of configure it yourself. So I think that, that, that's important.

Um, for the, for platform engineering teams, it also takes, again, takes that burden away from the organization versus putting it on the organization to support it. Mm-hmm, Done, right? It creates a, something of a social contract between the IT ops folks and the developers.

And one will give up, you know, not all their freedom, but a significant amount of their right to choose any tool or do anything they want in exchange for stability. It's kind of like how society works, right? All right, I wanna know next topic and is Red Hat and OpenStack, and we now have an instance of OpenStack that runs natively on Kubernetes, that all the components can be scaled up as you see fit and you can deploy which components you want.

Um, we've been talking about OpenStack versus Kubernetes forever today, but I have to wonder, have we reached a point where Kubernetes needs OpenStack now because, well, it's getting too complex to manage without it, uh, That small way to view it. I mean, I know, I think another way to view it is, uh, OpenStack, uh, it's, it's kind of the convergence of tech stack that's in your environment. I think, you know, red Hat having the ability to, to, to, you know, run OpenStack on top of Kubernetes and, and, and running it, um, on top of OpenShift as well is, is basically giving the ability to, to bring your tech stack together, reduce that, gotta use the god that the, the theme and it is reduce the complexity, right?

Reduce the, the overhead of running all these different things within your environment, understand your tech stack and understanding what tech, what technology you want to use. If you are using, you know, uh, vert in order to kind of migrate from VMs, uh, from, you know, that that helps with a lot of, uh, that the migration towards the more of a modernized stack modernized by. So I think that this is more about that.

I'm gonna go right to the beginning of this episode, automating that ai, automating that modernization effort of taking those heritage applications and moving them towards a modernized platform. All right, folks, well, you heard it. Here we have come full circle.

So thank you for spending some time with us once again. And, um, ultimately I think I'm more excited about this whole cloud native space today, um, than I was when I first started covering this thing five or six years ago. It's been a, a long road, but I feel like, and maybe I'm just crazy, Paul, but, um, have we reached a point now where, you know, cloud native is kind of the default way of doing things?

Oh, absolutely. I mean, it's, uh, it, it seems to be, whether it's on-prem and you're, and you're at your edge location or in a cloud, both public and private cloud native deployment for, for net new applications and anything new that's being built is the preferred way of de of deploying. Uh, it, it is mainly due to the security.

It's mainly due to, uh, the flexibility, uh, and, and, and the ability to scale that need. So I definitely think that anybody building net new applications is building it in a cloud native, uh, perspective. It's really understanding the heritage environment to move towards this cloud native environment, see where it's going.

All right, folks. Hey, the water's fine. Come on in.

Hey Paul, always good talking to you. Thanks Mike. Thank you all for watching slash listening to the latest edition of the Cloud Native Now podcast.

You can find this episode and others on all your favorite outlets, including Spotify and of course on the Cloud Native Now website. We invite you to check out all the other episodes that are, are there as well. Till then, we'll see you next Time.