We’ve previously looked at the Firecracker migration pattern for modernising legacy applications. We identified that the Firecracker technique works best for small legacy applications. A good example is offline databases such as Microsoft Access or Excel. But what do we do when we’re not migrating a single legacy application? How do we migrate those monoliths that are too large to migrate in a single project? We must stick to our agile principles and chunk down the project. Hence, we must divide and conquer.
Addressing legacy migration risks
As we've established, it is important to chunk the legacy system into multiple migration projects. This means we cannot simply turn all the lights off on the old legacy system. In effect we have an old and new system live at the same time. It raises a number concerns:
- Data integrity: what system holds the source of truth?
- Up-stream and down-stream systems: we must make sure we don't break other systems
- Integration: how do we keep the systems communicating without investing much time into the integration.
Divide and conquer migration pattern
The divide and conquer migration pattern stems from Eban Escott and Indi Tansey's book Bots that Code. It uses bots to help observe the existing legacy system (workerbot) and build the modernised system (csharpbot or springbot).
This figure is more like a deployment diagram. The old legacy system is on the left and the new legacy system is on the right. Each legacy system is split into an application (top) and a database (bottom). The humans on the left are the end users of the old application and the workerbot on the right will simulate the humans during the transition phase.
Step 1: Follow the steps from the firecracker migration pattern i.e., reverse engineer the requirements and design the new application. This should only be done for the upcoming scope of work. There may be learnings made from the initial migration that informs/changes the way you design the subsequent migration projects. This also includes formulating a database migration plan.
Step 2: If possible, add an interceptor between the old application and its database to forward all requests to the workerbot.
Step 3: If possible, add an observer to the legacy application that is able to forward other request data to the workerbot. Since all projects are different, think of different observers and interceptors you can use to send to the workerbot.
Step 4: Develop the workerbot to interpret the requests from the observers and interceptors to mimic the same requirement but in the new application.
Dr Escott recommends using an isolation checker to ensure the data integrity of the new application.
It will take significant effort to build the framework around the old legacy system. The observer, interceptor, and workerbot will take time to get right. But once you get them going, you will have a path to continue the divide-and-conquer approach on the old legacy system.
Utilising microservices for the modernised application
If you've read up until now you probably know a thing or two about monoliths. If this brings up a few bad memories (or even reminds you what tomorrow could be like) that's ok. We want to learn from the mistakes of the past to build better systems tomorrow. One learning that is particularly important is the need to break down monoliths into microservices.
One helpful tip is to identify the right messaging layer between microservices. RESTful API’s has become the industry norm. There are alternative technologies like Hazelcast that some experts suggest you get in-memory speeds to get extreme performance for both processing and inter-service communication.
Above all else, microservices requires a cultural shift. Protocols need to be standardised and new DevOps capabilities need to adopted. This type of shift can be difficult to perform internally and can be easier to complete by outsourcing the initial development. WorkingMouse specialises in legacy migration and will use processes and technology that will mitigate the risks of modernising your legacy system.