How do we know we have done enough on our move from Monolith to Microservice? It is obvious (to me at least) that we do not need to rewrite the entire legacy system into microservices. There will be pieces that do not fit into a microservice realm. They are larger, need special treatment, or any number of other things that cause us to not migrate them.
Bang For the Buck
There is a point where we have probably made a big enough bang for our buck. We have achieved the benefits that we set out on this journey for. Our code base can more easily be worked on by multiple teams simultaneously. Our developers can hold the code for their domains in their heads. Training up new members is relatively quick and painless. Deployments are automated and frequent.
There may still be this big and ugly system sitting off to the side, or perhaps still even smack dab in the middle. But that may be all right. If we have peeled away enough work that this core thing does not need to be constantly touched and coddled, then we may be done. This core piece perhaps can be maintained by a specialized team that looks very similar to a microservice team.
Business is Pushing Back
On the other hand, we may feel that there is still quite a bit of work left to do, but the “business” has deemed that our work is done. They feel they have given us enough slack, and it is now time for us to get back to the “real work”. This too is fine. We cannot continue a refactoring course forever, trying to reach some unattainable perfection. But we do need to keep reminding the business of the trade-offs. We still need to negotiate.
Building software follows a kind of sinusoidal wave, where you need to go through “peaks” of developing now functionality and “troughs” of refactoring and maintenance. If you neglect that maintenance for a while, it will eventually need to be paid off with a longer than normal period of maintenance.
We may not have spent enough time in maintenance as we would have wanted, but that is just where the conversation starts. This is the hard part of the job, because technical folks are generally bad at business and politics. Yet it is still part of the job. We still need to push for and convince the “business” that maintenance is still important and needs to be done from time to time.
Too Little Return
It is also possible that we have made a huge mistake. Maybe this system is not one that can benefit from the microservice architecture. Perhaps there is not enough domain expertise left on the teams to get the boundaries just right. Or, most insidious of all, quite often the culture will not be ready for the shift.
This will feel like a failure. Of course, in a way it is. We did not accomplish our initial goals. But we can still learn from this. Culture not ready? Work a kind of grass-roots movement to start cultivating the culture. Start little internal skunk works or mini user-groups to help advocate new positions. Run smaller experiments. Learn the people; see who is already on your side and will be advocates, versus those you still need to convince.
If the system does not fit a microservice model, look at why. Were we just jumping on this hype bandwagon without actually considering if it would work on this system? Are there pieces that would work, and pieces that are best left alone? Would a larger-grained “system of systems” approach work better? Maybe we still have much learning about the system to do before we can tackle such a drastic change.