Re:The Great Microservices vs. Monolithic Apps Twitter Melee
by derefr on Wednesday August 20, 2014 @06:15PM
(#8204985)
You don't need to do a big rewrite. Instead, you
1. turn your current monolith into one service (e.g. "cms-legacy");
2. fork the monolith codebase and remove everything not needed for that one particular component;
3. rewrite your integration tests for that component to use gateways, such that they either can be talking to the componentized service or the legacy service implementation without caring;
4. refactor the component into your favored beautiful new SOA design;
3. ensure the integration tests continue to pass;
4. remove the equivalent component implementation from the legacy codebase, and reimplement the shell of its consumer-facing API with calls to the componentized service (think LibreSSL here);
5. ensure the integration tests continue to pass;
6. repeat.
Basically, this is the Big Ball Of Mud (http://www.laputan.org/mud/) strategy, applied to cohesion between services rather than cohesion between modules.
1. turn your current monolith into one service (e.g. "cms-legacy");
2. fork the monolith codebase and remove everything not needed for that one particular component;
3. rewrite your integration tests for that component to use gateways, such that they either can be talking to the componentized service or the legacy service implementation without caring;
4. refactor the component into your favored beautiful new SOA design;
3. ensure the integration tests continue to pass;
4. remove the equivalent component implementation from the legacy codebase, and reimplement the shell of its consumer-facing API with calls to the componentized service (think LibreSSL here);
5. ensure the integration tests continue to pass;
6. repeat.
Basically, this is the Big Ball Of Mud (http://www.laputan.org/mud/) strategy, applied to cohesion between services rather than cohesion between modules.