 So, hello everyone, welcome to DevNation, embracing cloud native application modernization. My name is Daniel Brunzinger and I'll be your moderator for this slot. So with me, I have Christopher Newland, who's cloud success architect and also ambassador for the conveyor project. And you know, we all know those classic applications that have been around for ages. And notice how I'm saying classic applications, not legacy applications because I know a lot of labor and love went into these applications, but you know, we all know that after some time they become hard to maintain, hard to scale to new requirements. So I think I believe Christopher will share some insights and some case studies, how to take those classic applications to the next level, especially on Kubernetes. But before we start into that little housekeeping, so I will be watching the chat. So if you have any questions, you know, just drop them in the chat. I'll try to answer them. And if I can't, we'll have some time at the end for Q&A. So with that, I think I will hand it over to Christopher and enjoy the talk. Thank you. Thank you, Daniel. Just a heads up. I'm here in the American Midwest where we're having all smoke issues. So I may be taking a few deep breaths throughout all this and I have some sudden pauses. So I'm very sorry for that. I'm also probably going to go off camera because I'm really offy right now with all the smoke and allergies. So I do appreciate you all being here. If I do, if I am not able to cover all the content, I do have some of their content that I can share if we miss a few of the key points. So again, thank you for being here and I will get started. So today I'll be talking about embracing cloud native applications with also a case study. For those of you who are not aware, I am part of the conveyor community. Conveyor is a CNCF community around the idea of cloud native migrations and the assessment of applications going into different types of cloud native environments. So I'll be talking a little bit about conveyor today and also just some general things to do when you are preparing for a large enterprise cloud native migration. So a little bit about myself. I am a cloud success architect with Red Hat. I specialize mainly in large scale container migrations. So usually migrations that take anywhere from six months to two years, usually involving at minimum about four or 500 applications. At most, we've seen even thousands going over the course of two, three years. So I've been doing this for quite some time. My involvement in container technology goes back to the Department of Energy here in the US. Back with the Titan supercomputer here, whereas containerizing applications for different simulations. And just a little bit about me, I have a passion for IoT. I really like Internet of Things, small devices that can improve my life. I enjoy doing things like 3D printing, playing with microcontrollers, different sensors. So one of my passions outside of Red Hat. So I'm just going to start with the top two mistakes I see during migrations. The first one is usually not getting organizational buy-in. So making sure your whole organization is bought into a large scale migration. Everyone knows what's happening, all the different parties. So if you have a compliance team, different security teams, different application teams, really the gambit there. So making sure your whole company knows about this migration and what it entails. The second thing is just not spending enough time assessing your applications. A lot of times I find people are just wanting to start moving things over as quickly as possible. This is one of the worst things you can do. This is where a lot of mistakes happen where things like compliance or security or even just migration trends on how you can group up your migrations for best possible type of success. So make sure that these are the two main points for today's talk that I'll be covering. So I'm going to talk about a case study for this example. I'm just going to call this energy cow for just legal reasons. I'm going to be careful about putting this company's name on the slide deck. But I believe the moderator will post an article for you guys to look at that goes over this and what the company is and what it entailed from an organizational standpoint. But overall, this is a Fortune 50 company. One of the largest energy companies in the world. It has over 60,000 employees, a billion dollar IT. The biggest thing I want to focus on here, though, is just the large IT operations overseas. So they have really groups all and really just about every continent in the world. And they have IT groups throughout the world as well. So this is where a lot of the complexity of this migration came into play. And also where compliance plays a huge role. So we were not just dealing with compliance in the US. But we were dealing with compliance globally, different things in the European Union, even things involving Russia and things in Asia. So these, especially if you are a large international company, make sure that you're not just thinking about your local compliance standards. But you're also thinking about your international compliance standards to go over some of the challenges that we were facing. This company needed to be off their on-prem Kubernetes platform within one year. There were a lot of end-of-life issues with going past that year with both financially and from a support side. We were migrating this company over to being cloud native. So everything prior to this was on-prem. And they were moving into our Azure Red Hat OpenShift, otherwise known as ARL. So a lot of these applications, this was the first time that they'd ever been within a cloud environment. And really, that's where a lot of the challenges were taking place. So from a compliance standpoint, like I said before, we were dealing with a lot of international compliance standards, both from the EU and even things involving Russia at the time. The Ukraine war had just about halfway through our migration had just started kicking off. So there were even some things that we had to review from that standpoint. And then all these data centers that we're hosting were throughout the whole world. They were not just in the US, they were also in Asia and Europe as well. And one of our main challenges, too, was getting buy-in from application teams. These application teams were global. So really at any time of the day, there was a team that was working on this migration. It teams in Venezuela, Brazil, US, Europe, and Asia. So give you an idea of just the global scope of this. And then just, like I said, the need to modernize applications to be cloud native. So I'll talk a little bit about the organizational buy-in, some tips for our viewers. Meet early and often. This was something that was very successful with this migration. Because we had buy-in through the organization, we were able to meet with the stakeholders regularly. We had daily stand-ups with the main team platform team that was running this. And then we also had other meetings with different project managers throughout the company. And also different people internationally. So we would have potentially two to three meetings a day. Now, I know people get hesitant of meetings. For us, we kept these short. They were usually about 15-minute stand-ups. But through this, we were able to get information flowing globally about what was going on with this migration. And make sure that things were getting passed off when they needed to get passed off. One of the biggest tips I always give is, you know, ask who is not in the room. Especially when you're meeting early on for a migration. Ask the questions of, okay, we have these people in the room right now. But is there someone who needs to be here? Is there someone in a compliance office? Is there someone in security? Is there someone in networking? Is there someone in maybe even policy? Always ask who is not in the room. And make this an open question, because you may not know. And maybe someone else in the room who thinks, oh, hey, yeah, so-and-so from security needs to be here. So always, always ask who is not in the room. I know I've mentioned compliance a few times, but I do think it's probably the number one thing that derails migrations. So always be checking your compliance standards for your entire global operations. I cannot stress this one enough. This is the one that I see has been a showstopper for more migrations that I have done than really anything else. Especially when it's going into cloud native. Enable your application teams. Make sure that you're meeting with them early. Let them know key dates. Let them know what they own. And what type of technologies they'll be using in the migration process. And what I always like to do on top of this is to have some type of social contract. When meeting those application teams, let them know what their responsibilities are. And then also what the communication looks like. And that communication needs to involve all the parties who will be involved in your migration assessment. So my second tip is spend as much time as you need in the assessment phase. So this is analyzing applications, seeing how cloud native ready they are. Really understanding all of the dependencies that go into play here. And this is where a tool like conveyor is top notch. I'm not going to dive too much into conveyor and its functionalities. But the tool, especially if you're using Java applications, can do an assessment of your applications. Some of it is through just a questionnaire, but some of it also is automated. Where you just point to your repository and it will go and actually look at all the critical things that it can find about. That need to be addressed before your application can become cloud native. And it assesses it based off of criticality. Is this a minor issue or is this potentially a showstopper? I cannot stress enough how important an assessment phase is for your migrations. Here we have the assessment phase. This is from conveyor. This is our five step process to migrations. After you've gone through the assessment and the prep phase. So for me, really the first three there are all part of your assessment and prep. This is before you actually even start migrating applications. You can see that that's the majority of the time that we have actually allocated for this type of migration. And the pilot then is just making sure that you've proved out what you've assessed in a small scale. And then your main migration is just scaling that out. You know, if you've done all the preparation, then usually what we find is that 90% of your migration is going to go smoothly from there. Just from that assessment, we're going to talk a little bit about the bucket approach. So some of you may have heard this in an IBM lingo, they call this waves. Other people call it buckets. Really, it's the same thing, but it's really just how do you organize your applications for migrations? As I said, focusing on that analysis up front. But then there's also making sure to logically group your applications together to speed up the migration process. And I'll show an example of this. So the three areas that you can do here to really drive this kind of success when you're grouping up your migrations, either for what we call a wave or for a bucket, is finding common patterns. So this would be, do you have a set of applications that are Java? Are they Jboss? Are they stateless? Are they microservices? You'll find when you start doing these large scale migrations that these buckets are actually just going to naturally form. The earlier that you can identify this, the more that you can set up what we call a migration factory. And that is, don't reinvent the wheel. Once you've solved the pattern for one, make sure that your organization knows these patterns. So if one team has solved the issue with one Java application, you're going to find that pretty much all of your application teams are going to face the same issue. So make sure that you have a common FAQ or migration cheat sheet in a way somewhere where the main people executing migration can go and retrieve lessons learned from your migrations. And then grouping those up where applications are the most alike is where you'll just find that you're just breezing through these migrations. And like I said, what I found is that usually like 90% of these meet these patterns, and then you'll find your snowflakes towards the end where a little bit more additional effort needs to be put through. But there's also the common domain as well. So applications owned by the same team is one way to also group these together as well, especially if you only have a few large application teams and application verticals. You may find naturally that that may end up being one migration wave. And then within that, you would break it up by different common patterns. Now back to the case study. Using these principles I talked about today, we were able to complete this migration within one year. So we did reach that one year goal. During this time, we were also adding greenfield applications to the cloud. This is where a tool like conveyor came really in handy because we were able to assess those applications to see how cloud native ready they were, both from an assessment. Both from an administrative assessment standpoint. So are, are there any compliance concerns? Are there any data gravity concerns to also a technical assessment of the actual application and it's actual code where we were able to actually identify quite a few risks about moving it into a cloud native environment. So through this process, we were also able to help this company start some of their modernization into being cloud native. So pulling some of the user resources and then also helping their applications become more. Really allowing it to become more cloud native through things like elasticity and these were things that they had obviously on on-prem with Kubernetes, but they had a lot more, a lot more functionality with the cloud native that they're able to pull from. So this cloud native journey with them is still going. As I tell people it's always baby steps, especially when you're dealing with an enterprise company. A lot of times the best thing you can do is just get those applications into the cloud after, after your assessment, make sure that you've dealt with all the major risks. But then after that, it's a slow iterative process. I'm getting these applications to be more and more what we would call truly cloud native. Through all this, this company was able to sunset the majority of their on-prem data centers that were hosting these Kubernetes instances. And one thing I really want to highlight here, and this is, this is something a lot of people don't figure into their migration process. Migrations are a great way to do housekeeping. And almost every migration that I've led over the last 12 years has seen a major cost benefit with just being able to retire things like zombie applications or things that are just basically that are running, but no one has ownership over it. And it's not actually doing anything productive for the company. This company in particular, I can't give an exact percentage, but it was significant. It was significant enough that the amount of applications moved over and the cost consumption forecasting had to be brought down significantly based off of these retired applications. So just know that an added benefit of these types of migrations is this type of ability to retire applications that people have lost track of. Alright, that is actually it. This was a quick lightning talk. I do have some additional resources that the moderator will share with you about some of these subjects. I'm sorry that this one was a little more brief. I'm dealing with some breathing issues with all the smoke and fires here in the US. But thank you again for being here and do reach out if you have any questions either on here or always feel free to reach out to me on LinkedIn if you have some additional questions. Thank you.