Red Hat Summit 2024 | James Falkner | Red Hat

Clips
News
More from Red Hat Summit 2024

James Falkner

Director of Product Marketing for Runtimes

Red Hat

Konveyor AI: Changing app modernization with open-source innovation

Modernizing applications is an intimidating task for enterprises, yet increasingly essential. Enter Konveyor AI, an open-source marvel leveraging retrieval-augmented generation to seamlessly integrate large language models. This innovative tool is poised to transform the landscape of app modernization, according to James Falkner (pictured), director of product marketing for Runtimes at Red Hat Inc.“The challenge that we face is the economics of really essentially changing an app, burning it down, rewriting it,” Falkner said. “We have championed an open-source upstream project called Konveyor, designed to facilitate onboarding applications to Kubernetes

play_circle_outline Konveyor: Onboarding Applications to Kubernetes and OpenShift with AI-Driven Suggestions for App Modernization

play_circle_outline Konveyor AI can use Watson Code Assistant and corporate data to improve results

play_circle_outline Organizations can contribute rules to Konveyor to support transformations across different technologies

Info

James Falkner | Red Hat

James Falkner

Director of Product Marketing for Runtimes Red Hat

search

>> Hello and welcome back to Red Hat Summit AnsibleFest here in lovely Denver where theCUBE is broadcasting wall to wall and breaking down all of the announcements and digging in to this thing that we call AI, open source, and how you actually bring cloud native together, which actually brings us to a really good place. I'm Rob Streche, this is Paul Gillin, we've got Rebecca Knight floating around as well, she'll be back on in a little bit, but we're really happy to have James Faulkner, who's the director of product marketing for Runtimes at Red Hat joining us because really it's about how you get up and get these cloud native apps going. And I think you're going to have a very interesting perspective of some of the stuff that you're dealing with in general that's production and some of the things that are coming in the near future.

James Falkner

>> Absolutely. So I'll start with a little bit of a couple of numbers and some context. So we've done research recently that shows 80% of those we surveyed are going to modernize over half of their apps in the next two years. So this is a very timely, a very compelling event for not only Red Hat's customer base, but just the larger apps in general. And the other interesting piece that came out of this survey is that over 75% of them intend to use AI to do one or more aspects of that modernization. The challenge that we face is the economics of really essentially changing an app, burning it down, rewriting it, have not been very favorable. So a lot of companies when they modernize, they're looking to move applications but not necessarily rewrite them and take advantage of some of the more cloud native capabilities that they could be because of the cost-prohibitive factor of that.

>> No, I think that that's exactly what we've been seeing. And we talked about a lot of things in the lead up to this interview, and I think part of it was, I was in a financial services company. We had a application that was written by an intern that ended up becoming production. And it was on NT 4, and this is after NT 4 was gone, and we spent a phenomenal amount of money supporting it, but we were too scared to then go and modernize that. How are you seeing, and what tools are you bringing to bear to help organizations that are in that same paralysis analysis phase about modernizing? Because it seems like AI would be typical, and people have talked about using AI to do this for a while now, over a year, but what are you seeing?

James Falkner

>> So there are tools that can help in this regard. This is Red Hat, so naturally we're open source. We have championed an open source upstream project called Konveyor, that's with a K for Kubernetes, really designed to facilitate onboarding applications to Kubernetes, and of course, from Red Hat perspective with OpenShift, but it also is a place for incubating tools to help with this. One of those tools, an early on tool was called Windup. Many of you at Red Hat were probably familiar with that. This was a tool that did what we call static code analysis, and they would essentially just look at your code, find lines of problematic code depending on what you're trying to do, whether you're upgrading to a newer version of JBoss or whether you want to move to a new version of Java or something else and tell you what needs to change. And then it's up to you to make that change. It's up to you to test that change. It's up to you to get that change into production. So what we're doing here with Konveyor is introducing a new tool called Konveyor AI, and this really takes advantage of the groundswell underneath AI and brings a different and novel way of doing this modernization. But you can take an application and just ask an LLM, "What's the next best thing I should do," and it might give you a few suggestions here. It does not know any of the patterns that you've seen in the past doing modernization at a particular company. So with Konveyor AI, we're able to take advantage of a lot of the history of an application modernization and not just ask it for the next best action.

Paul Gillin

>> Now, IBM has Watson Code Assistant. Is Konveyor associated with that?

James Falkner

>> So IBM Research is actually one of the partners in the Konveyor community. And so Konveyor AI can use as Watson Code Assistant underneath as that foundational model. And again, what we also are doing, which is very new, is taking corporation data. So historical data about other fixes that have happened through things like GitHub pull requests, JIRA issues, the static code analysis that I mentioned earlier, and we're taking all of that and using the RAG pattern, the Retrieval Augmented Generation, to improve the prompt that we send to Watson Code Assistant so that what we get back is not just awesome Java code or awesome C code or awesome whatever code or whatever language we're using, but it also takes into account all of the past history and all of that data that's extremely valuable to companies and uses that to improve the results so that a developer who's working in their IDE will see the result and see, "Oh, I need to make this change because our corporate policy requires this particular change that a base foundational model would not know."

>> Yeah, I think that, to me, is what's really interesting about this, and again, being part of that open source community, and we were just at KubeCon, feels like last week, but it was actually a couple months ago now.

James Falkner

>> Yeah.

>> When you start to look at it, all of the things that are moving around, and this is the CNCF project?

James Falkner

>> Yes, the same CNCF Sandbox project,

>> And it used to be called Tackle and it's in Sandbox now, how did we get here with Konveyor.

James Falkner

>> So I think, with Konveyor, so we've done a lot of research in the Konveyor project. We've worked with a lot of customers, not just Red Hat customers, but also other customers interested in Konveyor, interested in contributing tools to that. And we've learned from the challenges they face. One of the challenges, for example, was not the static code analysis that we'd had already completed with the Windup project, but it was doing large-scale modernization efforts at companies and getting more metadata about the applications. Are the developers still around? Do you have a mature CI pipeline that you're delivering or CI/CD pipeline you're delivering to production? We can ask these all in a questionnaire, and then rank the applications in terms of the risk to the company of modernization or not modernization and a number of other facets. And so it really brings a more systemic mechanism when you add in these tools that we've learned from the Konveyor community. And that's really, I think, the power of Konveyor. And now with AI, we're just really turbo-charging that effort.

Paul Gillin

>> What kinds of applications are you finding are the best candidates for modernization this way?

James Falkner

>> I would say any application. That's a loaded term. What we say is app modernization is not a one and done, right? It's a continuous effort. And so the applications that I would say are mission-critical, the ones that have a huge performance impact or a performance problem, those are the ones that you really want to look out for app modernization, the ones where you're going to get the biggest return on your investment. Now, of course, the answer is always, it depends. So if the developers aren't there, then you might make a different decision. But by and large, it's those applications that bring real business value today, but have the potential to bring much more if you do things like move to modern cloud-native frameworks, move to platforms like Kubernetes and OpenShift, and then you can change how you deliver that software to production and get business value in that way as well.

>> Because again, in your title, Runtimes, help people understand that might not be as familiar. What does that mean at Red Hat?

James Falkner

>> Yeah, so Runtimes, it's essentially what runs your applications at the application level. So you have your infrastructure, you have your operating system, you have your silicon, or you have your cloud instances, then you have your orchestration layer, things like OpenShift and Kubernetes. Then you have application frameworks and languages, and then the business logic sits on top of that. So our runtimes are that layer between the applications and the underlying orchestration system that provides things like clustering, fault tolerance, single sign-on, provides transaction integrity, things like that. And so, traditionally we thought of this as middleware. So Runtimes spans both traditional app server-based middleware, as well as our cloud-native frameworks, things like Quarkus and Spring Boot and Node.js.

>> And there has to be... Like you said, I think that we went through a lot of people trying to modernize, and there's been this renewed push because of AI and the hype around it. And I'll say the hype, because the reality of people actually going through and using AI to do that, they're a little scared because they're trying to figure out where was it trained and things. It would seem that some of the things that were announced today would fit really well into joining in with Konveyor AI maybe in the future, and you could see this, because Konveyor AI is not a Red Hat product, it's open source.

James Falkner

>> Correct.

>> And it's not even a commercial product at this point.

James Falkner

>> That's correct.

>> So how do you see the things playing together, I guess you could say?

James Falkner

>> Yes, it's a great question. So the historical things, like you mentioned, Tackle, and we also had Windup, which is a static code analysis, those were surfaced to Red Hat customers through the migration toolkit for applications. It's one of a suite of migration toolings that we have. We also have migration toolkits for containers and also for migration for virtualization. So these are tools that are designed to bring applications onto our platform. So with Konveyor being the upstream to the migration toolkit, that's our path to essentially our go-to-market. This is a tool that developers and data scientists and people planning large-scale migrations will use. That's where it land will be in the migration toolkit. We're planning on bringing a packaged sort of dev preview version in the Konveyor community later this summer, and then we're going to look at moving that into the migration toolkit and combining it with things like the Granite models that IBM and Red Hat announced earlier today. The other aspect of one of the announcements later was that as you use this novel way of doing a modernization by bringing in through RAG, bringing in corporate data, as that corporate data grows and grows, that's the thing that's going to get bigger and bigger. So at some point you might want to sediment that into the foundational model and fine-tune the model. This is where InstructLab comes into play, because Instruct lab, it provides a taxonomy and all the synthetic data generation. This fits really, really well with a large-scale modernization effort because that's really what you're doing is you want to take the knowledge and skills that you've learned in the past to apply it to the next modernization application that you do. And it really turbocharges and accelerates that large-scale migration.

Paul Gillin

>> Do you see large language models being developed that are specifically for migration?

James Falkner

>> That's an excellent question as well. Yes and no. So one of the things that companies often look at is, "I don't want to give away my data. I want to keep it all in-house. I'll use your foundational model. I might fine-tune it. I might use RAG and hook it up to our internal GitLab instance and bring that data in and improve the prompting, but I'm never going to give that data away." Some will actually want to do that, but the challenge there is that the patterns you see in company A are oftentimes very different than the patterns you see in company B. So it may or may not actually be worthwhile to create sort of a community-based migration tool because a lot of the value proposition is in that corporate data in the patterns that you see inside one company where they have a set of developers that made the same kind of architectures, which would apply to their applications, but not necessarily to your applications. So there could be a middle ground there that a community can develop.

Paul Gillin

>> Yeah, I-

>> Oh, sorry. Go ahead.

Paul Gillin

>> I remember one CIO at a big financial services firm once told me that he has applications in his shop. He doesn't know what they do, but he's afraid to turn them off. What do you encounter? When you're going to do modernization efforts, what are some of the crazier scenarios you encounter?

James Falkner

>> That's par for the course, right? It's like companies who, the developers are gone or they outsourced the development and now they don't know what to do, or they're running an ISV application that they don't even have control over, and they can't turn it off or they can't make changes, and there's a path for that where you can go back to an ISV and kind of put pressure on them to like, "Hey, man, you need to modernize this thing." So we see a wide range of reasons why modernization is challenging. That's one of them. Also, they look at the modernization and say, "Well, I'm not changing the application, so there's no new business logic. What's the value to me?" And in a lot of cases, the value proposition for a modernization is in how that software is delivered, not necessarily what's in the application itself. So there's a wide range of reasons. And in the research I mentioned, which is on Konveyor.io, it goes through a number of the different reasons why modernization can be challenging. Costs, just don't know, don't have the skills, don't know where to start, it spans a whole wide gamut.

>> So in the little time we have left here, put in a plug for Konveyor, and for people getting involved, and organizations, you've got a lot of your customers here, and a lot of these customers are obviously into open source, and a lot of them would not like to contribute back to it. How should they get involved? Where do you see Konveyor going over the next year?

James Falkner

>> Yeah, it's a really good question. So to get involved, go to Konveyor.io, that's our website. There's lots of blogs information about it. You can contribute rules, so when I mentioned earlier the RAG pattern that Konveyor AI uses, one of the inputs to a prompt is a rule that was discovered in your application. And so if you contribute rules to say, "If this application uses this API, here's how you should probably fix it," and the reasons why, that is very valuable to the wider community. That's where we really want to see contribution is in rule sets for not just Java, not just .NET, but a wide range of application languages, because we want to be able to support transformations and modernizations across different technologies. So I would say go to Konveyor.io and get it all. We have Slack channels, we have user groups, lots of places.

>> And where do you see it going in the next year?

James Falkner

>> So I think that a lot of the work is going to be in integrating tighter with LLMs, integrating with InstructLab as well, and just improving the overall workflow. It's pretty early days. We have the IDE integration, but we really want to kind of bring it to that next level, and not just show you how to modernize that application, but also bring it onto the platform and show you how to get that app into production safely and consistently.

>> I think that's a great place to leave it, and I really want to thank you because, again, this is actually one of the things I've been saying is that KubeCon is really Cloud-native con, and they should swap the names around because Kubernetes is there. We know it's 10 years old now. Yay, Kubernetes! And we're all big supporters, but it's really the layer above it as you start to build these cloud-native apps. And this is right in that-

James Falkner

>> Yeah, it's a brand new way to do a modernization using existing communities, but powering using LLMs and AI. It's fantastic.

>> Well, thanks, James, for coming on board.

James Falkner

>> Thank you for having me.

>> Yeah. And thank you for watching theCUBE here live from Red Hat Summit and AnsibleFest wall-to-wall coverage. We'll be back with you in a few short minutes.

James Falkner | Red Hat

search

>> Hello and welcome back to Red Hat Summit AnsibleFest here in lovely Denver where theCUBE is broadcasting wall to wall and breaking down all of the announcements and digging in to this thing that we call AI, open source, and how you actually bring cloud native together, which actually brings us to a really good place. I'm Rob Streche, this is Paul Gillin, we've got Rebecca Knight floating around as well, she'll be back on in a little bit, but we're really happy to have James Faulkner, who's the director of product marketing for Runtimes at Red Hat joining us because really it's about how you get up and get these cloud native apps going. And I think you're going to have a very interesting perspective of some of the stuff that you're dealing with in general that's production and some of the things that are coming in the near future.

James Falkner

>> Absolutely. So I'll start with a little bit of a couple of numbers and some context. So we've done research recently that shows 80% of those we surveyed are going to modernize over half of their apps in the next two years. So this is a very timely, a very compelling event for not only Red Hat's customer base, but just the larger apps in general. And the other interesting piece that came out of this survey is that over 75% of them intend to use AI to do one or more aspects of that modernization. The challenge that we face is the economics of really essentially changing an app, burning it down, rewriting it, have not been very favorable. So a lot of companies when they modernize, they're looking to move applications but not necessarily rewrite them and take advantage of some of the more cloud native capabilities that they could be because of the cost-prohibitive factor of that.

>> No, I think that that's exactly what we've been seeing. And we talked about a lot of things in the lead up to this interview, and I think part of it was, I was in a financial services company. We had a application that was written by an intern that ended up becoming production. And it was on NT 4, and this is after NT 4 was gone, and we spent a phenomenal amount of money supporting it, but we were too scared to then go and modernize that. How are you seeing, and what tools are you bringing to bear to help organizations that are in that same paralysis analysis phase about modernizing? Because it seems like AI would be typical, and people have talked about using AI to do this for a while now, over a year, but what are you seeing?

James Falkner

>> So there are tools that can help in this regard. This is Red Hat, so naturally we're open source. We have championed an open source upstream project called Konveyor, that's with a K for Kubernetes, really designed to facilitate onboarding applications to Kubernetes, and of course, from Red Hat perspective with OpenShift, but it also is a place for incubating tools to help with this. One of those tools, an early on tool was called Windup. Many of you at Red Hat were probably familiar with that. This was a tool that did what we call static code analysis, and they would essentially just look at your code, find lines of problematic code depending on what you're trying to do, whether you're upgrading to a newer version of JBoss or whether you want to move to a new version of Java or something else and tell you what needs to change. And then it's up to you to make that change. It's up to you to test that change. It's up to you to get that change into production. So what we're doing here with Konveyor is introducing a new tool called Konveyor AI, and this really takes advantage of the groundswell underneath AI and brings a different and novel way of doing this modernization. But you can take an application and just ask an LLM, "What's the next best thing I should do," and it might give you a few suggestions here. It does not know any of the patterns that you've seen in the past doing modernization at a particular company. So with Konveyor AI, we're able to take advantage of a lot of the history of an application modernization and not just ask it for the next best action.

Paul Gillin

>> Now, IBM has Watson Code Assistant. Is Konveyor associated with that?

James Falkner

>> So IBM Research is actually one of the partners in the Konveyor community. And so Konveyor AI can use as Watson Code Assistant underneath as that foundational model. And again, what we also are doing, which is very new, is taking corporation data. So historical data about other fixes that have happened through things like GitHub pull requests, JIRA issues, the static code analysis that I mentioned earlier, and we're taking all of that and using the RAG pattern, the Retrieval Augmented Generation, to improve the prompt that we send to Watson Code Assistant so that what we get back is not just awesome Java code or awesome C code or awesome whatever code or whatever language we're using, but it also takes into account all of the past history and all of that data that's extremely valuable to companies and uses that to improve the results so that a developer who's working in their IDE will see the result and see, "Oh, I need to make this change because our corporate policy requires this particular change that a base foundational model would not know."

>> Yeah, I think that, to me, is what's really interesting about this, and again, being part of that open source community, and we were just at KubeCon, feels like last week, but it was actually a couple months ago now.

James Falkner

>> Yeah.

>> When you start to look at it, all of the things that are moving around, and this is the CNCF project?

James Falkner

>> Yes, the same CNCF Sandbox project,

>> And it used to be called Tackle and it's in Sandbox now, how did we get here with Konveyor.

James Falkner

>> So I think, with Konveyor, so we've done a lot of research in the Konveyor project. We've worked with a lot of customers, not just Red Hat customers, but also other customers interested in Konveyor, interested in contributing tools to that. And we've learned from the challenges they face. One of the challenges, for example, was not the static code analysis that we'd had already completed with the Windup project, but it was doing large-scale modernization efforts at companies and getting more metadata about the applications. Are the developers still around? Do you have a mature CI pipeline that you're delivering or CI/CD pipeline you're delivering to production? We can ask these all in a questionnaire, and then rank the applications in terms of the risk to the company of modernization or not modernization and a number of other facets. And so it really brings a more systemic mechanism when you add in these tools that we've learned from the Konveyor community. And that's really, I think, the power of Konveyor. And now with AI, we're just really turbo-charging that effort.

Paul Gillin

>> What kinds of applications are you finding are the best candidates for modernization this way?

James Falkner

>> I would say any application. That's a loaded term. What we say is app modernization is not a one and done, right? It's a continuous effort. And so the applications that I would say are mission-critical, the ones that have a huge performance impact or a performance problem, those are the ones that you really want to look out for app modernization, the ones where you're going to get the biggest return on your investment. Now, of course, the answer is always, it depends. So if the developers aren't there, then you might make a different decision. But by and large, it's those applications that bring real business value today, but have the potential to bring much more if you do things like move to modern cloud-native frameworks, move to platforms like Kubernetes and OpenShift, and then you can change how you deliver that software to production and get business value in that way as well.

>> Because again, in your title, Runtimes, help people understand that might not be as familiar. What does that mean at Red Hat?

James Falkner

>> Yeah, so Runtimes, it's essentially what runs your applications at the application level. So you have your infrastructure, you have your operating system, you have your silicon, or you have your cloud instances, then you have your orchestration layer, things like OpenShift and Kubernetes. Then you have application frameworks and languages, and then the business logic sits on top of that. So our runtimes are that layer between the applications and the underlying orchestration system that provides things like clustering, fault tolerance, single sign-on, provides transaction integrity, things like that. And so, traditionally we thought of this as middleware. So Runtimes spans both traditional app server-based middleware, as well as our cloud-native frameworks, things like Quarkus and Spring Boot and Node.js.

>> And there has to be... Like you said, I think that we went through a lot of people trying to modernize, and there's been this renewed push because of AI and the hype around it. And I'll say the hype, because the reality of people actually going through and using AI to do that, they're a little scared because they're trying to figure out where was it trained and things. It would seem that some of the things that were announced today would fit really well into joining in with Konveyor AI maybe in the future, and you could see this, because Konveyor AI is not a Red Hat product, it's open source.

James Falkner

>> Correct.

>> And it's not even a commercial product at this point.

James Falkner

>> That's correct.

>> So how do you see the things playing together, I guess you could say?

James Falkner

>> Yes, it's a great question. So the historical things, like you mentioned, Tackle, and we also had Windup, which is a static code analysis, those were surfaced to Red Hat customers through the migration toolkit for applications. It's one of a suite of migration toolings that we have. We also have migration toolkits for containers and also for migration for virtualization. So these are tools that are designed to bring applications onto our platform. So with Konveyor being the upstream to the migration toolkit, that's our path to essentially our go-to-market. This is a tool that developers and data scientists and people planning large-scale migrations will use. That's where it land will be in the migration toolkit. We're planning on bringing a packaged sort of dev preview version in the Konveyor community later this summer, and then we're going to look at moving that into the migration toolkit and combining it with things like the Granite models that IBM and Red Hat announced earlier today. The other aspect of one of the announcements later was that as you use this novel way of doing a modernization by bringing in through RAG, bringing in corporate data, as that corporate data grows and grows, that's the thing that's going to get bigger and bigger. So at some point you might want to sediment that into the foundational model and fine-tune the model. This is where InstructLab comes into play, because Instruct lab, it provides a taxonomy and all the synthetic data generation. This fits really, really well with a large-scale modernization effort because that's really what you're doing is you want to take the knowledge and skills that you've learned in the past to apply it to the next modernization application that you do. And it really turbocharges and accelerates that large-scale migration.

Paul Gillin

>> Do you see large language models being developed that are specifically for migration?

James Falkner

>> That's an excellent question as well. Yes and no. So one of the things that companies often look at is, "I don't want to give away my data. I want to keep it all in-house. I'll use your foundational model. I might fine-tune it. I might use RAG and hook it up to our internal GitLab instance and bring that data in and improve the prompting, but I'm never going to give that data away." Some will actually want to do that, but the challenge there is that the patterns you see in company A are oftentimes very different than the patterns you see in company B. So it may or may not actually be worthwhile to create sort of a community-based migration tool because a lot of the value proposition is in that corporate data in the patterns that you see inside one company where they have a set of developers that made the same kind of architectures, which would apply to their applications, but not necessarily to your applications. So there could be a middle ground there that a community can develop.

Paul Gillin

>> Yeah, I-

>> Oh, sorry. Go ahead.

Paul Gillin

>> I remember one CIO at a big financial services firm once told me that he has applications in his shop. He doesn't know what they do, but he's afraid to turn them off. What do you encounter? When you're going to do modernization efforts, what are some of the crazier scenarios you encounter?

James Falkner

>> That's par for the course, right? It's like companies who, the developers are gone or they outsourced the development and now they don't know what to do, or they're running an ISV application that they don't even have control over, and they can't turn it off or they can't make changes, and there's a path for that where you can go back to an ISV and kind of put pressure on them to like, "Hey, man, you need to modernize this thing." So we see a wide range of reasons why modernization is challenging. That's one of them. Also, they look at the modernization and say, "Well, I'm not changing the application, so there's no new business logic. What's the value to me?" And in a lot of cases, the value proposition for a modernization is in how that software is delivered, not necessarily what's in the application itself. So there's a wide range of reasons. And in the research I mentioned, which is on Konveyor.io, it goes through a number of the different reasons why modernization can be challenging. Costs, just don't know, don't have the skills, don't know where to start, it spans a whole wide gamut.

>> So in the little time we have left here, put in a plug for Konveyor, and for people getting involved, and organizations, you've got a lot of your customers here, and a lot of these customers are obviously into open source, and a lot of them would not like to contribute back to it. How should they get involved? Where do you see Konveyor going over the next year?

James Falkner

>> Yeah, it's a really good question. So to get involved, go to Konveyor.io, that's our website. There's lots of blogs information about it. You can contribute rules, so when I mentioned earlier the RAG pattern that Konveyor AI uses, one of the inputs to a prompt is a rule that was discovered in your application. And so if you contribute rules to say, "If this application uses this API, here's how you should probably fix it," and the reasons why, that is very valuable to the wider community. That's where we really want to see contribution is in rule sets for not just Java, not just .NET, but a wide range of application languages, because we want to be able to support transformations and modernizations across different technologies. So I would say go to Konveyor.io and get it all. We have Slack channels, we have user groups, lots of places.

>> And where do you see it going in the next year?

James Falkner

>> So I think that a lot of the work is going to be in integrating tighter with LLMs, integrating with InstructLab as well, and just improving the overall workflow. It's pretty early days. We have the IDE integration, but we really want to kind of bring it to that next level, and not just show you how to modernize that application, but also bring it onto the platform and show you how to get that app into production safely and consistently.

>> I think that's a great place to leave it, and I really want to thank you because, again, this is actually one of the things I've been saying is that KubeCon is really Cloud-native con, and they should swap the names around because Kubernetes is there. We know it's 10 years old now. Yay, Kubernetes! And we're all big supporters, but it's really the layer above it as you start to build these cloud-native apps. And this is right in that-

James Falkner

>> Yeah, it's a brand new way to do a modernization using existing communities, but powering using LLMs and AI. It's fantastic.

>> Well, thanks, James, for coming on board.

James Falkner

>> Thank you for having me.

>> Yeah. And thank you for watching theCUBE here live from Red Hat Summit and AnsibleFest wall-to-wall coverage. We'll be back with you in a few short minutes.