Microservices vs Shared Libraries

| by Jan Stenberg Follow 37 Followers on Sep 28, 2014. Estimated reading time: 1 minute |

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.

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

New Robert C. Post Clean Microservice Architecture by Valentin Tudor Mocanu

Re: New Robert C. Post Clean Microservice Architecture by Jean-Jacques Dubray

How could someone claim to know anything about Service Architecture, be it micro, zeta, clean, bloated, dirty or whatever, and not use the word "consistency" once, let alone explain how consistency is achieved in the above mentioned architecture?

As far as I am concerned that post is just another buzzword bingo post.

As soon as you transition from a "monolith" to something else, the C word pops in and will keep you awake at night. Who in the world could believe that "cLean" Architecture is nothing more than a Pipe Dream? Who in the world could believe that you can slice software in the same way people do with Salami? I mean really? in 2014, that's the best kind of discussion we can have about Software Architecture?

We have already wasted 7 years trying out REST for nothing, nobody has ever built so called RESTful services, the industry is now building APIs in a BYP mode (Bring Your own Protocol). Are we going to waste another 7 years to realize that no indeed software can't be sliced like Salami? How many more pretty PowerPoint Figures will we need to understand that Software Architecture is just a bit more than circles and rectangles, layers or slices?

Re: New Robert C. Post Clean Microservice Architecture by Valentin Tudor Mocanu

Well.. there are people that are making some clean code and if you reverse that code you can see some pretty rectangles.
About slices: it is possible, by functional cohesion and not by coupling the deployment solution with the functional part (there are distinct concerns that must be separated).

Re: New Robert C. Post Clean Microservice Architecture by Jean-Jacques Dubray

I have seen lots of code in my career and I can boil it down to two problems that even the cleanest code I have seen can't deal with:
- mediation
- consistency (in particular long running state management)

Even the cleanest of the cleanest code requires refactoring, that's when things start to get ugly without any kind of mediation. Versioning and dependency management kills the cleanest of the cleanest code, any day.

I have never seen a single code base (doesn't mean it does not exist) that manages long running state properly, yet that kind of state is everywhere, even a tweet has a long running lifecycle, and this reply too (4 min edit window). Writing long running service orchestration and compensating handlers in imperative code can't be made pretty, let alone maintainable.

In the last 15 years, I can't think of a hipster who has come to identify these issues as relevant to the symptoms they were fighting. They keep trying to apply 70s solution to 21st century problems. At best, they rehash CRUD without too much damage.

Ultimately, layered/centered architecture is flawed because we all know and understand that the a good chunk of the business logic has to repeat at every so called "layer" or "circle".

Are we going through another hot air cycle of software architecture? certainly looks like it. How could "consultants" resist teaching corny principles at $300/hour? All I can say buyer beware, it's not because the a principle was invented in the 70s that it still applies today (MVC, CRUD, Cohesion, Loose Coupling, and yes Functional Programming).

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

4 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you