Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Moving from a Monolithic to a Microservices Architecture

Moving from a Monolithic to a Microservices Architecture

This item in japanese

Arguing for a move from a monolith to microservices the only value business stakeholders care about is reducing cost. This shift in architecture will not increase or protect revenue and neither scaling nor distribution are good reasons that will convince the business, Ian Cooper claimed in his presentation at this year’s Microservices Conference in London giving some guidelines moving from a monolith to a microservices architecture. The reason cost can be reduced is that developers can be more productive working in smaller and less complex contexts.

Cooper, founder of the London .NET user group, notes that business capabilities are often mentioned together with microservices but that very few have a clear definition of the concept. For him a business capability is essentially the function a business provides to its customers that gives them some form of value, one example being an insurance company selling insurances. Business capabilities are quite stable but also at a rather high level, Cooper therefore transform them into bounded contexts, (a concept from DDD), to make them more concrete.

In a monolith multiple bounded contexts exists but they share resources like domain objects and database schemas. This creates dependencies between all parts; when one is changed it may have a ripple effect to other parts which means everything has to be built and deployed together. Moving to a microservices environment all that is needed is breaking this up into separate bounded contexts. Although straightforward Cooper notes that it’s not a trivial operation.

One approach for moving from a monolith to a microservices architecture Cooper describes is a complete rewrite but for him this is also a move from an agile to a waterfall world since the replacement usually have to be functional complete and is not shippable until it matches the existing system. This means going dark without feedback for a long period of time as all learning will come at the end. This type of projects tend to be closed due to failing in delivering any business value for a long time.

Cooper instead recommends finding the features where the most value for the business lies, i.e. features that create a market differentiation or that are mission critical, maybe also changing rapidly. He then replaces them one by one with new code which allows him to replace functionality in a bounded context with new one until all the old code in the context is dead and may be removed. Eventually a point is reached where all functionality needed has been replaced. Advantages he sees with this approach are that it enables a project to stay agile and manage risk using incremental re-architecture and delivering early and often.

Next year’s Microservices Conference in London is scheduled for November 7-8 2016.

Rate this Article