 Hi everyone, today we have an awesome presentation for you. We have Bob Quillian from Beat Function and Marcus Noggle from Red Hat and the Khmeri community. So the way that we're going to do this today is that Bob is going to go over some research findings that they have from a research that they commissioned on the topic of app modernization. And then afterwards Marcus is going to come on and tell us of how this compares, how those findings compared to what he's experiencing with customers out in the field. And once we get through both of those sections, then we'll have time for any questions that you guys may have. You can put those questions in the chat throughout the presentation. Just know that we likely won't get to them to the end of it. And with that, Bob, it's all yours. Great. Thanks Jonathan. Yeah, I'm gonna go ahead and jump on into it. I'm excited to be here to talk about our findings in this research report. We just completed with Wakefield. And really part of our goal here was to benchmark where the industry is with app modernization, considering we've been through maybe 10 to 20 years of app modernization projects. Many not successful, many are. And we'll talk about kind of the goals of those projects, kind of talk about the terms. And, you know, baseline, how people are looking at modernization, talk about why things fail, why things succeed, and maybe some recommendations for success. So we just completed this research just a month or two ago, and the research is available on our website. Feel free to dive in and look at all the details around it. We talked to 250 developer teams and architects and who are actually in the business of maintaining monolithic applications and Java applications. So this was a really focus on these application teams, the challenges they have, kind of where the industry is today. So if we take a look at, you know, where the market is currently, I'd say that 78% of the market is really in this meaty part of the middle, where they're planning to modernize, but they haven't started yet, many have just started, and some have made progress, but that's really the mass majority is in that area. The other 22%, 8% haven't started at all, 14% have made significant progress, but the mass majority is really a focus on modernization as a key area of progress. They're trying to, in many ways, figure out, you know, what's went wrong, but also how to improve it and move it forward in a much more effective way. And Bob, do you want to go into a slideshow of you so that way you can, yeah, there we go. Is that not showing up in slideshow? Yeah, it just shows all of them right now. So like when you were talking about the different stages earlier, it was still on the cover. Yeah. Okay. Yeah, I'm sharing it. Let's see. Yeah, so you're not seeing that as a overall window right now, right? We're seeing it. We're seeing all the slides and the main slide. Yeah. There you go. Let's do it this way. Okay. So, yeah, so the, if you take a look at the headlines and the headlines in this particular survey, 79% of modernization efforts are failing and there's a high cost over one and a half million. Many are costing over $2 million in terms of the overall project, so it's expensive. And it's taking a lot of time over a year and a half. Sometimes over two years is the average for these projects. So they're taking a long time. There's a lot of risk. There's a lot of failure. There's a lot of frustration in the marketplace. And I think that is basically the system what we've seen throughout the industry for the last five to 10 years. Now, take a look at basic terms of how you define app modernization. There's been a lot of confusion, I think, in the marketplace, too. What is modernization? It's been kind of used in many different forms and factors. There's many R's. We kind of joke about there was five R's and seven R's. We've seen nine R's. There's an app modernization from replacing, rehosting, through platform, through factoring. We really wanted to get a baseline first of how people are defining the term app modernization. And what's encouraging is we're starting to see a clear understanding that refactoring and, in second place, rewriting are really the two key areas people focus on when they talk about app modernization. So 60% say the true definition of modernization is refactoring. So a lot of lift and shift and rehosting and replatforming has happened over the last probably five to 10 years. And I think that's a key issue that we've seen in people trying to do a stopgap or kind of kick the can down the road in terms of trying to modernize by migrating and lifting and shifting and model it into the cloud itself. But we're also seeing from other surveys too that migration is beginning to move down. The priorities and modernizations beginning to move up and is actually superseded migration as one of the key issues that people are trying to benefit from when they look at overall priorities in terms of IT and IT investment. So what is the overall goal about modernization? And this is just where it's kind of interesting as we've begun to split the survey in terms of the business leaders perspective and then the technical perspective from the architects are actually in charge and actually have their hands on the project itself. So executives look at app modernization in terms of how do I increase innovation? How do I lower my technical debt, get the product moving more quickly, create more scalability in my business? And if you take a look at architects, they kind of look at the other side of the coin where innovation has a direct inverse relationship to engineering velocity and technical debt. So they want to increase velocity. They also want to innovate. They also want to increase scalability on the architect side or technical side, but they also are beginning to focus, you see from the architects, the emergence of the people side of things. So it's not just about the business. It's not about the engineering and the technology itself, but it's also about the developer side and the cultural side of one is hard to ramp up new developers into an older monolithic application. Two, it's hard to retain those and keep those developers motivated and employed. And it's even hard to organize them successfully because monolithic application usually implies a monolithic team. We have a lot of people working on the same thing. It's hard to break it into smaller groups. It was harder to work in a remote environment like we are today in many cases where we have remote offices. So what happens as we start these projects? What are the obstacles that people face? Well, the top reason we see for pushback is risk. And risk is a big issue. 97% of these organizations are seeing some level of pushback in every modernization project, but any application is up and running now. It's business critical. You're running your business on it. Key business flows are still going through it, even though it's been around for 10 or 20 years. The risk of changing is very high. Executives also look at the cost associated with that and the ROI of actually doing the work. The architects look at risk also, apart from a technical perspective, but they also look at once again the cultural side of things. There's a fear of change inside the organization. And there's a fear of losing the role itself. So losing the role and beginning to lose their part of the organization. What's interesting as you look at refactoring projects, more and more we're seeing people were able to maintain that team and move them forward, which is nice. If you maintain the logic, you can help build a bridge between the older technology into new cloud-native technologies that move those teams forward. So a proper organization, a proper plan, can help you then move the stakeholders forward without the fear of losing their job. So it actually has a good cultural benefit if it's organized correctly. So we have seen all this huge number around application modernization. Projects failing. Why are they failing? So the executives say, one, a failure to set expectations correctly or accurately. And that includes not looking at the cost correctly, maybe not understanding the org structure that's required. This is interesting. There's a lack of information available to build a clear business case from an executive point of view and kind of their focus on how these things are starting. And there's not a clear before and after or clear understanding between the technical side and the business side of what they're trying to accomplish. That was one of the key findings we saw is that how you start really implies and helps how you finish in terms of the results. So on the architect side of things, they call out the lack of intelligent tools. And we talked about the challenges of doing modernization data, which is being a very manual process, takes a lot of time, takes a lot of, you know, unraveling and unwinding and dealing with all this tangled web of dependencies. But being able to have the tools that help you through that is really something that's been lacking from an architect's point of view. The training complexity all play in the minerability to set expectations correctly. And I would say the lack of tools actually is also impacting the way to set expectations. Because you can't see inside the model of themselves. You can't actually understand what it's going to take to refactor or modernize that application. You're kind of just making the best guess. And they all agree that the org structure needs to be correct around making this project successful. So, you know, one thing we talk about a lot and add a little color to this is, you know, a, we're looking to what are you trying to achieve in setting expectations. I go back to, you know, splitting the view between migration and modernization. And the cloud providers over the last five to 10 years are really focused on migration, lifting and shifting models into the cloud. It's faster. It improves your security DevOps, helps you close down some data center technologies. But really, you're not modernizing anything. I think that's beginning to be an evolution of understanding how people are looking at the modernization problem. If you want to get that velocity that people are looking for, if you want to increase innovation, if you want to begin to get those, that application scalability, well, you're not going to get that unless you look at refactoring, we are particularly writing. So I think that we're seeing through this survey, more and more understanding that migration does not equal modernization and the need to actually, if you want to achieve these goals, which are the top goals of modernization, you really have to be looking at some of these different R's besides be hosting, be platforming. The other thing that we also see around expectations is some people try to do the quick fix. And a quick fix happens by throwing an API layer on top of the monolith and maybe putting a nice shiny UI on top of it too. Once again, it's kind of a stopgap. You get some benefits, you get a nice UI, celebrate that the API provides some capabilities that you didn't have with just the monolith. But you still have a monolith. You still have the issues that you're unable to meet those requirements, meet the goals, etc. And these are two things that we see that migration versus modernization and the jumping to a quick fix approach. That's why a lot of these expectations are not being met, and why a lot of people are feeling like modernization is too risky. There's not a good plan set in place, etc. So one of the most difficult steps in the modernization project, and once again, we split this between the business leaders, the executives, and the architects on the technical side themselves. The executives look at securing budget resources and actually it's where the architects agree. Starting how you start, how you set the plan, how you build the business case, and how you understand what you're going to focus on really breaks down into a successful project later on. But that's the most difficult step. And that's an agreement interesting between the executives and the architects. Executives say it's difficult to know what to modernize. I think this comes down to an understanding of being able to look inside the monolith, having the tools, the data, understanding where the technical debt is being carried, etc. Training and preparing a staff once again on the cultural side. And then finally, architects talk about executing the project successfully. So having the right tools in place, right plan in place, etc. So there's a planning and assessment phase, there's an execution phase, and then there's an organization on making that successful. So having a really clear plan of how to make this happen is important. Having the tools to execute it is important, and having the staff ready and training to make that happen. So as we talk about what are the top two challenges with refactoring, and people look at refactoring being the top option when you go into a modernization project, executives say it takes too much time. And architects say it's too difficult. And once again, I think this is an indication of complexity. I think it's an indication of a lack of tools, and a lack of understanding of what it's going to take to make this successful. There's a common basis, the common language upfront in terms of assessment, and having the data upfront you agree to, if you understand the challenges that you're going to be up against, then it becomes much more effective in terms of executives understand how much time is going to take, what the goals are going to be. And architects would have a much better understanding of the complexity that's difficult to make this happen. But right now it's a big challenge. But the challenge is something that is, you know, you don't really have an option. You need to be able to, you know, the option of not modernizing is you have to maintain the model of it. So, you know, if you keep doing that, it's going to, you know, have an issue of continuing to keep up with the business requirements. This is where the executives come in, they look at the business side of things. And why can't they keep up with the business requirements? Because this is growing technical debt that's weighing you down, to be able to drag on the application team. They find developers that can maintain and then having the time to fix and add new features. So, features, business requirements talk to the business side of things, technical debt and developers talk about the technical and the cultural side of things. Architects, when they look at the problem, where the top challenge is maintaining it, it comes down to ramping up developers, recruiting developers, actually retaining those developers, organizing the team, then that drives the ability to keep up with the growing technical debt and that tipping point that we're all seeing around technical debt itself when it becomes too much to handle, then that translates into keeping up with the business requirements. So, see developers, technology and business requirements once again, pretty consistent in terms of how they look at the kind of a reorganization of how people approach the problem. So, people are being successful with application modernization projects and the ones that are being successful cite having the proper resources and the tools in place to be successful around these projects. So, what are the patterns, the best practices for these high-performing teams? One, they have to have the right organizational structure and the tools, the schedule and the resources to do that. Really, that comes back to that planning process. Planning, having the right information in advance, taking your time to have the before and after, I have to be able to understand what I'm going to try to accomplish, benchmarking where I am now, and be able to show afterwards that I did accomplish those goals. And that includes having goals that are well-defined, having the deficient tools, and having the time. So, in my perspective, I think that's actually some of the key elements that we're seeing across the board of how we make these projects much more successful. So, key takeaways, app modernization is a key initiative, 92% are playing to or I've already started their app modernization projects, but we see a lot of failures, they're taking a lot of time and taking a lot of money. So, the pushback is something that everyone deals with, but having a strong understanding of the cost, the risk and complexity up front can help mediate those issues. So, then it helps you then prioritize those going forward. And architects and executives agree that the challenges are there, there are reasons for failure, but there's also a path for success of having the right tools, having the right training, and focusing on the technology side, but the people side of things too. So, that kind of wraps up the Wakefield research report, and I'll stop sharing right now, and kind of hand it back to Jonathan to talk more about it. Thanks, Bob. Awesome insights. So, everyone, if you have questions as we go through this, feel free to put it in the chat. Now, I'm going to bring out Marcus. So, Marcus has experience in the field, and I thought it'd be interesting to get his insights on and see how these fundings match up to his experience. Marcus, if you want to give a light intro and yeah, I don't want to waste your time. So, Marcus here. Hi, everyone. I work, as you can see, I work at Red Hat. So, I'm a senior architect with Red Hat Services in the EMEA Solutions Practice. So, basically, what that means is I'm helping customers across Europe and the Middle East onboarding applications and modernizing applications onto Red Hat's spin of Kubernetes, which is obviously OpenShift, and the whole tool chain around it. So, furthermore, I also internally at Red Hat lead the application modernization community, and as such, I'm also well feeding back our field experiences, stories from the trenches, if you will, back into the conveyor community, and also help build best practices around that. And so, well, first and foremost, I would like to thank Bob for sharing this and commissioning this research, because it basically mirrors 100% what I see in the field every day. So, I encourage every one of you to go to the V-function website and download that report in full, because it's very well worth reading. So, I did, and I did regret it. So, I just wanted to elaborate on a couple of things that stand out for me, what I see in the field, and maybe that can help you listeners, viewers tackle those challenges a bit better or be prepared when you encounter these. As Bob just said, one of the key things we see at customers is, and what's really super important is making the case, and that it sounds super obvious, but the thing is what we see as Red Hat services, and probably there's people from SIS, Red Hat partners that have seen the same thing, is when we go to customers, they tell us, yeah, we need microservices, we won't onboard that stuff. And we have to ask, okay, so that is the means, but what is it that you're trying to achieve? Is it cost reduction? Is it reduction of technical depth? Is it developer flexibility? Do you want to free up your developers from manual and menial tasks of keeping the monolith alive, basically, to free up that time for real innovation? Do you want to move ahead of the pack of your competitors? So, what is, basically, what is the why? Why are you starting this? Why are you, well, basically investing money, time, people, people's time to start this endeavor? What is it? And the important thing is throughout that whole modernization project, executives will typically, as Bob just said, and that also mirrors what we see, those things take time. There's no pixie dust that you sprinkle over the application, and then everything will be fine. You have to invest, you have to invest a considerable amount of time to do that. But one of the key things is those executives would want to have some kind of feedback. So they will naturally not be in the project all the time, but they would want some reports. So, basically, having a baseline of where are we starting? What are we trying to do? What is the application portfolio, planning that properly, grouping it, analyzing it, assessing it, and grouping it into, well, these are the low-hanging fruit. This is, for example, something that we can provide value with very early on, migrating that because it's very simple, and it will give the team that's doing that some experience, how to handle the new technology, how to deal with hopefully a better team structure. So all these things, those need to be properly planned, and planned, scheduled, and, well, if you don't have a baseline, if you don't know where you're starting from, then you can tell the executives who are basically opening their pocket. Okay, so this is what you wanted, but this is where we started, and this is our progress, and these are the improvements. So, being part of the conveyor community, there's one thing probably you want to look into, Pilaris providing some dashboards on the typical software development matrix in terms of velocity, meantime to recovery, etc., etc. I won't dive into that now, but this is one tool, for example, that can help you doing that. But this is the one finding, making the case that really stands out because if you start wrong, there will be no chance to really, to really amend starting on the wrong foot if you allow. So that's really, that's really crucial. And so through the whole project, also tying that back into the strategy that you're following is also super important. For example, just one, won't obviously share customer names here, but one customer was saying, okay, I need to, basically my primary driver is, I have a renewal upcoming with vendor ABC, and I was thinking about moving off of that platform anyways. And now is the time to not only migrate my monoliths from A to B, but also modernize these because I have to touch them anyway. But the primary motivation for that was cost. So that will inform the strategy that you're following. So these applications that are, they had more, they have 105 applications, actually, that have to be migrated. And those that were on that specific platform that was with the renewal around the door, they basically needed to move these first and tackle these first before, before all the other ones, although some of the other ones might have been slightly easier. But as you see, what's the executives, what the executives target outcome in this case, cost saving is also has a huge impact on what comes first, basically. So that's, that really stands out. Yeah, Bob, go ahead. No, I was going to chime in a bit too that the, yeah, I was not surprised at the pain and the issues and the cost and all the different complexities of doing modernization. But, yeah, the resounding kind of consistency around the lack of this plan, the need for a better upfront planning. Those columns, you know, remind me that there's just not a good way to measure technical debt and that way to understand the complexity of these applications before you start them. And I think that's part of the, part of the challenges of having the data that's measurable, that's, that's calculated, that begins to help you both from a technical perspective have confidence, how long it's going to take, what are the, what's the first service I want to pull out, or maybe how I'm going to prioritize applications too. Maybe this is highly complex. Let's go take me extra time. I know that now. I have, my gut told me it was complex, I'm kind of stuck in the middle of it. But I have these three other applications which are a little less complex, still mission critical, but maybe I get those done first, or maybe I can, you know, outsource those while I work on this with my key application team. So, yeah, the prioritization is important, having the tools to look in advance and try to understand deeper what the technical debt is. That's a kind of a key kind of part of the understanding that there's an interesting question here around rewriting versus refactoring and re-architecting. And so, you know, how to decide between those but also what's the difference. And maybe we can also talk about that in terms of refactoring. I would put on a spectrum, refactoring, re-architecting, rewriting, kind of also kind of blend together. You have a monolith and you want to begin to pull out services out of that, but keep the code itself and refactor that particular set of code. Really, it's maintaining the code but beginning to change the architecture from a monolithic architecture potentially to a microservice or cloud-native architectures. Typically, refactoring is in that mode. Re-architecting might be taking, you know, some of the applications and services, putting them together, maybe, you know, throwing some of the monolith away and adding in new services. And then a full rewrite is actually starting to rewrite the actual business logic. We find a lot of times with mollus, the code is actually is working and it derisks the actual project by maintaining the actual original source code but just beginning to take that set of code that's in the monolith that represents a domain, beginning to pull that out into a service and use that as its first step to modernization. So, but there is a kind of a spectrum that's connected from refactoring to re-architecting, re-writing, and sometimes people kind of move between them synonymously. So, but they basically are about retaining and beginning to move that application forward in terms of its architectural. I'm sure you've got a lot of background with that Marcus too. Yeah, yeah, so one thing just to add here, maybe a little bit of it, well, some experience from the field is when talking to executives and also architects, as you said, so I said 100% what came out of that report totally resounds with me. The thing is risk, well, no custom, well, the other way around, all customers are naturally risk averse. So that's, we don't want to derail their business, but we need to achieve those goals. So when we talk about specifically monoliths, I'm not talking about this simple thing, I have a super small spring boot application that I need to onboard into container, that's not the use case here, but most of the critical business applications, they have grown over time, and naturally they have grown bigger and bigger. And so there won't be a, or they shouldn't be at least a big bang approach. So developing behind closed curtains for 18 months and then coming out with a new version and then finding out, okay, that didn't resound with my users or it didn't, we only captured like 80% of the functionality. So what you would be doing is applying the strangler pattern. And for that, for that, absolutely also need to, you need to analyze the monolith, see where are the, in the domain driven design speak, where are the bounded contexts, where are the transactional context, et cetera, to carve out, to carve out bit by bit, service by service. And the thing is, the advantage coming back to what I was saying about risk, the advantage of that is if you're doing this in this stepwise approach, what will probably happen in the course of that project is that you have implemented something not quite right. So what you can do is then you can basically throw away what you did or amended whatever and for the time being switch back on that service in the monolith because it's still there. So you're not throwing it away. You have to find means and there's tools around that as well. You have to define basically an API that will then connect your new monolith, sorry, no, definitely not your new microservice to that old monolith. And if something fails, you can basically see what went wrong and switch that back. So that takes out a lot of risk out of that approach over a big bang approach. So that's definitely, but as Bob said, you need to know where to apply the knife. Yes, one of the patterns of success that we've seen is for those very complex tens of millions of lines of code monoliths, megaliths, you might call them, that an iterative approach or selective approach for people to iterate, they do one service at a time, pull that out, maybe they do another service and get some success, maybe they leave some services behind. So part of the upfront planning is to say, I'm not, it's not a big bang, like you said, this is something that requires some iterative, you might, some ways you're leaving them all on the model of behind, you're pulling out some services that are critical, maybe they're going to come mine with some other services you've already already done. So I think the, that's a, for our most successful projects, people have taken an iterative approach or they've gone in selectively. So I know there's three services I want to pull out, I need to find out where they are, what the most effective way to do that is, and begin to strangle the rest of the model involved. So I think that's a, another key, a key pattern for people who are looking to communicate, what are my, what are my plans, how am I going to have early successes and, you know, claim some and de-risk the process to, claim all the success too. So, yeah. Absolutely. Then one, one, one thing that probably most of, most of you already know from the, from the Kubernetes community, well, to be, to be technically correct, we're talking about modernization and that is, that is not in its entirety tied to containers and Kubernetes. However, that is 99% of the use cases these days. But you can still modernize without, without containers. But let's just focus on the 99% and forget about the 1% for the moment. What, what can help you with that is evaluating Kupert and tools to migrate your existing VMs, VM deployment of your monolithic application and move that onto Kubernetes and the VM in all its complexity in, in the megalith, as you, I like that word. As you just said, that lives in Kubernetes. Why would we do that? You might ask the thing is, you can then apply the strangler pattern and you only have one platform to manage. So it's still, it lives in Kubernetes. The VM is configured via, via Kubernetes artifacts. So basically everything is Kubernetes and you can basically shift the functionality slowly but steadily in a continuous iterative approach from that monolith so that VM will get smaller and smaller while your microservices, your native Kubernetes artifacts will, will become more and more and you will gain more and more flexibility. So that's also one thing to consider. Yeah, yeah, I'd say that's a, that's a great pattern. The, where I've seen some customers stop is like they get it into Kubernetes and they leave it there for a while. Yay, we're successful. They've done the migration. There's a level of celebration that we're in the cloud running on Kubernetes. And then six to nine months later, they realize that they are eating a way too much CPU memory and they don't have any of that orchestration control. So yeah, we have these discussions. So, so then that is, that is not, that is not only tied to, to actual VMs using Cupert, but we see that every day, like containers that are actually VMs. If you're really, if you're really honest about it, it's, it's just a VM that is not AV, it's not called AVM, but it's monolithic. It takes minutes to start up. It has some very specific requirements. It needs some, some modifications on the, on the Kubernetes nodes to be able to run. So really nightmares and that is not, and that's why it's super important to plan this correctly and ask the customer, what is it that you're trying to achieve? Because none of these migrations, it will take one of like 20 boxes. So it's now running on Kubernetes. Yeah, great. But what have you actually achieved? Exactly. Yeah, that's right. I'm always trying to reinforce that a migration is fine, as long as it's in the context of a broader modernization project. But I think we've seen time and time again, people stop with the migration and they come back a year or two later and realize they're, they've have a kind of remorse, migration remorse or lift and shift remorse. They're up there in the cloud. They're eating up a lot of bandwidth, reading up a lot of the costs in the cloud and they're not getting the benefit they wish they had. So, so yeah, continuing on with the process, having that full kind of continuous view of what happens next. And I think the good news is that, you know, from the survey and from other kind of indications in the marketplace, we are seeing people beginning to understand the difference between migration and modernization, cloud providers are beginning to push on that much more. We're seeing an interesting emergence of gen one fast vendors and cloud vendors have been in the cloud maybe five to 10 years who were originally a monolith now looking to do a modernization. So they're already in the cloud, they're a cloud vendor. They've been running as a monolith successfully for maybe five to seven years. Now they're looking at trying to modernize and take advantage of the rest of the benefits of containers and Kubernetes and microservices. So, so yeah, I think there's a broad spectrum of people near the older monolith that are sitting on prem, but there's also monolith in the cloud already that need to be addressed. Absolutely. So guys, I actually have a good, good amount of questions that have arose since you guys may have to dig deeper into this. So the first one is, Bob, you may want, you may want to go for this first. How do you define rewriting and its differences with refactoring? Yeah. And I think, yeah, it's a, it's something that we've, we've touched on in the survey itself. And you see it, I mentioned that the seven hours, the nine hours, the five hours around modernization. But in kind of going back to that view of refactoring can actually take the existing code and begin to refactor how it's being applied, but then the architecture. So it's a, it's a kind of re-architecting. So refactoring, re-architecting have a kind of a similarity and a rewriting is actually being to rewrite the actual code itself. So with refactoring able to maintain the business logic, you actually begin to carve out the domains, find that code itself, it de-risk the process. You begin to move from a, a monolithic architecture and refactoring it into a microservice architecture. But that requires you to understand domains, being able to strangle off the old, old monolith flows and beginning to move that into this new architecture. A full re-architecture will be right, tends to actually get into a broader project. We see people starting with a refactor and then they kind of go into a, and then rewriting some new code, but also then re-architecting some other things. So there's a, I think it, people move back and forth in terms of those projects, but they have similarities in terms of if you have code that works, you want to de-risk it, you want to re-factor it first, and then begin work through and re-write it into a re-architecture process. Yeah, absolutely. So the lines are blurry there. So it's, well, it really, it really also, well, typical consulting answer. It depends. The thing is, the thing is, basically, there is a lot of, basically, I call that condensed knowledge. Condensed know how the company works, how the business processes work, condensed in code. And you don't necessarily want to throw that away when it has been proven working. You just want to modernize it. Hence, that's why we're here. But you don't want to throw away all that knowledge about your internal business processes unless you're trying to reorganize these processes as well. Or another use case that I've dealt with last year is if you're on a platform, speak mainframe, where you have tons of core ball and PL-1 code. And you can, simply, there might be some ways to really do it. But in those cases, what you really have to do is, well, following that same strangler pattern approach, carve out those modules. But you cannot, you cannot migrate like PL-1 code without any hassle to Java code, for example. In those cases, it's basically rewriting is more or less the only option you have. I know I'm not technically correct. There are some translation mechanisms for core ball and PL-1 to Java, but well, with mixed results. So in those cases, if you want to modernize that, you just have to rewrite. Okay. Thank you both. The next question, and I think this is related to the study, what's the size of modernization projects in terms of the number of applications in a project? Typically, I think, you know, what we've looked at it, and kind of what, at least when we dive into it, a project itself is usually one application. So it's a monolithic application. There's a broader mandate to modernize more applications. So usually it's within the context of a broader modernization initiative. But a project itself is typically one application or monolithic application. And that could be, you know, small as Marcus said, but also, you know, the ones that typically where people raise their hands for help are the ones that are, you know, millions and millions of lines of code, thousands, tens of thousands of Java classes, for example, where it's difficult to really get in there and detangle this tangled, you know, ball string and begin to pull out the different dependencies and different services themselves. So you start with one application. Typically, once that starts going, you could build a flow of factory model that is much more repeatable. And your team is trained. You understand some of the tooling, some of the approach. The business side understands what they're expecting if you've had success, and then the engineering side too. So part of it is getting that flow going from a factory perspective. Usually, most organizations don't have just one model if they're sitting on top of, you know, maybe hundreds or thousands, we've seen, they know there's a core set that need to be modernized first, but there's a broader set that need to be addressed. And that's where prioritization happens and we're having a set of best practices where you've had some success to be able to move them forward and much more efficiently. Okay. Go ahead, Marcus. Yeah, so that also, we have some customers, the minority, though, that would ask us, okay, can you help us with this one or two applications? However, then more often than not, we tell them, okay, so if you're doing this in a one-off, typical project approach, what will happen is you will invest a lot of time and resources and then it will happen successfully, hopefully. And then that team will dissolve again and then a couple of months later, you think, okay, now this application and then all that knowledge will be lost. So what we typically tell our customers, why not take a step back and look at the application portfolio? There might be applications that are actually not worth looking at because they will be decommissioned in the next year or so anyways, but looking at the bigger portfolio and then also building a strategy from that is definitely worthwhile effort because what we preach to our customers is use, basically capture all the information, even the slightest bits of information of also there's nothing wrong with failing with things. You can learn from a failure, you can learn from a technology used wrong, but document that because what will happen if you have a bigger endeavor? Like I see basically coming back to the question, I see everything from 30 to hundreds, the biggest customer that we're still currently dealing with, it's a long-running thing of course, they have 800 applications that they're looking at. It's obviously a very large organization, but it's somewhere between a few and large, so there's no real thing. I would say the average is about 100, 150, something like that. They have more, but those are the ones in focus. So going back to this cycle that you're going through with these applications, so what you would typically do is harvest all that information into some kind of knowledge base, what we call typically a cookbook, because when I encounter this library, when I encounter this technology, when I encounter this setting, I can, after the third or fourth or fifth application, I can then just pull out the recipe because that problem has already been solved by someone else, of course, because I'm a developer in a different application department, for example, but I can pull out that knowledge, I can just apply it instead of reinventing the wheel. And that's what happens if you're doing this one application, then crickets, next application, crickets. If you don't harvest that and also if you don't have that team, that enabling team, that to a certain extent controls steers that whole endeavor and also on boards the developer teams onto the new technology. So that goes a little bit to the finding that the study has defined, aligned and trained the team. So basically, if you're asking a team that has never seen containers with migrating a monolith into a containerized world, you will have problems. So nothing that cannot be solved, but you need to identify, okay, so what's the maturity of the team, what are the processes around it? So just a simple example, modernizing something with a customer, but the customer has really, I call that process written, because even though they have the nicest technology now, they're still due to their process requirements and regulatory requirements and basically all very heavily siloed organization, they're basically, they're still just releasing qualitatively, because they can't. So you have to look at the bigger picture, but I'm digressing here. Yeah, I think it's consistently defunction came out with our modernization hub a couple years ago, focused on refactoring. And it became pretty clear that from a project perspective it was successful, but the front end of assessment and prioritization and kind of building the pipeline and getting all that tooling up front and all that analysis up front was a key requirement to create a kind of continuous assessment model. You're always assessing, you're always trying to flow applications in, so you have that set of best practices that we see a very consistent thing. And then we have an assessment version of the product and a modernization version, which allows them to create a much more consistent kind of a continuum around modernization. You're assessing, you're always modernizing, it is not just a project one-off basis. So I think that's the next phase that we're kind of pushing towards is, you know, moving towards a way you're always measuring your technique, that you're always trying to understand, you know, there's microservices that become macroservices that become, you know, monolithic services. And if you've begun to see that happen too, where you're, and you have very chunky services that aren't optimally defined that have been actually not, all the context of it has been plugged into it. And these are big services. You want to be able to have much more nimble services going forward. So all those things, I think, are part of the, where the, where the market's headed, where the industry's headed. But yeah, we have to get through all these modernization challenges first. So, and this is a question that is on Qvert. So this is the comment, and then they're asking to hear your thoughts on this. So the comment is, Qvert can be an interim state, and then there's a drawback of dependency on bare metal. What are your thoughts on that comment? Yeah, you're asking me or? Whoever wants to take it. Yeah, I can be you. This is just started. Yeah. So basically, and basically Bob said that already, and that that's what I see as well. So nothing can be as permanent as temporary solutions. So basically that that is a risk that is a risk you're facing with customers that would just say, okay, yeah, no, it runs on Kubernetes. Great. Next. And yeah, so that that that is a problem. It should always be clear for for modernization purposes. There are obviously other use cases where, where a Qvert totally makes sense to run VMs on Kubernetes in for for the foreseeable future. But when it comes to modernization, the goal is not to make your monolith run on Kubernetes. The goal is to modernize. And so this would be an interim step. However, that step makes it easier, makes the whole modernization process easier, because you're not facing, okay, you know, need to have like firewalls opened, specific, specific network routing, all these things, because you're basically on the same network. Now, you're on the same platform on the same network. Otherwise, you always have the, the problem that you're, that you're crossing boundaries of maybe also organization wise crossing boundaries, and you have to file tickets, et cetera, et cetera. So that just helps the process. And yes, nested virtualization is never a good thing. So that's, you have to, you have to run it on, on bare metal. Yes, it will, it's, it's a trade off of sorts. So if you're, if you're, let's say on, on VMware, and you only have VMware, just, just to name one, then that is probably not an option for you, because then setting up an extra bare metal, and there's no operations team that knows how to, how to maintain that bare metal. And that's probably not, not a good thing to do. And that's basically because, well, nested virtualization, well, you can play around with that. But that's nothing that should go into production, because there's, there could be so many problems between those virtualization layers that, and also, well, performance, you can probably tackle performance with more power, but still there's, there'd be dragons. So don't do it. And that is, that is a trade-off you have to make. Okay. And this is for, I believe both of you. What are examples of successful case studies using the strangler pattern for non-trivial containerized application? So something that's 50 to 100 containers? Yeah, I think most likely over that. Yeah, I'm sure Marcus had had a lot of case studies on that. We've got several on our side, Texas Apollo, Trend Micro, who've gone through this, and all of them kind of share that same set of patterns of, you know, complexity, but also a lot of risk and a lot of frustration to failed efforts in advance of where they came into this and then also use that strangler pattern to begin to move that into a successful use case. So some of those are available on our website. There's a cool product from AWS called Refactor Spaces too. That does some of the automatic strangler pattern with the networking components. And that's another area you can look at for the actual strangler effort of how you do that on top of AWS is called the AWS Refactor Spaces, part of the Migration Hub product too. So they have some use cases there around how you can, once you've done the modernization, how you use strangler pattern to begin to shut down one side and begin to enable another sign. And so, well, I have to be honest. I'm not really sure what customer names from a recent experience I'm allowed to mention. So I would have to just point you to, well, for example, V Functions website, Red Hat's website and there, well, the strangler pattern, it's not new. It has been around since I think 2004 or so. So that has been applied in many cases. So, well, modernization, every time you build something, even the greatest, latest and greatest most Chinese technology that you're building today will be considered legacy in five years. So the thing is, that's why you have to be continuous in these efforts and make sure whatever you do today will be technical debt also in five years. So this pattern has been around for quite a while and all you can do, and that's one of the reasons why people do these kinds of modernizations is if you have smaller components to manage, speak microservices or right-side services or whatever you want to call them. So smaller components that are independently deployable, easier to manage with defined boundaries tied to a specific business need. So that would make it easier and will make it easier in the future to tackle that technical debt that will be no doubt will be there in a couple of years. Okay, awesome. So we have kind of the opposite question being asked now. Are there any public case studies or public articles about modernization or failed modernizations or less than optimal ones? So anything that's seen as an anti-pattern that others can learn from? Do you guys know of any public references on that? Yeah, probably anonymized because I don't think a customer would like to be in the press, if you will, for a failed project. I would say that the survey provides that anonymous conclusion around why they're failing failures, set expectations, lack of a business plan, lack of intelligent tools. There's a lot of, I think, indications in the survey itself that one reason we want to do the survey is, you know, move from the anecdotal side of things to actually be in the measure why people are saying it fails and why they failed in the past and how they look to kind of succeed in the future. Okay, and then related to the study, Bob, do you have any details on the model of applications that the participants were using? Was it Java, Net? Yeah, so part of the selection criteria was they had Java and Java applications that they're looking to modernize. So that was a part of the process that we're getting into, we're not just going into environment where they're running already in microservices or, you know, etc. So we went into organizations that had applications of a certain size and in certain kind of groups of applications and began to then look at the demographics and the cohorts around the business leaders versus the application architects too within those groups. But in order to qualify, they had to have some, at least we use Java as the leading indicator. Typically we'll be fine if they have Java, they have some .NET. And typically there's some cobalt and some other stuff in there too. Yeah. Okay. And then I think this is related to one of the learnings from the study. So the common is a hidden learning seems to not be technology related to people. There is quote unquote required or structure changes. The DevOps slash SRE would seem to require this, but what are they missing? Yeah. Yeah. I mean, I'd say that there's the DevOps side of things you start looking at. I mean, the right DevOps technology and that kind of goes for all cloud native stuff around CICD and all the building out the pipelines and being able to do all the continuous delivery. Having that most organization, I began to move that into place. I think the harder issue is for application, existing application teams, many of which are monolithic in nature because they're built, there may take the model of the application to begin to migrate to something more of a topology around a domain ribbon microservices. And you have a team on each service. And I think that's the next step. You've got to have the DevOps and cloud native technology in place. Team topology is nice. That's a book we all swear by, right? Yeah. So that is everyone who has not read it. Just Google team topologies. So I have the blur kicking in here. So now I can see it. Matthew Skelton, manual pays team topologies. Just Google that will be one of the first hits. That is super helpful because I also said it's super important to look at the processes and at the team structures because, well, as you said, when you have a monolithic application, you typically have a monolithic team. And you will want to, when you focus on smaller services that serve a specific, that are in a specific business domain and serve a specific purpose, you will, you want to organize your team around that. And on the other hand, also, what you want to do is you want to, you want to enable your organization. So we don't say, we don't say like modernization means you have to restructure the whole company. No, that's not the case, but you have to establish some good, well, hence the name team topologies. Well, who is reporting to whom? Who is doing what? Who is helping whom? And who is organized around value streams, meaning who is providing value, building an application that serves a purpose? And who is like in an organizational, sorry, in a vertical approach, who is supporting multiple teams onboarding and building the feedback loop between developers, for example, developers and the platform team that is now managing the Kubernetes platform. So what features do the developers as platform users, what do they need to achieve those tying back to the beginning, those target outcomes? So it's all interconnected, as you can see, but this is definitely also, well, summertime is coming. So if you don't have anything to read on the beach, this is the one. Yeah, agreed. All right, guys. So last question, then we can wrap it up. We're at the hour mark. The question is, is there a recommended tool stack from assessment to plan into actual implementation, like reading code analysis and code converters, which v function and Red Hat use or recommend? So I'm sure you both have answers to this. Bob, you can go ahead first. Yeah, well, I mean, this is right in the heart of what v function does in terms of automated assessment, technical data analysis for prioritization, and then a modernization hub where we actually will do the refactoring and dependency analysis. And so this is kind of the heart of what we do. We integrate with OpenShift and a bunch of other kind of platforms in terms of target cloud-native environments. And so that's a we work well with the Red Hat team in that respect. And we're really more focused on getting into the application itself, understanding dependencies, beginning to untangle those and helping the architect refactor and build those new microservices. So we recommend that. And then as a Friday of other kind of tools that go around that, that I think the OpenShift community kind of fills in. Speaking of community, since this is the conveyor community call, there's obviously also some tools in the conveyor community. However, probably looking at things from a different angle. So what the v function tool set does is much more sophisticated and in-depth than than the conveyor tool set, because it looks at things from a different angle. So and there are obviously also some overlaps. And I would think, well, I typically work with mostly with conveyor, because those are also the upstream versions of the Red Hat products. But I would expect beyond v function. Well, I've had the pleasure, Bob, to work with you before and present that internally at Red Hat. But the thing is, so I know v function and there's probably others as well. So there going back to the question, there is no recommended tool stack. There's nothing like do it this way and everything will be good. It also depends on, let's say I get from v function very sophisticated. I get the whole dependency chain untangled. I know where my transaction boundaries are. So basically all the work is carved out for me, but I don't have anyone who actually knows how to move this into a container. So you have to look at the bigger picture. So I just have to quote it because I do that every time. A fool with a tool is still a fool. So the tool might be great, but you have to look at the bigger picture. Awesome. Thank you guys. I just had one last question. This just came in, based on engagements, what is the percent of customers that are comfortable with managing and operating Kubernetes clusters? Sorry, how many customers are coming into asking Red Hat to operate? Sorry, I didn't get that fully. That question. So just based on the interactions you've had, what is the percent of customers that are comfortable with managing and operating Kubernetes clusters? All right. Okay. So miss the middle part. And that's on their own? Yeah, on on on prem. So we see the shift. We see the shift currently of customers moving on Kubernetes in the cloud. For example, well, in our case, obviously managed open shift on Azure on AWS, for example. So I as a customer don't have to worry about managing my clusters, etc. I'm just consuming. I'm just consuming all the goodness and I don't have to have people who are actually doing that. I can basically free up those people. However, obviously, there's a cost involved. So and other customers, mostly in the in the highly regulated environments such as banking, insurance, medical services, we see those trying to well consolidate their data centers. But for regulatory purposes, they can't move everything highly confident data to the cloud. So it's however, for my experience, I'm not a market researcher. But for my personal experience, what I see customers are more and more shifting what they can to the cloud. So so Red Hat Red Hat is doing more and more of these hybrid cloud projects also where these regulatory customer regulatory inflicted customers, they're keeping the core data in house because they have to. But that doesn't mean that they don't have workloads that can well work very well on on on a managed and hosted Kubernetes. So so this hybrid approach is also we're also seeing more and more of that because then you can basically you can manage it as one target appropriately and say, okay, these workloads will go out there and these have to stay in house along with their associated data, of course. And so there is no there is a trend but no 78% are doing this. And Bob, do you have any input or anything? Yeah, on the on the Kubernetes, I'm not what I would say is that with the cloud provider services are getting are very mature, the open ship services around Kubernetes. I think the management and operation in tooling around that has gotten very mature and kind of much more predictable. There's still a training issue, there's still like a lack of a skill personnel. So it's hard to put a number on it. But I think the people who are looking to get confidence that want to get comfortable with managing it, using a service to start with a managed service. And then working your way into maybe something you would do on your own will be something will be the trend to go to. But the managed services are very predictable. And I see we see that in most cases, somewhere in an organization, there's a there's a team that feels comfortable with it. I just wouldn't say across an entire enterprise organization, there's a broad level of comfort, but there's pockets within almost every organization where there's the expertise that's developing or developed. So awesome. Well, guys, let's go ahead and close this out. Do any of you have any closing thoughts you want to share with the audience and maybe how they can reach you, if they have any questions or anything they should check out? Yeah, well, I just want to say thank you all for letting us share our perspectives on application modernization. The challenge is I'm Bob at Defunctions, you know, Bob Cullinette on Twitter also, so you can track me down there. But Bob at Defunctions, you can email, have any questions and look forward to seeing all out there. Thank you very much. Thank you, Bob. Marcus, any closing remarks? Well, yeah, you can reach me. That's a little more complicated. I should have thought about that, but creating an alias. But it's M. Nagel. So Marcus Nagel, so first letter, first name M. Nagel at Red Hat. So you can reach me also anytime if there's questions. Or just ping your nearest Red Header. So there's works. Thanks for watching and listening. And as you can see, I can fill whole evenings. I can blow parties with just talking about application modernization. So thanks for bearing with me. Thanks, guys. And thanks, everyone. Until next time. Bye. Thank you all.