Skip to main content

Do Not Share Libraries Across Microservices

The major goodie of (micro)services is low coupling, i.e. isolation. Isolation of domains with bounded contexts; isolation of technology choices (one service will use a relational database while the other requires NoSQL); and finally, organizational isolation (different teams can work on different services with low friction).

But then, I have seen situations where it was decided to share some common libraries between all services within an organization. To me, it seems like a slippery slope on the way of losing the benefits of a service architecture.

If you are sharing a common entities library, then your bounded contexts are at risk of merging too much. If you are sharing a common utility library, then you are sharing technological choices, often dragging some external dependencies with specific versions which will make it hard to evolve services independently. You will also be introducing organizational friction as teams start to depend on each other's libraries.

Is the economy of scale through re-usability worth the trouble of sharing libraries? Paradoxically, the bigger the organization, the less so, as coordination costs increase exponentially.

Yes, in terms of performance, you will still be able to scale your services independently. But doing microservices is as much of an organizational/domain modeling pattern as of a technical/performance pattern. Do not lose the benefits of the former by sharing too much between services.

Comments

Popular posts from this blog

Scala - Execution Order when Mapping Over Twitter Futures

As Twitter Futures don't have the concept of ExecutionContext (unlike plain Scala Futures), it is at first hand hard to know what gets executed when and where...

One creates a Twitter Future by specifying the FuturePool in which it will run:
In this case, the content of the code-block will be scheduled to run immediately as the unbounded pool has no limit to the number of concurrently running tasks.

One can also create one's own FuturePool. For example, in the code example below, we create a FuturePool limited to two concurrent tasks:
Now, getting to the crux of the matter, the question is: in what pool does the code passed into the map function run?
Looking at the output copied at the end of the snippet, you will notice that it runs immediately after its corresponding Future has completed. The total number of active tasks stays limited to two, from which we can deduce that it gets run in the same thread pool as its Future.

Could one run the map statements in another pool? Yes…

In Defence of the Software Engineer

It is often argued that software engineers are not real engineers as they lack the credentials and formal methods required to claim the title. I will counter that, first of all, these statements are simply false; and second, that this argument relies on a mistaken notion of what it means to be an engineer.

The credentials part is the easiest to argue as I am myself a Qualified Engineer certified by the engineering certification authority of my country, the Commission des Titres d'Ingénieur. Consider me the living proof that it can be done!

Now, that we don't rely sufficiently on formal methods as a profession can be argued either way. Some software developers will reject the idea of being engineers and prefer to call themselves craftsmen. It is true that in many cases a software developer has to come with unique and creative solutions to a problem, making it hard to apply formal methods. On the other hand, a lot of software engineering is rigorous and has a wide overlap with c…

Scala Coding Exercise - A Recursive Implementation of an Immutable List

I recently got to code a list as an interview coding exercise from one of the FAANGs. I thought that it might be a good idea to post it there for future reference.

I went for a recursive and immutable implementation. It's quite naive and I would certainly not use it in production, but as an exercise it was fun writing it due to its elegance.

If you look at the list implementation in Scala 2.12, they went for an imperative solution for most methods... Elegance sometimes comes at too high a price in terms of performance!


So... Do I pass the Fizz Buzz test?