There is a bit of sticker shock out there. No, it’s not the big IaaS public cloud bill that will make you gasp, it’s the price of changing applications to take advantage of cloud-native features as they move to the cloud.
There are three basic ways to deal with application migration to the cloud:
- Lift and shift, or just putting the applications on a public cloud unmodified and hoping for the best.
- Partial refactoring, which means modifying parts of the applications to take advantage of some cloud-native features.
- Complete refactoring, or redoing most of the application to take advantage of cloud native features.
Of course, lift and shift is the cheapest way to go, and thus the way that many enterprises have directed their cloud migrations. The downside is not taking advantage of the cloud platform where the application resides, leads to higher bills, slower applications, and just not making the application be all that it can be on the public cloud platform.
The refactoring approaches, to take advantage of cloud-native features, result in lower cloud bills and higher performance, but it adds costs and risk. Moreover, the worse the state of your applications, the higher the refactoring cost and the risk.
Enterprises are doing the right thing in trying to refactor applications moving to the cloud, including running the cost metrics of the work that would need to be done. This refactoring effort not only includes the rewriting itself, but testing, deployment, and perhaps using new devops organizations and tool chains.
The problem is the cost. I see them ending up triple what enterprises initially expected. This is due largely to the fact that the applications were much worse than originally assumed, and major (unexpected) gutting was needed to get them first to a good architectural state and then to a cloud-native state. It’s like when you go to the auto mechanic to find out what is making those ticking sounds, only to find that a pushrod is bad and needs a major expensive overall.
So, will enterprises pay the extra cost? Some will, for most of their critical applications. But budgets are budgets. So, enterprises will end up not refactoring as many applications as originally thought, perhaps putting them off for 2020 or 2021. This may end up costing more money in the long run. If that’s acceptable to you, fine. My advice is fix it now, rather than later, and absorb the costs you’ll end up paying later anyhow. After all, that pushrod can come right through the block.
