Avoid This Common Cloud-Native Migration Trap
Migrating your software applications to the cloud requires significant development effort and testing, along with the risk of introducing complex infrastructure changes.
Moving to a cloud-native architecture is even more involved. Not only are you moving your application to a cloud-based infrastructure, but you are also rearchitecting your entire application. You are moving your monolith into a service-based architecture. You are containerizing your services and introducing infrastructure orchestration. And you are introducing different data storage and database access technologies.
All of this is difficult, time-consuming and introduces significant risk to your application and its architecture.
A common model often used to move from an on-premises, monolithic application to a microservices-based, cloud-native application is to introduce changes slowly and incrementally. You make only a few changes at a time, little by little, over an extended period. The idea is simple: Do a little improvement bit by bit and eventually you’ll reach your goal.
This model has some obvious advantages. It spreads the costs of the migration and the customer impact over a larger footprint. This means less impact on your staff, your budget and your customers.
However, there are some significant disadvantages to this approach. One of the riskiest parts of this “little by little” rearchitecting approach has to do with organizational support. When you begin your cloud migration, you will probably have significant support from upper management. After all, you are talking about only making minor changes slowly over time, and the long-term benefits are a fully cloud-native application with all the advantages that come with that modern architecture.
However, as you make these small architectural changes to your application to support a longer-term vision, you run into a problem. You end up spending some amount of resources making application changes that don’t appear to have any short-term gain. You being to field questions about why you are rewriting sections of code that, on the surface, appear to be working fine. You inevitably introduce bugs with your changes, and that just increases the scrutiny.
“Why, exactly, are we doing this, again?” It’s hard to answer a question like this when the short-term costs mount with no visible benefits and the long-term goal is still in the distant future.
Often, restructuring code to prepare to move it into a separate service introduces system complexity and affects performance in ways that appear negative in the short term. So, your attempts to improve things for the long term have made things worse in the short term. This puts the success of the long-term goal in serious jeopardy.
It is surprising the number of times I’ve seen a major application rearchitecture project halted in the middle by upper management who have lost their confidence in the migration team. The result is an application that is stuck and is only partially migrated.
In many cases, this means you are worse off than you were if you never started the migration. You have some changes in place that have no benefit and you have added complexity and changes that have introduced risk and performance problems. Yet you have no ability to move forward on your long-term positive vision.
Cut your losses and run—that’s the way upper management sees it. They’ve lost confidence in the project, in the plan and direction and in your ability to execute on a vision. And the application is worse off because of it.
How do you avoid this problem? When you decide to move your on-premises monolith to a fully cloud-native modern application, you must have a plan that has purposeful and meaningful steps to drive to the goal. You must have an organization-wide realization that there will be short-term pain in order to realize the long-term goal. And you must structure your plan to minimize the time between the short-term pain and the longer-term benefit.
Don’t get stuck in incrementalism. Make bold progress toward your cloud-native vision so your leadership team sees the benefits and stays engaged in the plan. Only then can you succeed with your long-term, cloud-native modernization plan.
