BT
x Share your thoughts on trends and content!

Microservices vs Shared Libraries

by Jan Stenberg on Sep 28, 2014 |

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

Relevance
Style

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
General Feedback
Bugs
Advertising
Editorial
Marketing
InfoQ.com and all content copyright © 2006-2016 C4Media Inc. InfoQ.com hosted at Contegix, the best ISP we've ever worked with.
Privacy policy
BT

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.