For those of us who have ever been tasked with the exciting albeit challenging work of migrating a deprecated software system to a more modern one, we know that great emphasis is always placed on the migration plan. Be it turning a monolithic dinosaur in to an array of autonomous and lightweight microservices or dragging the long loved JEE solution from IBM WebSphere Application Service in to the cloud - all containerised, load balanced and orchestrated, you might have been there.
Migration efforts typically consist of three artefacts:
Baselining, a.k.a The As-Is: To baseline a system involves analysing and documenting the current state - a.k.a the as-is of the system. This typically include having a deep understanding of the system to be migrated including all current use cases, their implementations, architectural artefacts (UML diagrams if applicable), tools and technologies used (including frameworks, libraries, etc.);
Target Solution - a.k.a. The To-Be: This concerns the ultimate outcome of the desired system after migration - the silver bullet solution, if you will;
The Roadmap: The roadmap is generally considered the plan from getting from the as-is to the to-be.
In my meandering experience, I have however seldomly seen a practical application of the roadmap.
Granted, if my as-is is "I am in Miami now and my to-by is "I want to be in New York City, it would be fair to argue that my optimal route might take me through Columbia SC, Raleigh NC, ... - but does this reasoning really apply to software system migration?
At present, the half-life of technology is short and shrinking at a dizzying rate. If I had a magic wand that could produce and deploy the ultimate silver bullet solution in no time, immediately that clock starts ticking and the ultimate silver bullet soon becomes archaic. Can we thus afford to be held back in the name of the dreaded Roadmap? Put differently, building the silver bullet takes time. Do we really need to build the Columbia or Raleigh solutions before diving straight in to the New York City solution?
IT teams often follow this diverted approach, clinging on to the as_is with an almost nostalgic and sentimental yearning to drag their technical debt in to the future. In the confusion, their roadmap even consists of an interim solution equivalent to adding a Detroit in their road to New York.
The point is: what would happen if we start building the ultimate solution from the onset?
I was part of a team of software developers working on a migration project. The baseline: J2EE running on the IBM tech stack; the target, AWS with Lambda functions, EC2 instances, S3 buckets and all the bells and whistles one would expect for the ideal and well architected modernised cloud echo system. The problem? The implementation plan and in particular the dreaded roadmap.
It has been decided by the powers at be that it would be practical to containerise the J2EE / IBM system and deploy it in the cloud. Why, one would ask, only to be confronted by doubtful stares consumed by the confusion of an atheist in hell.
The solution: we have industry proven best practices for migrating complex systems efficiently. The migration can be done while in production without the end user ever knowing what is happening in the background. For microservices, the Strangler Pattern immediately jumps to mind.
A blue-green pipeline allows for th switching to migrated services once they are ready for production.
If a company decides to migrate, the first question should be: WHy? before How?
Case Study: we want to use microservices so that small teams can work on small grained services individually with little disruption to their "neighboring" services. This sounds like a great idea.
But what if we only migrate services we envision will be changed in the near future, develop all new services to our modern microservices architecture and leave the monolithic workhorses be - at least for now?
When bug fixes are required, migrate, fix and deploy to production.
Prioritise services to be migrated based on need and urgency. Taking the route from (for this example) monolith -> miniservices -> microservices makes really no sense.
Top comments (0)