Are you planning an application migration? Perhaps you are moving your on-premises application to the cloud, or perhaps you are moving your monolithic application to a service-oriented or microservice architecture.Migrations such as these are commitments. Commitments of time. Commitments of resources. Commitments of mind-set and corporate energy.Migrations are not easy to pull off.Migrations can involve long and evolved transitions, and usually, the effort expended does not directly align to a realized benefit. Often the benefit comes much later than the investment. Sometimes things even get worse before they get better.It’s tempting to want to quit the migration early.Who would ever want to do that? It seems crazy, but it happens. Moving from a monolith to a service architecture, but stopping not long after the migration has begun, leaves the application in worse shape than before starting the migration. So how do you avoid the temptation of halting a migration in its tracks? Well, it’s all about managing expectations and understanding the true return on investment.The Valley of PainWhen we start a major migration, especially a complex migration such as a monolith to microservices migration, we have certain expectations about the benefits we will ultimately see. We expect the benefits are a function of the effort and time we put into that migration. We calculate that the ROI (return on investment) will make the effort of the migration worthwhile. But this ends up being a simplistic view into determining the value and benefit of the migration. A simple ROI calculation doesn’t sufficiently capture our understanding of how our efforts will turn into benefits. Typically, we imagine the benefits and investment will play out uniformly over time, as shown in Figure 1. IDG
Figure 1. Expected effort vs. investment appears straightforward.
As time goes on and we continue our investment in the migration, we expect that the benefits we receive, either real or perceived, will continue to increase. The more effort and time we put in, the more benefit we receive. Or so we think.In reality, this idealistic model isn’t representative of how the migration normally works. The relationship between investment and benefit will often be a lot more complex and will look more like Figure 2. IDG
Figure 2. Actual effort vs. investment isn’t so simple.
Here, the initial investment appears not to have much benefit. In fact, we may actually see a regression in benefits as things get worse initially. Only as time goes on will the real benefits begin to emerge. Let’s consider an example. Imagine you are moving a monolith to a service-oriented architecture. Initially, as you start changing parts of the monolith over to services, you might experience decreased performance. The application complexity increases because your application contains many more moving parts. You continue to add more individual services to your application, yet still the remains of the monolith are present and are heavily involved in the function of the application. This complexity may cause reliability problems; it may cause scaling problems; it may create other unforeseen problems.In short, your application may be worse off than it was before you began the migration. There are several reasons why this happens:
Your code is in an interim state, with added technical debt related to the migration.
Your code runs slower because some code has been updated and some code has not.
Your code is more difficult to understand because some code uses the old paradigm and some uses the new paradigm.
The code is, frankly, a mess.But as time goes on, you work your way out of this low point, and the benefits of the migration effort begin to kick in. Your benefits multiply. You will start seeing a return on your effort as service creation becomes easier and takes over more functionality from the monolith. The growth of benefits over time will accelerate. Finally, you will see the actual value of the migration. But to see these benefits, you have to make it through the low points of the early days of the migration. You have to make it through what I call the Valley of Pain.There is a strong tendency to want to give up on the migration in this valley. After all, you’ve invested in the migration, and you haven’t seen any benefits. Instead, things have gotten even worse than they were before.But don’t give up here. Don’t stop the migration at this point. If you stick with the migration just a little bit longer, you’ll begin to see the benefits come through. Eventually, you’ll make it to the point where the benefits are growing faster than the effort you are putting in. IDG
Figure 3. The pull to stop early is strong.
Falling for this trapI’ve been through many migrations. Virtually all of them have this valley. But, unfortunately, companies fall into the trap of giving up at this low point and suffer the consequences.One major company I worked with abandoned their monolith migration at the worst possible time—at the very bottom of the valley. In doing so, they simply “declared victory.” But there was no victory for them.They informed everyone working on the project that they all had “learned enough” from the painful migration effort: “We now know what’s involved in implementing this migration, so we can stop here and maybe pick the migration back up again later on.”The company wanted to get back to doing “real work” and stop investing in the migration. They concluded the announcement by telling everyone, “This exercise was a valuable experience, don’t you think?” Yes, it was a valuable experience, but at what cost?What the company had created was an untenable code base. They had built several services that were figuratively bolted on to the side of the remaining monolith. Yet, the monolith was still there and still just as difficult to work on. Their code was a mess, and they suffered from the problems caused by this mess for many years.This decision severely reduced the company’s ability to produce new features for some time to come. Morale among the engineering team hit an all-time low, and the company lost many good engineers. They even created some severe availability issues that impacted customer satisfaction. This was not a pleasant environment to work in at the time.The lesson from this story is this: The relationship between benefits and effort is not linear. There will be times during the migration when things seem to be getting worse rather than better. But don’t give up. There will be a light at the end of the tunnel, and the benefits will begin to appear. The benefits will be more than worthwhile in the long term.Before you start the migration, understand the costs and understand the benefits. But more importantly, know when you have to pay the costs and when you will see the benefits. Don’t stop when the costs start to build. If you keep moving, the benefits will eventually appear.
Copyright © 2021 IDG Communications, Inc.
Source link