Modernizing to the Numbers

When we look at taking on any modernization effort, we need to look at a lot of factors. Some are actual and some are emotional. But let’s unpack that. We can put metric around how much revenue goes through an application. You have an e-commerce site and that’s a clear metric. Some factors are not as cut and dry. If you have an app that is personal to someone who has tenure at your company, it’s going to get emotional. I have seen this firsthand.

Them: “That is Pete’s app he wrote that for Kelly in accounting she uses it once a month!” Me: “I get it, but it’s written in VB6 and we need to talk about rewriting this.” Them: “This is a non-starter!” Me: SMH

But if we can wave a magic wand and remove the emotion from these conversations and look at only the data. The data we should be looking at needs to be deep and relevant. Sure, we should look at how many users use the app. What are the peak use times and how many users are at those times? What are response times on average and when you are at peak load are other factors that need evaluation. So often we start off talking to customers about getting an app to the cloud we don’t look and see where it’s at.

Before any serious effort of modernization requires some deep analysis. I usually ask if they run tools like Dynatrace or even New Relic. And yes, I know they are hard to compare. But having something that can take a deeper dive on what is going on in your apps. If there are code issues, they don’t get better when you move to a platform. They get worst. And sure, in your data center that isn’t going to cost you much dollar wise but in a public cloud. A few things to remember before you start.

Code Analysis

Know where the code has some pain points. Again, tools like Dynatrace and New Relic make this easier. Analyze how the application is running currently. See if you have deadlocks. Code that is running bad or have outdated practices. This is the time to outline them. Have the target architecture remediate and have a path to get from the current state to the new state. Taking the code in one project and squeezing it in to a microservice helps no one without knowing what is there. Don’t worry if this hurts Pete’s feelings.

Know the Load

Unpopular opinion here not everything needs to be a microservice. But sometimes it makes sense. Best way to look at this is understanding the load of the application. There are two sides of this. First (again) using a monitoring application to track when and where this happens. Second is to talk to the business owners of the application. If these two sides line up, then this is an area to focus on having it scale.

For example, the application takes a huge load at the end of the month. Business says that’s when they run some month end jobs and they take forever to process. But if you are seeing issues here and there with no explanation. This isn’t an area to focus on scale more so focus on code.

Benchmark

Have the numbers of where your application is at before you start. Run the same tools throughout the modernization process. Don’t make the mistake of changing your monitoring tools halfway through this effort. But throughout this check and see if performance is getting worse or better. Best case it’s staying the same. Adjusting course as you go is much better than trying to fix it after the fact.

Wrapping up

Don’t go into this blind. Have the data and numbers to support what you are doing. Unless of course you have unlimited resources and time, then do what you want. But for the rest of us having a focused approach on what to do is imperative. Have the numbers to justify the effort. Be able to back them. APM tools make this easier. This also show a clear other use for tools like Dynatrace and New Relic.

Most companies question this all the time. “Why are we using time and money on doing this?” Be able to show how this effort has made the app better. I have learned if you state something like “this is VB6 and we need to upgrade or it’s going to be bad.” This doesn’t work.