Shared Libraries in Microservices

[dermidgen]

Talk amongst yourselves. I'll give you a topic. G'head and search using shared libraries in microservices. It's not a great idea. Sometimes, you just can't avoid it. Microservices that share code are neither microservices nor monoliths... Discuss...

[mentalisttraceur]

I haven't yet formed an opinion or read anything, but as a data point, the first result when searching "using shared libraries in microservices" on duckduckgo.com is currently this blog post called Why "Don't Use Shared Libraries in Microservices" is Bad Advice.

[dermidgen]

I think I would generally agree with those points. I think the advice typically speaks to the issue "I want to share this piece of code I wrote with all my services, I don't wanna copy/paste it 30 times". This article does a good job breaking that down - but I would also suggest he's not addressing the main concern that folks have when they want to do this behavior.

Shared code isn't inherently bad. Microservices that share code isn't inherently bad. It's really more about how you implement this sharing and how does that implementation support each context: local dev, testing, CI/CD, deploy targets, etc.

[mentalisttraceur]

What's the difference between two of our microservices using shared code, versus them both using an external library?

I think those differences will determine if using shared code in microservices is a good idea or not.

(This is me just thinking before reading anyone's takes for now.)

[mentalisttraceur]

The main similarity is that both shared code and shared external libraries are both fundamentally just reusable pieces of logic, and obviously "don't share code between microservices" cannot be an absolute - no one's saying we should be rewriting minimal kernels for every microservice, rolling our own TLS libraries, and certainly not reusing libraries like requests from PyPI.

So clearly the problem isn't the sharing of code in itself, but something about the sharing.

[mentalisttraceur]

So, we accept sharing mature external code which abstracts enough important complexity behind a good-enough API.

Now, in particular, does it being external make it less microservice-y?

1. Do we care if it comes from a public repo versus a privately hosted repo?

2. Do we care if the authors and maintainers are members of our team, project, or organization?

3. Do we care if the outside world also has access to use it?

I think the answer is clearly no. Imagine a polished, cleanly decoupled Python library like requests, pydantic, or numpy. If you download a dependency from a local private cache instead of PyPI, your microservice is no less or worse of a microservice. If you wrote such a library, and a microservice uses that library, whether or not you wrote that microservice doesn't make it less or worse of a microservice. If one of those libraries suddenly disappears from the public, and you maintain a private copy so that your microservice still works, your microservice does not suddenly become less or worse of a microservice.

So clearly the problem isn't the code being private or internal. If the private shared code is a good stand-alone library, then it's fine.

But maybe something about it being private code makes it more likely that the code sharing ends up being problematic.

[dermidgen]

Here's an additional context to consider, versioning.

Let's say you've got 10 services doing some kind of real-time event processing.
Each service can bind to requests or numpy at a specific version and there's no hard requirement that there's version alignment amongst the services. That can be enforced by policy - but it's not a requirement for build/release/deploy.

If we're using a "shared library", where all 10 services are bound, what is the desired behavior? When you make a change to the "shared library" does it mean all services have to be rebuilt and their versions bumped? Should services be able to independently pin to a "version" of the "shared library" - or is it basically unversioned and every time a service builds it includes the latest of the "shared library"? There's real use cases for both situations.

Consider if 3 services all need numpy but all 10 need access to your shared/custom/private event-stream. Should you publish a private event-stream package? Open your event-stream to the public? Should be iterated, tested and versioned independently? Should all services be pinned to a specific version of event-stream or just pull in the code from another path in the repo? Should you even pull code in or build it separately and install the package (binaries/wheels/whatever)?

I find that inexperienced teams like to use a "shared library" approach at first - very often for configuration so that they can "push" configuration changes to their whole stack. Typically, this works enough to lure teams in but ends up creating all kinds of issues that force teams to get real and adopt configuration management that is independent of code. If they've been doing it with application code, they often reach a point where they can't fix bugs or make changes in shared code without breaking/refactoring all dependent services all at once.

These are often the pain points described when discussing why shared libraries in microservices make them ... no longer independent microservices but a monolith of interdependent services and shared code.

I don't necessarily believe that's true. This repo shows a path where you can potentially mitigate these risks, behave in a truly microservices way, and still share code sanely. Of course a naive team could abuse this to get themselves in dependency hell, but it should at least be a good discussion point with some simple scaffolded examples to consider.

[mentalisttraceur]

I think I have a good summary: the danger is risk of excessive coupling to a microservice's implementation, which is encouraged by convenience when code is shared within a project and is enabled by freedom when code is not shared outside a project.

So the three-part test I would go with for determining how problematic code sharing between microservices is:

1. Does the shared code cause excessive coupling between our microservices?

2. Would it be easier to add excessive coupling through the shared code, than to notice or code a better solution?

3. Can we get away with excessive coupling due to the shared code, or will broader reuse prevent it?

How to determine "excessive"? I'd start by looking at how my microservices are glued together. If two microservices are passing messages between each other, then they're necessarily coupled because their messages need to be compatible. So sharing code which encodes/decodes or serializes/deserializes those messages would not be excessive. In fact code sharing is good in that case because it helps make it obvious or at least discoverable that you can't change one without breaking the other.

The convenience of code sharing creates risk because it can create situations where for example switching from json to pickle is the easiest or most mentally accessible solution for some developer. A new requirement comes along for these two microservices to pass binary blobs in their messages, and a developer might not care, know, remember, or think to check that pickle is a Python-specific format and thus creates more coupling than needed.

If the "shared" code is public, or at least gets used by multiple teams, then it is resistant to such changes. A developer might really want to change json to pickle, but as we dial up the amount and risk of breakages and complains from that introducing excessive coupling, we also dial up the likelyhood that the developer will figure out a way to do it with less coupling.

[mentalisttraceur]

I don't have great wording to weave your versioning addition into that summary more explicitly, but you're extremely on-point, I'm glad you brought it up, and I feel like it's very closely connected.

I'm tempted to say that inability to use different versions, whether that's due to

• always grabbing whatever is currently at a specific path in the repo, or
• unintended breakages when trying to use different versions

is itself either a form or symptom of excessive coupling somehow somewhere.