Don’t Stop Your Cloud-Native Migration Too Early
Cloud-native migrations can be intense. Steps are complex and intertwined and system complexity can slow you down and introduce problems and concerns. It may not be clear that everything will eventually smooth itself out. It may not be clear that your migration will be successful. It may not be clear that the migration will ever end.
This is especially true if this is your first cloud-native migration and the whole concept of cloud-native architecture is new to you. You may see things happen to the application that you were not expecting and you might worry that things are going very wrong.
This is the biggest mistake people make during their cloud-native migration, and this is when it first crops up: They consider stopping the migration.
Let’s face it; when you started the migration, you had great plans. You were going to split your monolithic application into a series of services. These services were going to be containerized and orchestrated, and Kubernetes was going to be your friend. You were going to take your stagnant monolith and convert it into a vital and future-proofed, cloud-based, scalable web application.
Things were going to be great.
But then, reality sunk in. The changes were more involved than you thought. Things looked like they were actually going backward. Pulling functionality out of your monolith and into standalone services makes your code more complex. You were adding complexity to your application in the short term. You now have new moving parts that you have to manage.
Your application seems brittle to you.
You can still dimly see the long-term vision. Microservices make your application more supportable, sustainable and easier to manage as it grows. But, right now, as your application sits partially dismantled, you have a hard time imagining this long-term vision becoming a reality.
This is called the Valley of Pain. It happens during any complex migration, but you are specifically vulnerable to this phenomenon as you move from a monolith to a microservices-based application.
The Valley of Pain is the point during the migration where you have invested in the migration and completed part of the process but have not yet started to see the benefits of the migration. Instead, you only see the downsides. These downsides are an expected part of the migration process itself and not an indication of what life will be like once the migration is complete. Downsides seen in the valley phase include lowered application performance and increased code and architectural complexity.
The valley exists because splitting a monolith into services involves breaking things before fixing things. You must break up your monolith before you can assemble a services-based architecture. This can be a long and complex process, and your application will look—and act—very differently while you are in the middle of the migration. As a result, your application will underperform, and the fundamental complexity of the application will increase.
Your application is more brittle during the migration and so is your organization.
You start feeling the pressure. Your application is running slower and errors are cropping up. Obviously, you must be doing something wrong. The costs are too high. The risk is too great. The rewards are only a distant possibility. Something has to change.
But, this is the worst time to give up on the migration. After all, you’ve already started by moving some components out of the monolith. Your application is more complex and more fragile right now.
This will improve.
But right now, things are more complex in this half-completed state. If you stop the migration now, not only will you not see any of the long-term advantages of the completed migration, you will have to endure many of the short-term disadvantages of the migration itself. If you stop the migration now, you will be worse off than if you never started the migration in the first place.
When I’m brought in by a client to assist with a migration project, one of the first things I always do is sit down and talk to them about the project’s risks. I make it abundantly clear: Whatever you do, do not start this migration unless you believe you have, throughout the entire organization, the will to see the migration through to completion.
I’ve seen so many companies start and then abandon the effort. They’ve left themselves in a worse state than if they never migrated. I even was part of a company that started a microservices migration, stopped it in the middle and declared it a victory in an attempt to keep morale high. It didn’t work. People felt defeated, and people left the company.
Don’t get lost in the Valley of Pain. Don’t start a migration unless you are sure you can sustain it. And once you start a migration, see it through to the end. Your efforts will pay off, and you will reap the benefits of a true, cloud-native application.
