Speaker: Bahman Nikkhahan
This session is from NDC Sydney 2020
Maintaining a legacy application sometimes could be cumbersome and costly. Hosting upgrade could be one step towards modernizing an app and helping future improvements of legacy products. This talk is a case study about a legacy application which has gone through a lot of transformation throughout 15 years of development. It has many components that are dependent of IIS and Windows. The application had around 200 installations in separate Virtual Machine and on-premise infrastructure for individual clients. The main purpose of modernizing its hosting was to reduce maintenance efforts and costs. Azure Kubernetes Services with Windows containers and Azure SQL Server have been chosen for the target hosting platforms. In this talk I will take you through why we chose these hosting options, how did we implement our solution, challenges that we experienced in this journey and what are the lessons learned.
Alright. Hello everyone. My name is Baman and similar to Emily. This is my first conference talk. I'm going to talk about modernizing legacy app using Windows containers and Kubernetes. I work for a Health which is the largest Australian software provider for age and disability care, pharmacist and hospital. I'm going to talk about a particular product in Asia which is called Colin. It's a very useful tool for care providers in Australia that they can use to manage their community called documentation and all the administrations work for their residents. This particular tool has been around for 15 years and you have got the largest market share in Australia and we have more than 200 clients that are using it. Now we know that there is a legacy app. What did we want to change in it? If you compare a single installation of our app with a ship, a ship has got everything that it needs to run. Our application is also similar to that. I mean a single installation of our app should have everything that is required to run like the operating system which is Windows in this case is the database, the code and everything else that it requires. However, the picture that we are facing at the moment is this. We have 200 different shapes running around in a the reason is we have spin up new VM for all of our clients. Unfortunately the app have a multi tenancy feature and we have to do it this way. Obviously this is another picture that you want to maintain these days and we want to get back to our picture of having one ship. Alright bye now why did we want to make the exchange? There are many reasons maintenance is the big one. It's not easy to maintain 200 different virtual machines, even some of our clients they have their own onprem as well. Cost saving is important with the performance, scalability security making it easier to put for ourselves. Better disaster recovery plan, higher availability. All of these eventually lead to a better customer extent. Before I continue. I just want to quickly mention about mention the technologies that are been using this particular product. The development of this app started 15 years ago with ASP Practic, and over the years there has been a lot of that in a lot of transformation and different technologies added to text that unfortunately we don't have SP classic, but we have some legacy code which is written in paper form and AngularJS so we know that there is a bit of legacy code over there and those ones are not easy to change considering the fact that we have active clients using our application. So we know that we wanted to transform our infrastructure, but what options? You don't want to make huge changes in their code and we wanted to go with platform as a service offering from one of the cloud providers and we are using Azure already. So our options essentially came down to Cheat, Azure App Services and Azure communities. We chose it. And the main reason for that was again, this picture. We want to have all the releases, all the installations for all the clients in the same sheet, or as I said, or list a few of them, not 200 of them. 207. And in the case of AKS coverages, will be the captain of a ship. The challenge was containerizing our app. As I said, all the technologies that that you saw are quite old. Some of them are quite old, and we are using Spot framework, not ASP Net close five. We had to go with Windows containers in order to make sure that our obvious kind of working Windows container. In the first situation, we decided to a proof of concept. And in order to do that, we use a tool called Image to duck up, which is a partial module that can look into your ritual machine that you are running your application and it can help you to build build your container. So we did it. We use this tool and we were able to contain the application and we run it and all went fine. We did some smoke testing and all look promising. That's as easy. I wish it was that simple. Anyway, this picture is a simplified of our solution, the legacy code that the legacy applications that I'm talking about, and it has got many features, many libraries, many assemblies, many folders, and all of them are kind of related to each other. So the very first question that we ask ourselves as if we put everything in a single container, that's probably okay. But instead we thought maybe just do a bit of refactor here and just put a draw a line somewhere in the solution and divide the whole solution into two and let's call one of the legacy another one mother. So the way that we did this dividing was we know that there are some technologies that quite old, and if we want to convert them to new technologies, we have some limited options or no options. Those ones in Legacy. And to be honest, there's not so many development happening on the legacy code, and we will be focused more on the modern type of thing. So we ended up with two containers. So in this way, we have to upgrade our modern code in a close future. And at some point we can rewrite the legacy stuff and get rid of them. Another thing that we had to use for how the application was configuration builders. The reason that it's actually a new get package that I think available from Net Framework 4.7 .1. And it's a way that it's going to help you to inject your configuration values to your containers as environment variable. So you have your environment, you define your environment variables for your container and just inject them to the container. The container your application that is running in the container and pick them up and use them. Okay. One another challenge was running our application a load balance environment and why this is important. The reason is in Kubernetes is quite common that you have a replica of your your application or a single release, so your application should be able to walk behind the Lord Palace. Some example, we had some local file logging for application login that we had to get viable and we use Azure app inside instead of those ones. We had some in memory caching to increase the performance. We remove those ones and we use Redis since then. Also, there are some places that we were saving some temporary files to be purchase later on. We had to get rid of those ones as well. Along the way. We actually came across some list known issues like the places that we were using some third party certification licenses to with other systems that to change those ones as well. Also, we realized that there is a site application that we used to run using Windows task scheduler not is that didn't go very well with configuration builders that we are using. So instead we use Kubernetes Cron jobs to handle this particular scenario. In general, when we talk about Windows container, they have some limitations in this slide. I'm just talking about the limitations that are important. Some of the limitations that are important in Kubernetes and as the very first one is you need Linux master node. So Kubernetes is an orchestration tool for containers and it needs a Linux master note. It needs a place of one virtual machine that he's using minutes, but you can have more rich on machines that have Windows operating system. So if you are using Windows containers, you will end up in a hybrid approach. You need to have a mix and Windows machine side side by side, which is perfectly okay if you're using cloud provider like as, but if you are running your searcher, then there is a bit of work there out of memory. Exceptions are different in Linux and Windows. The reason that this is important is if your Linux VM is out of memory, then it can kill some of the parts that are running in your cluster based on some criteria. A part in Kubernetes is essentially a process that is running your container. But the same story doesn't happen in Windows, and if your Windows machine is out of them, it will start paging and it will use the disk for that. So what you get is just some performance issues on your application, I guess supports Windows Server 2019 or above and only process isolation mode in Windows container is support. So this means that you the version of operating system that you use to build your container should match with the version of a rating system that you use to run your container. And for as, it has to be 20 Windows 720 19 or above. Network policies are another good feature of communities. They are some sort of rules that you set on your cluster that that can can block some communications that are happening within your cluster. Among the pots, unfortunately, that supported in CS or Windows notes, but they are supported for Linux notes. But I had a lock up road map and I think this is something that are going to release in the future. Some learnings if you if you can just use Linux containers, if your application is in a shape that you can convert it to that five do so. Otherwise, Windows containers are something that you can book with as well, depending on your scenario. But think about the future and think about how you can upgrade your solution if you are thinking to upgrade the infrastructure for legacy application, most probably the processes that exist in your organization are also legacy. So think about the amount of changes that you're going to introduce. One example was for four. Our scenario we change the infrastructure, but we didn't. We even changed CI CD tools. There was no reason actually to change those ones, but if you are removing a feature or two, think about the alternative. Another example from how scenario was when we presented our solution to our application support. Very first question that they asked us was how can they log in into a server and and check the Is logs? Because they used to do that a lot. And we said, well, you can do that, but it's not that straightforward. So instead we explain them, how can they get the fish they want using Azure app inside. And also we stream the Is logs for them in container logs. Then they were able to use Kubernetes Dashboard or Azure Portal to see those logs as well. And eventually there's always something to surprise you. So be ready for it. Thank you, everyone. And here is the link to plan your address side and my speaker code that you can use site. If there's any questions, please put them in the chat window and I will answer them. Thank you. Thanks, Mike. That was great.