During the last months many have claimed that a microservices architecture should always start with a monolith, among others Martin Fowler and Sam Newman, but Stefan Tilkov is convinced this is often wrong, building a well-structured monolith with cleanly separated modules that later may be moved out as microservices is in most cases extremely hard, if not impossible.
Tilkov, co-founder and principal consultant at innoQ, agrees though with the idea that distributed system should only be selected when there are reasons for doing so. For him the most important reason is enabling fast and independently delivery of individual parts of a large system. He believes that the main benefit for microservices are creating clear and strict boundaries between different parts of a system, minimizing the risk of connecting disparate parts which would increase the coupling. He notes that this is possible also with a monolith using strong discipline but in his experience this is rarely happening.
For Tilkov the basic idea of a monolith is to couple things to each other. From a technical view all parts are using the same platform, abstractions and libraries with communication based on everything being in the same process. From a business perspective all domain objects are available everywhere, the same persistence model is used with transactions always available to span over all changes made. All these are facts that for him increase the coupling and he again emphasizes that it’s extremely hard to pull apart an existing monolith.
Instead of always starting with a monolithic design Tilkov believes that when a system is large enough we from the beginning should think about individual subsystems, building them as autonomous as possible.
As an example of a system made up by microservices Tilkov refers to Otto.de, a German e-commerce site, about which he held a presentation at QCon London last year.
Tilkov earlier compared characteristics of different types of systems and coined the term Self-Contained System (SCS) to describe an autonomous service significantly larger than a microservice but still responsible only for one specific business domain.
