Start with shared libraries and a plugin architecture and only when that becomes insufficient consider introducing services boundaries and microservices is Robert C. Martin’s advice in a recent article. In a response Giorgio Sironi argues against this, emphasising how different interactions between microservices are compared to interactions between objects inside a single application and warns for the cost of retrofitting microservices over an existing code base.
Robert, (Uncle Bob), describes microservices as small standalone executables that talk to each other, a common way using http and REST, with advantages including the ability to test smaller parts, flexibility in deployment and freedom selecting data storage and other infrastructure components for each service. Robert summarises this as Independent Deployability, but argues that by using shared libraries, e.g. jar files or DLLs, which are loaded and linked at runtime, it’s possible to achieve many of the same advantages. One disadvantage using microservices that Robert emphasizes is that communication between services over e.g. sockets takes much longer time compared to talking directly to objects inside shared libraries.
Robert notes that he’s not totally against microservices but that they should be used judiciously, often shared libraries is more than adequate thus avoiding the increased cost in communication between processes.
Giorgio, a developer in Italy, mentions other advantages he sees for using microservices; services can be scaled independently from each other and written in different languages. He also finds it easier to spot servers with a high load that may need replacement and believes they also simplifies implementation improvements; just replace a microservice with a new one.
Giorgio notes the negative impact synchronous calls may have on distributed systems referring to a paper written in 1996. He instead prefers to use a Command and Event style of integration for microservices which makes their public interfaces very different from the ones objects expose, thereby arguing against Roberts’s advice of always starting with a plugin architecture.
In a recent twitter feed Robert claimed that “Monolith vs Microservice is a false dichotomy” which started a discussion among several participants.
Peter Kriens earlier this year claimed to have defined OSGi µservices as a service that always communicates within the same process already four years ago.
