Migrations
Issues with migrations
Migrations can have many challenges often could be narrow down to a Testing problem. Once you migrate the code and are compile it, how can you say that will not break the business in any way? If you do not have an established owner, this is a potential risk.
If there are multiple slow migrations in places due to the team erosion effect, it could quickly produce Left Overs which are potentially tricky. Unfinished migrations can create challenging scenarios for future migrations.
Ultimately if you have a legacy system(meaning not maintained by healthy/safe engineering practices), migrations might not be possible at all, and you might need to do a re-write. Other times, it could be pure FUD(Fear, Uncertainty, and Doubt), meaning it looks scary but is not that bad in practicality. One of the many reasons is because it is easier to write software than to read it.
When do not migrate?
There will always be different appetites or forces inside a company, which is healthy to some degree. Big business might have domains or products that might perform better, which might get more people, investment, and moving faster or slower.
There are always pieces of software known as Legacy systems which, in case if they have a red laser pointed to the heads(meaning they will be decommissioned on short/mid tern) in that case, doing migrations might not make much sense.
IMHO, migrations are more complicated when you pile them up and are not doing things incrementally. It's like branching and merges; long-lived branches are more challenging to migrate than short live branches, like smaller PRs (10 files or less) got migrated much faster than bigger ones(+100 files).
Now you might be wondering why migrations are not done incrementally? Well, it could be for a variety of reasons such as:
* Higher priorities or more significant problems
* Lack of discipline and proactive culture
* High Coupling(Distributed Monoliths) - creating all or nothing scenarios
When should we migrate?
Under the right conditions, I believe there is the sweetest spot. You really do not want to jump to the shiny new things and re-write all your software every 2 weeks. On the other side of the coin, you really do not wish to discover you have 50% of you fleet running in windows 95 and Java 1.2. This leads to one of my points here. Visibility, in the sense of inventory. We need to be able to answer these questions:
* How many services do we have?
* What's the type of resource? Service? Lambda? Shared Lib? BFF? Micro-front?
* How many of those are active? to be decommissioned?
* How many have established owners?
* What migrations are going on now?
* Do we have leftovers, how much?
Governance often is a bad word. I personally have my issues with Governance, mainly because several times it is bureaucracy. However, at Scale, you lose control; when you have so much software, you really need to increase discipline and Governance. Governance does not means rigidity or doing things without thinking. Having a proper inventory allows you to have better decisions on the tactical bases service by service.
Ideally, performing migrations in isolation is a big deal because you can do it without cross coordination, and teams can do it at their own pace. IMHO isolation trumps almost everything, and for several reasons, you always want to have isolation. At Scale, some degree of chaos will always happen; some damage control is needed. That's why inventory is a must-have.
When there are services that are critical to the business when you have a compelling case, meaning the benefits of the migration are:
* Reducing Cost
* Reduce Complexity
* Reduce Binary Coupling
* Increase operational efficiency - less work to maintain software
* Adding new business capabilities
For these reasons, migrations are often a good idea. One way or another, there will be migrations, is the nature of software, like Cloud Migrations from the past decade and pretty sure will continue to happen for the next one. Due to security patches and vulnerabilities, we always need to update software; going on a high level of abstraction such as containers and lamdas makes it better, but nothing is perfect in software. They also can have bugs and security vulnerabilities. This is a never-ending battle.
Isolation, Inventory, Proper Testing are ideal practices that will reduce migrations and make migrations easier and more manageable. Incremental and proactive migrations also make teams work on their own terms and pace, allowing more flexibility and less cross-coordination.
Cheers,
Diego Pacheco
