January 16th, 2016
(written by lawrence krubner, however indented passages are often quotes). You can contact lawrence at: email@example.com
If you are actually able to build a well-structured monolith, you probably don’t need microservices in the first place. Which is OK! I definitely agree with Martin: You shouldn’t introduce the complexity of additional distribution into your system if you don’t have a very good reason for doing so.
(So what would be a good reason? There are many, but to me the most important one is to allow for fast, independent delivery of individual parts within a larger system. Microservices’ main benefit, in my view, is enabling parallel development by establishing a hard-to-cross boundary between different parts of your system. By doing this, you make it hard – or at least harder – to do the wrong thing: Namely, connecting parts that shouldn’t be connected, and coupling those that need to be connected too tightly. In theory, you don’t need microservices for this if you simply have the discipline to follow clear rules and establish clear boundaries within your monolithic application; in practice, I’ve found this to be the case only very rarely.)
But if you start with a monolith, the parts will become extremely tightly coupled to each other. That’s the very definition of a monolith. The parts will rely on features of the platform they all use. They’ll communicate based on abstractions that are shared because they all use the same libraries. They’ll communicate using means that are only available when they are hosted in the same process. And these are only the technical aspects! Far worse than that, the parts will (almost) freely share domain objects, rely on the same, shared persistence model, assume database transactions are readily available so that there’s no need for compensation … Even the very fact that it’s easy to refactor things and move them around – all in the convenience of your IDE’s view of a single project – is what makes it extremely hard to cut things apart again. It’s extremely hard to split up an existing monolith into separate pieces.