 So first, we're going to do some introductions. My name is Christopher Newland. I am a cloud architect with Red Hat. Prior to that, I was just a general architect in our services. I've been working in the container space for about 10 years now, starting with OpenVZ, with the US Department of Energy. After that, I've been moving along from different microservices to now focusing more on modernization and migration. So I'm also an ambassador of the conveyor community. Hello, good afternoon, everyone. I'm Valentina. I'm from Red Hat. I'm a principal architect. I focus on adoption and application development. It's my pleasure to be here today. My name is Jared Burke. I'm a managing architect with Red Hat. I've been here with 12 years based out of Austin, Texas. I focus on all things containers and application migrations. Hi, I'm James Bench, Vice President of our Digital Practice and Technology Consulting Services. We do a lot of digital transformation work, agile transformation, low code, no code, and then full stack software engineering in both the .NET and Java platforms. All right, so a little bit about the community that is sponsoring us. So we're here representing conveyor. Conveyor is a CNCF community and project. So there is a tool called conveyor. You may have heard some of the other tools. If you've heard things like Crane and Tackle, Move to Cube, these were all projects that were under the conveyor community umbrella. I'm happy to announce today that we've consolidated that. So our new website, conveyor.io, the big new version of that just went out last week. And along with that, we are consolidating the projects down to one simply called conveyor. So if you're familiar with the Tackle tool, that has been rebranded. And then some of the things around the conveyor community have been either moved inside of that single tool or have been discontinued. So we're putting all of our eggs in one basket, especially from what we're hearing is the most beneficial to this particular community. So definitely check out conveyor.io for all of the updates there. And this talk specifically is going to be really a fireside chat on just migrations. Talk about our experiences. All of us have been doing this for a long time. Some ways that the conveyor tool can be incorporated in that. And a lot of just lessons learned from large enterprise migrations from a variety of different sources. So this could be containers moving from on-prem to into the cloud, or it could be going from a mainframe application all the way to being cloud ready. So a variety of different experiences and things that we'll be talking about today. So we did ask our community some questions before coming. So the way this talk is going to work is that I have some predefined questions that have been sent to us. And we're going to spend about half to three fourths of the time going over those questions. But then we're going to open it up to the audience. So if you have a question, I'll let you know. We'll be starting Q&A a little bit earlier, probably in some of the other talks, just to give you the audience some opportunities to ask our panelists some questions. But I'm going to start with Valentina. What are some of the biggest challenges enterprises face when taking on a cloud native migration? That's a great question. So the first thing that I have seen when working with customers are when they focus on modernization as a only one-time thing, instead of seeing it as a journey. So when you embrace modernization as a journey, you start looking at different things and not only technology. You look at people, processes, and technology. When looking at people, you will look at, for example, do I have the right skills? Do I need to train my people? And with processes, do I have the right methodologies? How would all those fit together to create in a plan? The second thing that I have seen that is critically important is understanding why we are doing this. Why containers are important? What is the value for my business? So we have seen that containers brings a lot of value from increasing security, reliability, high availability, also accelerating your software development lifecycle. How all those values connect into your business? Can a story that really aligns to your mission and to your vision and communicating that back into your company at all levels? When you speak at a company and everyone really gets the value, you not only get the alignment, but also the commitment, the inspiration, the motivation behind it. I have seen that sometimes customers see this as a priority, right? When you focus, when you're working with feature development, you are always competing with priorities. But when customers understand the value and they have this articulated to all the different levels, that is just a different game on the modernization. It's just competing completely different. And they are able to move forward when those prioritizations are having problems. The other thing that is very important is when you create the why, you really create a plan that connects to it and look to create metrics that can measure back into the why. So if you're saying, well, for me it's important to reduce cost. So how you can measure back that you are really getting that value from your modernization. And that's when you really get successful. Absolutely. Where are some areas that people can start? So let's say that someone is in the planning stages very early on of enterprise migration. What are some of the considerations that you should be taking when they're starting this journey? Yeah, absolutely. So that's a great question again. So we were talking as a team again, the importance of having, once you have that vision articulated to everyone, create some working groups. So ensuring that everyone on the room, whoever needs to be involved from developers to platform engineers and devops, are aligned and I'm working on early stages. But then you may wondering like, how should I start? Like where to start? That's what everyone is asking. And the important thing is creating, we call it a pilot project. So you can create a pilot project to start measuring what you want to obtain. What is important for your company now to start working on any modernization? Is it sometimes customers are concerned about the time that it will take me to modernize? How much time it will take me? So we take an application that maybe has a lot of complexity. Maybe you want to prove the business that this has value. So you work on a line of business and choose an application that is important and critical for them. So depends on your criteria and what you want to prove, you will select one or a set of applications to measure back. This will help you not only to understand reduced complexity, reduce risk, provide value, but also how you can plan back into your whole modernization journey. So create after that, create, don't try to do everything at once. Create a plan with faces. And that will help you to see where should I start. Should I start with a more complex one that I already resolved? Looking at similar archetypes, like I have Java applications and maybe I want to focus on. Or should I want to work with this line of business that I know modernization is very important for them? The other thing that is very important, Conveyor has a way that you can set up all of these. But the other thing that developers are wondering is how do I know if my application is ready to move into containers? And this is what Conveyor has a really good way to create different paths. It depends on where you are, to show you where do you want to go, and how much those changes do you need to do in your Java application. So Conveyor is a really great way I have been using with customers. It saves a lot of time, it provides amazing features. Yes, I think we are in time. So Chris, I will ask you, you've been working a lot with customers as well. What are the non-technical challenges that you have seen when working with them? I think going off some of the conversations and give some examples of some of the things that you were talking about, especially who is in the room at the beginning? Do we have the right people on day one? Usually what I find the answer is no. When we ask different organizations about their migration efforts, they'll usually bring in the networking guy, maybe an app dev guy, and then someone maybe from the security team. It takes a lot more people usually. A lot of times you're not thinking of all your stakeholders. There might be an organization that isn't directly involved, but may have direct impact on your migration. The biggest example I can give, especially in a lot of industries, there's some types of policies that are driving certain restrictions. The things that come to example, healthcare, government, finance, all these have some type of governing body that has certain policies that you're needing to meet to effectively drive security and other things within your organization. A lot of times these things aren't known, especially if you're running on-prem and you're going into the cloud. A lot of times when you're moving into the cloud, you're having to take more things into consideration. Geography becomes a very big issue. I know for me when I worked in the energy sector, we've had things all on-prem within the United States. Well, when we were moving to the cloud, there was times where we were moving things to Singapore or even Russia or China, and we had to be very careful. In healthcare in the United States, we have HIPAA, and that's the governing body over how certain information is shared. So PKI, personal information, that becomes a big key. And a lot of times there's people within your organization who manage these policies that you may not even be aware of. I always recommend to try to hunt those people down because more often I see these type of things derailing migrations for three months, six months, a year, or sometimes even putting projects completely on hold. So these are some of the things to be being considering. With that, I have a question for Sheridan. It really just comes right into what I was just talking about. Who and what within my organization should be involved early on when planning a large-scale enterprise migration? That's a really important question, Chris. And to answer that, I think you need to think about who some of those folks are, right? And when you are planning those, we have some of those people are things like your business leaders, unit leads, application owners, architects, operations and support, cloud native teams, specific platform teams, such as your computer infrastructure teams, your storage teams, your networking teams, security. Notice there's a lot of folks that are involved in that, right? And it's not just the people that you need to have involved early on to be successful in large-scale migrations. You also need to think about the what those people can bring to the table, right? Thinking about what the analysis and assessment phase is going to be like, understanding those data requirements, what those people can bring to the table in order to be able to connect to the why, right? Understanding what those business requirements and business needs really are. What is that data from the application perspective, right? So when we start to think about that, what these people can bring to the table, we're talking about what's the general application? What does it actually do? What about the application architecture? You're gonna need to know how it operates, right? What is the, it's operating life cycle. How does it perform its performance characteristics? Does it have a, what's it all for a life cycle, right? What type of life cycle does it have? Is it real, how resilient does it mean? Is it a single app or is it high availability deployed in multiple regions? Security and compliance are also important and databases and dependencies, right? And you can see there's a lot of areas of data that you have to go get with a lot of different people. In order to be able to get together that data, leveraging a tool like Conveyor can help you get away from spreadsheets doing, having to organize that data, being able to collect it in a very organized, methodical way and then take the data that you've collected from the people and the requirements and be able to start to do the analysis and assessment phase and plan that migration so that you can begin to continually understand what the various priorities are, think of the Rs and determine which of your application portfolio needs to actually be migrated, can be retired or re-platformed or others. Nice. Thank you, Jared. So, James, I know you've been doing this a very long time. You've been involved with different federal agencies in the US and things in commercial space. What are some of the lessons learned that you found after you've done these types of large scale migrations that you wish you had known beforehand or different approaches that you have taken? Yeah, there are things that it's really easy to underestimate. So when you're thinking about a large migration and, again, think big, think an entire critical business function that has departments tied to it, nearly it's so important to the enterprise that it basically has its own IT, dedicated IT infrastructure associated to it, IT staff is dedicated to it. So think of something that is that tightly woven and core. Some of the biggest challenge that was easy to underestimate was how much of a culture change that it actually takes from an IT governance perspective. So when you're doing this transition, let's say, into cloud-native Kubernetes and Docker, you have to introduce so much more kind of technology that is not in the approved software list. And normally there is a process, if you're in large enterprise IT, where security has to go through, approve it, scan it, and they do that process for each and every product you're needing to introduce to actually get this launched. So at the very beginning, you have to really take stock of the inventory that you're having, and you need to make sure that you work with them to kind of change how they perceive what does secure software actually look like. And knowing that if you're building now into a DevSecOps capability, that all of the scanning layers that you're doing, all of that will actually provide what they're really needing is to know that is there something vulnerable that you're introducing into the ecosystem. And I think if you can help convey that early on, very early on, that'll help kind of overcome kind of one of the key roadblocks is really are you on the approved software list? Classic governance processes around release management. When you're transforming into this type of capability, you're able to deploy much more frequently. You're able to remediate things faster. You're able to take production issues and recover them quickly because you have this now a new capability to deploy. But if you have formalized, kind of classic enterprise IT governance processes around deployments, that process really slows down. And a lot of it ends up being again, education early on, where you have to tell them or show them that actually security is completely baited into our entire build process, our deployment process. There's checks and balances. We can measure the hash of what we built, the image that we built and actually what made it into production. All of those controls are now baked in completely. And so again, what was the point of having all of those controls in the first place was to ensure that that was happening. But now it's completely baked into the entire lifecycle. And so now that paradigm has to change and it comes with a lot of education. So underestimated that, that hurt, that's hurt before. So we tackle that kind of early on. And then the other one is the development team. If the team has been working on that kind of monolithic application for a long period of time, when you're moving into this entire paradigm, agile tends to have to kind of come along with it. And so transitioning them to kind of an agile, methodology and approach, tying that agile methodology into your deployment process, into your build process. All of that takes a lot of culture change. And so don't underestimate kind of needing to kind of stack that upfront when you're doing the planning process. Another kind of key lesson learned was really around security. 100% bring them in, bring your security officer in as early as possible. So the security office has to essentially manage the enterprise security kind of across the board. And so they're not gonna be the experts on what is Kubernetes, what is DevSecOps, how are all these security scanning layers work? Maybe I'm just doing one scanning tool on the OS layer, but I'm not really understanding like all the different layers now that can be scanned. And I can provide a security footprint at any moment of time. So because they don't understand all of that or the number of ports that had to be open, which is far less than what it was before, just really all of that education, we end up having to do a lot of training early on and the security officers that are gonna do the assessments and really help teach them what does it look like to have a scaling infrastructure? What does it mean to have this kind of capability? So having them on almost on day one, through the entire migration has been critical to kind of like some key successes. And then the kind of the last one I'll highlight is if you've worked in a large enterprise application for a long period of time, you'll have your pet peeves, you'll have your tech debt that you know you've been sitting on for a long time, and you'll want to tackle all of that tech debt as part of the migration. That is a very slippery slope that can actually lead you into some trouble. What you really need to make sure is that you have functional parity between your current application and then your migrated version of the application. Be very particular about which tech that you're gonna tackle, which one you're really gonna have to refactor or not refactor, be mindful of like what do you really need to do to actually make it into the new paradigm? Once you're there, you will have a new development capability, a faster way to resolve, and then you can tackle the functional instead of the core ones that you had to tackle to move it into the new environment. Nice. Thank you, James. So we'll move over to our Q and A here in a second, but I wanna do some summarizing what we've been hearing. Two major takeaways, I think, and something I always tell my clients on day one when we're talking about large enterprise migrations like this is that migrations are usually more of a people problem than a technology problem. So I'll repeat that. Migrations are more of a people problem than a technology problem. It's about identifying the people who are in the room to begin with day one and identifying the people who are not in the room day one who need to be there. It's very important to have organizational buy-in throughout your entire organization, even if you think a business unit doesn't have anything to do with your migration, they should at least be aware because there might be some things that you're not aware of, how they have some stake in what your operations are doing. Another big thing is just try to do the most analysis you can upfront. The more information you have about your applications and your current platform and the platform you're moving into, the more you're gonna be able to pivot and make critical decisions along your migration path. But yeah, no, those are all great things. I think that we're showing more and more from your experiences that this really does end up being very much a people problem a lot of times, who's involved upfront. So I am open for questions from the audience. Does anyone have any questions for us? And I'll just go ahead and repeat. So if you could speak up and I can just repeat it back for the camera. Okay, we do have a couple of questions that were submitted in. So I am going to take a look at the next one there. Jared, I have one for you. So there's a trend with more and more migrations going into managed services for Kubernetes. So things like EKS, AKS, Red Hats, Rosa. What are some of the complexities you're seeing in these types of migrations from maybe the traditional on-prem migrations we've been seeing prior? Well, a lot of that gets to where you're starting from. But at the end of the day, a lot of the managed services help actually kind of get you started earlier because you don't have to worry about as much of the infrastructure, getting it up and running faster. Again, it comes back down to having, knowing your why, being able to understand your reasoning, learning and adapting from that and improving it on those. As you on-prem, you start to have typically more security requirements. You happen to things that are not always as organized, right? Things we don't always have the right people. You don't always have the right applications. And so what ends up happening on-prem, you tend to have more challenges. Especially if you're going from on-prem to the cloud, it's easier to go from on the cloud back to on-prem. You tend to have more security controls that you can put in place on-prem than you do in the cloud. So that's really where some of your major challenges come in is that security, making sure that your applications can run in the more less secure environment than typically your enterprise environments. Using tools such as Conveyor can help you understand your applications, what complexities that they have in them, the dependencies, security challenges, and what changes you may need to make in order to be able to deploy in your target environment, such as Reso or ARO. Thank you, Jared. Just doing a time check. How much time do we have? Okay. Thank you. We have a question right here. Can you come up and then I'll repeat the question? Actually, I'll just give you the microphone. You're coming all the way up. Thank you. Yeah, this might be easier. Am I loud enough? Right, so you mentioned that it's not as much a technology problem as it is an information problem. So, sorry, as it is a people problem. So by that, is it a question of distributing the information, getting the right information to right people, or is it a question of getting people to buy in and basically persuading them to make this decision instead of that decision? That's a great question. And to answer it, it is both. The one that I see more often is an information issue. So usually there's been some organizational buy-in and it could be that someone is seeing an email or heard at a meeting, so like a director level or manager level that they knew this migration was coming. So from there, there's buy-in, they're not saying no, let's not do this. But then from an information standpoint, it's more that that person doesn't know how maybe their business unit interfaces with the operations of your infrastructure team or your DevOps team. And that's usually something that's known by like a tech lead or a business analyst who from this other business unit who thinks it's not involved, they're not having the right conversations or they're having the right information to be able to say, hey, actually, we have some stake in this. Maybe there's a legacy application or there's a policy or we have an old application that ties back to this mainframe that you're retiring. It's things like that which I usually see tripping things up. And then like I gave there at the beginning it's a policy issue too. Maybe there's someone that's making policies like in healthcare and you think your team is good because you've checked off all these things on a box, maybe a form or a document where maybe you don't know that things are changing in two months from the policy person and that person then comes in and says, hey, wait, this is all changing January 1st. We gotta pull the brakes. From a buy-in perspective, this one's a little bit more rare, but I have seen this often where a particular business unit has decided to make a migration and they have not actually gotten buy-in from other groups. This is usually like a networking group or maybe a storage group who are unaware of the migration but are a critical part of the migration. These are the types of things if I'm seeing day one, I'm usually like, we need to stop this meeting right now. Tomorrow you are going to bring your storage person, your networking person, your security person and we are going to have a much more in-depth conversation and this needs to be going up to your CTO, to your even potentially your CEO about trying to get more buy-in because right now you're on a path of destruction. This is not going to work out. And that is a conversation unfortunately I have to have with many clients. Does that answer your question? Are we at time? Five minutes? Okay. One of the other questions was, oh, right here. Hello, thanks for losing it. So I have a question about failed migrations. So you've been doing it a long time. Have you experienced any learnings from that? I have not failed the migration, so that's why I'm up here. But I'm usually picking up after usually multiple attempts of failed migrations where they tend to, where they have fallen over, which is where you end up picking up from, is a little bit of the question that was earlier asked, is when you're doing this effort, there is a lot of gates that end up needing to be kind of passed before you can actually end up in production, in full production. Security ends up being one of those kind of gates where if you don't really give them the education and get their kind of understanding about how that is on really at the early stages, that from my experience is usually the place that projects get killed. They won't actually engage security, they'll go ahead and do the implementation technically correct, technically built the right thing, and then as they go for the security assessment to actually be authorized to go in a production environment, they get stomped down, and then they get delayed for months on end, trying to then catch up and educate security on how to do it, what does it mean that it's secure? Where is all the logs being captured and where does that get sent? How do I manage my CVs? Oh, we do images now? What is that? Getting them in early, so security ends up usually being the area that gets stuck. The other area that a project can fail, and usually they fail because you run out of time of waiting, so you'll build the solution, it technically probably works, but you won't get enough approvals, you actually get it out the door, and then time will pass and then funding dries up, interest dries up and the project ends up falling over. The other one was the IT governance component, making sure that you get all that approved software in early, many of my clients are full-on enterprise organizations, it could take three months to get one new piece of software introduced in the enterprise. And in these types of things, when you're introducing this much new stuff, you're talking dozens, dozens and dozens of new software that you'd have to do that you typically would have to, each one would take three months. So making sure you group that together, you're doing that early on. So you're just getting ahead of these major time killers that will pretty much strangle out a project and have it fail. Yeah, I want to add as well, that's a great answer. The other problem that we have seen is scalability. So you need to look at scalability from every point. Whatever you are now, how you can scale even in the infrastructure, do I have enough infrastructure to accommodate all the workloads that I'm expecting? How I can manage that multi-cluster strategy or hybrid cloud strategy? And the other problem that we have seen is in terms of developers and DevOps, sometimes the companies start not with the right tooling or the right approach or the right templates, and they ended up spending a lot of time trying to recreate things that the industry have solved already. So if you are just getting started, I guess you were into the booths and hear about what's going on there. So learn about what the industry is doing and then try to recreate something that someone already solved and use best practices and think, will this be scaling in my company? And having the right methods, it will help a lot. We have seen from customers it's reaching out because they have those problems. I don't know how I can move forward because I don't have templates to, I don't know, deploy my applications or these templates are broken or doesn't work or where I even can find the documentation or how I can be trained. So all that's all the factors that we have seen really slowing down and breaking on the motivation on the people. So wanted to add that. Thank you. Yes, that was a great question. Thank you. I think we're coming up to time. So I just appreciate all of you being here. I do ask that if you can, please give us a review on our talk. This data is very, very important. It helps us know how to improve as speakers, but it also helps us know what CNCF is looking for when we're giving these types of talks for the conveyor community. So please, please, this is really important to us. This type of feedback is a big impact on how we do our talks to come. So thank you for being here. I do appreciate the conveyor community for sending us as well and have safe journeys home. Thank you. Thank you.