We had this debate at my company. You might want to read this:

http://www.smashcompany.com/technology/an-architecture-of-sm...

It's important to realize that you are wrong when you use the word "continuum". In a true continuum you can move in both directions with equal ease, whereas there is an important asymmetry in the tension between micro-services and monolithic apps. Read this part:

"There is an important asymmetry between an architecture of small apps and an architecture of The Monolithic CMS. If you have small apps, and decide you want to move to a monolithic CMS, then you must do The Big Rewrite: the exhausting effort of reproducing all of your funtionality so that it is handled by your one, all-consuming CMS. But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite. Instead you take some small part of your CMS, rewrite it as an independent app, set the app on its own port, use your webserver to proxy the app-on-a-port to whatever URL the CMS was previously using for that functionality, and thus you’ve taken a step towards a new architecture without having to rewrite anything but the functionality covered by your new, small app."

I did not hear the phrase "micro-services" until Martin Fowler wrote his essay in March 2014, but clearly, what I talked about in that essay, 14 months ago, is what we would now call micro-services.

That's the first time I've ever read it was hard to move from a collection of small services to a monolith, and easy to move from a monolith to small services.

Agreed, that seems totally backward from my experience. I notice no justification is given either, apart from describing both refactors (small->large and large->small).

> But when you move from the monolithic CMS to an architecture of small apps, there is no need for The Big Rewrite.

Uh, what? Maybe if your app is written The Right Way, but in cases where encapsulation and cohesion are poor, where do you begin splitting? Services, on the other hand, force encapsulation from the get-go. Why wouldn't it be easier to connect them -- it's what they designed to do.

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.

I found this to be a much better article than the OP since it is very focused on the practicalities.

The user "slyall" just submitted it:

https://news.ycombinator.com/item?id=8204826