If you have legacy applications and are moving to the cloud, one popular pattern is to do a simple “Lift and Shift.” That means you don’t architecturally change the application but simply move it to your cloud of choice and run it just like you did before. This approach lets you more quickly “get out of the data center” and doesn’t initially imply that you have to refactor any part of the application to use native services provided by your cloud vendor.
In fact, if the application is stable but just legacy, your valid strategy might be to let it run forever in an “as-is” state. Nothing changes. Just get it running in the cloud and out of the data center.
This approach’s major downside is that Lift-and-Shift also carries forward all the Technical Debt accumulated for that application.
Technical Debt is defined as:
Technical debt is the implied cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Analogous to monetary debt, if technical debt is not repaid, it can accumulate “interest,” making it harder to implement changes.
Let’s look at an example:
On a recent project, a customer moved a VM from on-prem to the cloud. This included the OS along with the defined storage. Their idea was to recreate the same disk layout in the cloud that matched what the VM currently had on-prem. They wouldn’t have to re-think, redesign, or refactor anything and would let the migration process be mechanical and easy to implement.
Let’s look at the VM definition:
Total storage size 2 TB (terabytes). The total number of disks is 41.
Yes, that is right, 2 TB and 41 disks.
A reasonably technical person would ask: “Why so many disks?” I did just that. The migration person I worked with said, “I don’t know. That is just how it was on-prem.”
I finally found the person who did know, and they said: “That application is close to 20 years old. In the past, when the database ran out of space, the current administrator at the time would add another small disk to get it working again. No one ever wanted to return and consolidate all the small disks into something that made sense.”
This is a prime example of Technical Debt compounded. The historical solution was “just get it working and move on.” Year over year, from one admin to the next, keep adding a little hunk of disk space when needed.
This VM also had performance problems. What is the “easy path?” Just add more memory and CPU to try to overcome the IO inefficiency. Multiply that approach over dozens or hundreds of VMs that are part of a large-scale move to the cloud, and most likely, your monthly cloud bill is unnecessarily inflated.
Sometimes, a straight lift-and-shift is justified if you are forced to get out of your data center and don’t have the time. If that is your situation, then do this one thing:
Assign a “Technical Debt Rating” (TDR) to the various components being migrated to the cloud. It doesn’t have to be fancy, and any experienced technical person can look at something and say, “That doesn’t look right.” That is all you need. The TDR gives you something to review after your migration is complete. The problem will be solved if the app is refactored to become all cloud-native. If it’s a “Lift and Shift Forever” scenario, the TDR may be used to tune things up over time.
Here are a few examples of architectures that might warrant a high TDR number:
- Server with a small total storage size but many disks (LUNs). (Example: 2TB X 41 disks)
- Server with a small total storage size but a high amount of CPU or memory assigned. (Example: 500GB storage X 256 GB memory)
- Compared to other apps, applications have a very high number of reported bugs/functional problems.
- Systems with high numbers of outages.
- A system with components written in several different languages. (Example: Java, C++, Python, and Go are all used on the same application)
- Systems with high numbers of security incidents.
These are just a few ideas of how you might classify something as having a high TDR compared to a peer. A straight lift-and-shift is going to carry forward much of the historical technical debt. Lift-and-shift is a valid cloud migration approach in many situations. Once you’ve moved to the cloud, you will have a lot more options available on how to get rid of some or all of the historical baggage that was carried forward.