[efsavage]

There are two ways to think about microservices. Development (which your comment focuses on) and deployment. The pure/idealized microservice is isolated from the rest of your environment/codebase on both of those axes. In practice, there will be some coupling on both, and perhaps one of those isn't isolated at all.

The monolith is simply the opposite of the microservice ideal, it is heavily coupled in both development and deployment.

And yes, DRY does often run counter to the development isolation, as you need to balance repeating yourself or sharing code (and reducing isolation).

As these things generally go, any system in contact with the real world will exist somewhere between the monolith and a federation of microservices. My current company, for example, employs 2 distinct codebases, Java and JavaScript, which have 3 and 2 deployments respectively, each in two similar-but-not-the-same environments (in-house and white-label). We could easily split those deployments into twice or 5x the number, we could also join them, this just happens to be where things naturally settled for the time being.

[tracker1]

There's an additional aspect... Types of load (compute vs i/o)... I'm currently building a system where node/iojs is the primary application runtime. In this case, separating those portions of the application that are compute heavy (resizing images, recalculating values, etc) are offloaded, beyond that I have separated the backend data into discrete containers based on collections of data/types... that which is related to an account, vs that which is related to a user/profile (and authentication)... which makes a bit more sense. I also separate the authorization as a service layer above backing logic.

UI (shared client/server codebase), WebAPI (ui access, auth filtering), DataAPI (used from WebAPI), Profile Service (users/auth), Account Service (core data), Image Service (backs upload/resize) and various backing pieces... for me I didn't break things up into too fine grained pieces, but wanted breaks based on type of work and/or data.

It really just depends on your workload.

[grandalf]

Makes sense. I typically try to design things so that they are initially joined (for convenience) but can easily be split off -- such as a simple router between micro-apps which can be replaced by haproxy (or similar) later.

[anezvigin]

I like this too and usually do the same in the application layer for new projects (though it takes more discipline).

Every module is built with the intent of breaking away later. Disallowing intra-module communication is essential to this. That means no global ORMs or global anything really.