 The Cube presents KubeCon and CloudNativeCon Europe 2022, brought to you by Red Hat, the CloudNative Computing Foundation and its ecosystem partners. Welcome to Valencia, Spain at KubeCon, CloudNativeCon Europe 2022. I'm Keith Townsend along with Paul Gillan, senior editor, enterprise architect or a silicon angle. We are going to talk to some amazing folks, especially in today's segment. Paul, there's a lot of companies here. Like what's been the consistent theme you've heard so far in the show? Well, you know, one thing that's different from this show, it seems to me that others I've attended is it's all around open source. We're not seeing a lot of companies bringing new proprietary technology to market. We are seeing them try to piece together open source components with some kind of, perhaps there's a proprietary element to it, but to create some kind of a common management interface or control plane, and that's quite different from what I think we've seen in the past. Open source business models have been difficult to make work historically. These companies are all taking their own approaches to it, but I think the degree to which this, the people here have coalesced around the importance of open source as building blocks to the future of applications is something I've not seen quite this way before. Well, with our current segment guests, we're going to go deep into kind of these challenges and how enterprises are addressing and their partners are addressing with those challenges. We have with us Alan Flower, head of cloud native at HCL Technologies. We'll get into how a system integrator is helping with this transition to Ramon Neeson, senior product manager at Red Hat. Welcome to the show. You're now CUBE alum. Welcome. Thanks for having us. So we're going to get right off the bat. We're going to talk about this. What are some of the trends you're seeing when it comes to application migration? You've done, I'm assuming at this point, thousands of them. What are some of the common trends? Well, it's a very good question. And clearly at HCL, we've helped thousands of clients move tens of thousands of applications to what we would call a cloud native environment. I think the overwhelming trend that we're seeing, of course, is clients realize it's a particularly complex, sophisticated journey. It requires a certain set of skills and capability. Clients increasingly are asking us for anything that we can do to simplify and accelerate the journey. Because what's really important to clients if you're on a transformation journey to cloud is you want to see some value very quickly. So I don't want to wait three to five years to transform my application's portfolio. If you can do something in three to five days, that would be perfect, thank you. Wow, three to five days, that sounds more akin to when we were doing P2V or V2V migrations, I'm sure HCL is at this point done in the millions of those types of migrations. What are some of the challenges or the nuance in doing a traditional migration from a traditional monolithic application to a cloud native? Well, it's another good question, of course. You notice that there's a general trend in the industry. Clients don't really want to lift and shift anymore. Lift and shift doesn't really bring any transformational value to my company. So clients are looking for increasingly what we could call cloud native modernization. I want my applications to really take advantage of the cloud native environment. They need to be elastic and kind of more robust than maybe before. Now, in particular, I think a lot of clients have realized that this state of Nirvana, which was, we're going to modernize everything to be a cloud native microservices based application. That is a tremendous journey, but no client really has the time, patient or resources to fully refactor or re-architect all of their applications. They're looking for more immediate kind of impact. So a key trend that we've seen, of course, is clients still want to refactor and modernize applications, but they're focusing those resources on those applications that will bring greater impact to their business. What they now see as a better replacement for lift and shift is probably what we would call replatforming, where they want all of the advantages of a cloud native environment, but they haven't necessarily got the time to modernize the code base. They want to refactor to Kubernetes and re-platform to Kubernetes in particular, and they want us to take them there quickly. And that's why, for example, this week at QCon, eight sellers announced a new set of tools called KMP based on Conveyor, an open-source project supported by Red Hat. And the key attraction of KMP is it lets me re-platform my applications to Kubernetes immediately, right? Within two or three minutes, I can bring an application from a legacy platform directly onto Kubernetes and I can take it straight into production. That's the kind of acceleration that clients are looking for today. Isn't that just a form of lift and shift, though? Well, no, lift and shift typically, of course, was moving virtual machines from one place to another. You know, the focus of Kubernetes, of course, is containerization of solutions. And it's not just about containerizing the solution and moving it, it's the DevOps tool chain around the solution as well. And of course, when I take that application into production in a Kubernetes-based environment, I'm expecting to operate it in a different way as well. So that's where we see tremendous focus on what we would call cloud-native operations, clients expecting to use practices like site reliability engineering to run these re-platformed applications in a different way too. So it sounds like you're saying, I mean, re-platforming has been a spectrum of options. I think Gartner has seven different types of re-platforming. Are you seeing clients taking more mature attitude now to re-platforming? Are they looking more carefully at the characteristics of their legacy applications and trying to make maybe more nuanced choices about what to re-platform and what to just leave alone? I think clients, and I'm sure Roman's got some comments on this too, but clients have a lot more insight now in terms of what works for them. They've realized that this promise of maybe a microservices-based applications estate is a good one, but I can't do that for every application. If I'm a large enterprise with several thousand applications in my portfolio, I can't refactor everything to become microservices-based. So clients see re-platforming possibly as a middle ground. I get a lot of the advantages from a cloud-native environment. My applications are inherently more efficient, hopefully a lot more performance. It's a matter of software delivery performance. So legacy workloads will definitely benefit from being brought into Kubernetes in the software delivery performance department. So it's a matter of somehow rebumping your legacy applications and getting the benefits in application life cycle management, if full tolerance and all that stuff. It's about leveraging what Kubernetes offers. When you say bringing legacy applications into Kubernetes, it's not that simple, right? I mean, what's involved in doing that? It isn't, it's just a matter of taking a holistic view at your application portfolio and understanding the nuances of each application type within your organization and trying to come up with a suitable migration strategy for each one of these application types. And for that, what we're trying to do is provide a series of standardized tools and methodologies from a community perspective. We created this conveyor community. It was kickstarted by Red Hat and IBM, but we're trying to bring as many vendors and GSIs as possible to try to set up these standards to make these roads towards Kubernetes as easy as possible. So we've done a little bit of app modernization in the CTO visor hybrid infrastructure. And one of the things that we've found is there's plenty of advantages. If I take a monolithic application that has, that I've traditionally had to scale up to gain performance, I can take selective parts of that and now I can add auto scaling to it. However, as I look at a landscape, out in thousands of applications, I need to dedicate developer resources to get that done in my traditional environment. But my traditional environment is busy building new, my traditional or my developers are building new applications and new capabilities. I just don't have the resources to do that. How does HCL and Red Hat team together to kind of fast track that capability? Well, I'll comment on two things in particular actually. The first thing, when it comes to skill in, I think the thing that's really surprised us at HCL is so many of our clients around the world have said, we are desperately short of skills. We cannot hire ourselves out of this problem. We need to get our existing developer community reskilled around platforms like OpenShift, Conveyor and other projects too. So the first thing that's happened to us at HCL is we've been incredibly busy, undertaking probably what we would call developer workforce modernization, where we have to help the client reskill their entire technical and developer community to give them the skills. So we will help the clients, the developer community, build the cloud native understanding, help them understand how to modernize tools, for example, or applications. But the second thing I mentioned is, this comes back to comment that Raman made around Conveyor, it's been really encouraging to see the open source community start to invest in building the supporting frameworks around my kind of modernization journey because if I'm a developer that's reskilling and I'm attempting to maybe modernize an application, being able to dip into an open source project, I mean a good example would be Tackle, part of the Conveyor project. You now have open source based tools that will help you analyze your applications, they will go into the source code and they will give the developer guidance in terms of what would be effective treatments to undertake. So perhaps the development team that are new to this modernization journey, they would benefit from a project like Conveyor, for example, because I need to know where can I safely modernize my application. Now for experienced organizations like HCL, that comes naturally to us, but for people who are just starting this journey, if I can take an open source tool like Tackle or the rest of Conveyor, for example, and use that to accelerate my journey, it takes a lot of pressure off my organization, but it also accelerates the journey too. And it's not just a matter of tooling, we're also open sourcing the modernization methodology that we've been using in Red Hat Consulting for years, so these whole conveyor communities, it's all about knowledge sharing on one hand and building a set of tools together based on that knowledge that we are sharing to make it as easy as possible. And what role does Red Hat play in all that? I mean, as you've carved out this position for yourself as the true open source company, does that position you for a leadership role in helping companies make this transition? I wouldn't say we should be leading the whole thing. We kick-started it, but we want to get other vendors and more for this thing. One cool thing about the Camero community is that IBM is open sourcing a lot of their IP, so IBM research is on board in this thing. We have some really crazy stuff related to AI being applied to application analysis. We have some machine learning in place. We have very cool stuff that has been sitting on a corner in IBM research for quite some years, that now it's being open sourced and integrated in a unified user experience to streamline the modernization process as much as possible. So let's talk about the elephant in the room. HCL was leading the conversation around Cloud Foundry circa five plus years ago, and as customers are thinking about their journey to Cloud Native, how should they think about that Cloud Foundry to Cloud Native or Kubernetes re-platform? Well, within the Cloud Foundry community, we've been quite staunch supporters of Kubernetes for quite some time. It's quite a stated intent of the Cloud Foundry Foundation to move across to Kubernetes platform. Now, that is a significant engineering journey for Cloud Foundry to take. Now, we're in this position where a lot of large users of Cloud Foundry have a certain urgency to their journey. They want to consolidate on a single Kubernetes-based infrastructure. We see a lot of traction around OpenShift, for example, and Red Hat in terms of its market leadership. So a lot of clients are saying, we would like to consolidate all of our platforms around a single kind of Kubernetes vendor, whether that's Red Hat or anyone else, quite frankly. So what HCL is doing right now with the tools and the solutions we've announced this week is we're simply accelerating that journey for clients. If I've got a large, installed base of applications running in my Cloud Foundry environment, and I've also started to invest in standardized on Kubernetes-based platforms like OpenShift, most clients would see it as quite a sensible choice to now try and consolidate those two environments into one. And that's simply what we're doing at HCL. We're making it very, very easy. In fact, we've fully automated the journey so I can move all of my applications from Cloud Foundry into, for example, OpenShift pretty much immediately, and it just simplifies the entire journey. So as we start to wrap up the segment, I'd like to know customer stories. What, how are customers either surprised or challenged when they get into, even with the help of HCL and Red Hat, why are they seeing the most difficult parts of their migrations? Well, my simple comment would be maybe complexity, right? And the associated requirement for skilled people to undertake this modernization work. We spoke about this, of course, in terms of clients now a lot more realistic. They understand that their ambition now needs to be somewhat tempered by their ability to sort of drive modernization quickly. So we see a lot of clients when they look at their very large global portfolios of applications, they're trying to invest their resources in the higher priority applications, the revenue generative applications in particular, but they have to bring everything else with them as well. Now, a common kind of separation point was we see a lot of clients who might say, I'm going to properly modernize and refactor maybe five to 10% of my portfolio, but the other 90% also needs to come on the journey as well. And that's really where re-platforming in particular kicks in. So the key trend again is clients saying to us, I've got to take the entire journey, all right? I've got the resources and the skills to really focus on this much of my application base. Can someone simplify the overall journey so I can afford to bring everything on a cloud-native journey? So the key to success here is having a holistic view of the application portfolio, segmenting the application portfolio and different application types and ordering the priorities of these application types and come up with suitable migration strategies for each one of them. That's the key to success. Is it really necessary to move everything though? Not necessarily. No. Or not necessarily, absolutely not everything, but it would make sense, as we were saying before, it will definitely make sense to move legacy applications towards Kubernetes to leverage all the software delivery. That's a big project, right? It is. If you're going to restructure the application around APIs and microservices. But it should be taken, the way I've seen organizations exceeding the most in this road towards cloud-native and Kubernetes in general is trying to address the whole portfolio. Maybe not move everything, but try to have this holistic view and not leave anything behind. Because if you try to do these isolated initiatives of bringing these or that applications in isolation, you will miss part of the picture and you might be doomed to fail there. Yeah, it's been my experience that if you don't have a plan to migrate your applications to a cloud-native operating model, then you're doomed to follow lift-and-shift examples to the public cloud, whether you're going to any other clouds. If you don't make that operational transition. Last question, on operational transition, we've talked a lot about the replatforming process itself. What about day two? After I've landed to the cloud, what are some of the top considerations for compliance, observability, just making sure my apps stay up and transitioning my workforce to that model? I think the overarching trend or theme that I see is clients now are asking for what I would call cloud-native operations. And in particular, there's a very solid theme around what we would call reliability engineering. So think about site reliability engineering, SRE, platform reliability engineering, and PRE. These are the dominant topics that clients now want to engage HCL on in particular, because the point you make is a valid one. I've modernized my application. Now I need to modernize the way that I operate the application in production. Otherwise I won't see those benefits. So that general theme of SRE is keeping us really busy. We're busy re-skilling all of those operations, teams around the world as well, because they need to know how to run these environments appropriately too. And also being able to measure your progress while you are transitioning is important. And that's one of the concerns that we are addressing as well in the Camero community with a tool called Polaris to effectively measure the software delivery performance of the organization after the transition has been done. And this is a really good point, by the way, because most people think it's a bit of a black art. How do I understand how I modernize my application? How do I understand how I've improved my kind of value chain around software creation? And many people thought you needed to bring in very expensive consultants to advise you on these black arts, but in open source projects like Conveyor from Red Hat, the availability of these tools available on an open source model means any engineer, any developer can get these tools off the shelf and get that immediate benefit. Well, Alvin Flower, head of Creative Labs at HCL, and Ramon Leeson, Senior Product Manager at Red Hat, thank you for joining theCUBE. You're now CUBE alone. You'll have a nice profile. You'll like the profile pictures on there are awesome. Absolutely, thank you. From Valencia, Spain, I'm Keith Townsend, along with Paul Gillan. And you're watching theCUBE, the leader in high tech coverage.