Share this
by Kosta Hahladakis on 28 April 2016
In my role as an Equinox IT Senior Consultant specialising in solution architecture, I am often asked by clients to assist in planning IT architecture and technology roadmaps. In a recent assignment I was asked to work with a team from Equinox IT to help a client modernise their core business system. In this article, I cover the work that we performed to migrate the system onto a new platform while minimising business disruption and project expenditure.
Client situation
The client’s core business system had evolved over time with many changes and new features to the point where it had become large, complex and unwieldy for the developers to maintain. The architecture had grown into a spider’s web of tightly coupled interconnected components and services. The application platform was littered with deprecated technologies and unsupported 3rd party libraries. Myself and the others from the Equinox IT team were tasked with finding a way to modernise and simplify the system so that it could better support the client’s current and future business needs.
Setting the legacy system migration strategy
Firstly, we set about establishing a strategy for modernising a large and complex system that would be workable with the client. The client did not have the appetite for a large scale rewrite or replacement project. In this situation, we decided that a Strangler strategy (like a vine plant strangling, killing and replacing it’s host tree over time) would work best. The existing system would be gradually migrated onto a new technology stack by replacing small pieces of it at a time. The core system would continue to operate while we integrated the new components alongside it. In this way, we could approach modernisation almost as a maintenance activity rather than a major programme initiative.
One of the challenges in applying the Strangler strategy is finding hooks into the current system where functionality and data could be partitioned and new solutions injected. Luckily for us, the existing system was based on a web services architecture and this provided obvious demarcation points. We would begin the migration of the legacy system at the services layer, rewriting various services as we went along and integrating them back into the larger system.
Designing the new services model
To define the scope and shape of the new services we would be developing we decided to follow a Domain Driven Design, by examining the business context and organising the services layer accordingly. We didn’t just want to do a straight out one to one replacement of the existing services as the interfaces were already very tightly coupled to the underlying platform and leaked too much implementation details.
With each service to be replaced we undertook an analysis of the related business domain.The analysis involved understanding and capturing the key business concepts, and as DDD advocates, establish a common terminology that would permeate from the requirements through to the code. Services were identified by breaking down the business domain into discrete areas of responsibility and organising these into the sub domains and bounded contexts of our analysis models.
Implementing microservices
When we set the future state architecture of the new application platform we decided upon adopting a microservices architecture. It was difficult to maintain the existing system and we didn’t want to repeat the mistakes of the past. So we put a lot of effort into ensuring that new components were developed as small, autonomous services. This aligned nicely with the Strangler migration strategy we were following allowing us to tackle updating the large system one piece at a time.
The services we developed were small and focused. Each one operated as an independent unit supporting a specific business context and managing all related data. They exposed a REST based API that had a clear interface and was simple to integrate with. Each service instance was self-hosted, running under its own embedded http server and did not rely upon any external dependencies or configurations. This made them truly portable and allowed us to treat them as the Lego bricks to assemble the foundations of the new system.
Result
Over time we made great progress in modernising the client’s legacy system. Approaching migration in an incremental manner meant we could deliver new services early and have working software in operation, and thus avoided undertaking an expensive and risky replacement project. Adopting a Domain Driven Design and Microservices architecture has set a solid foundation for modernising the legacy system. This is only the beginning of the journey but already there have been some great successes and clear way forward for the future.
You may also be interested in my recent article Enhancing continuous delivery with blue-green deployment
Kosta Hahladakis is a Senior Consultant specialising in solution architecture, based in Equinox IT’s Wellington, New Zealand office.
