In the past few weeks there have been a lot of posts on the blog about Micro Services, their benefits, their negatives and even about Monoliths. Time and again there has been a mention of how you needn’t worry if you have a Monolithic structure and that Micro Services can work with Monoliths. Today we will examine how to do just that.

So how does one refactor a Monolith? It is not often that we are awarded the opportunity to start with a blank page where service architecture is concerned. In fact some of the most successful Micro Service based architectures that we see today started out as Monoliths!

The first place to start is to examine your Monolith to see if you indeed are big enough to justify the shift since the shift is not only expensive but requires some serious reworking of the teams that work on your architecture. Once you have made the decision to go ahead with Micro Services stop adding any more code onto your Monolith and start externally like they did with SoundCloud.

Add any new functionality to the Monolith as a Micro Service. For this to work you will need to write a slightly complicated glue code to ensure compatibility but it is important to stop adding further elements on to the existing code.

Next, we peel the Monolith. Identify the components from within the Monolith that can act as small, stand-alone services. Great places to look are services that are in a constant state of flux or those that are in conflict for resources or would be better served in other languages. These components can one by one be turned into external services and attached with clue code or by using public APIs that work with internal APIs. Slowly we strip the Monolith of all the components that can be turned into Micro Services and create the framework. Keep in mind though that there will always be at least a small part of the Monolith remaining at the core.

While this process is by no means a piece of cake, it certainly helps in making the transition from one type of architecture to another.