How to maintain dependencies shared among microservices?

Question

There is a dependency jar containing tons of service classes mostly used to retrieve data from database, and this jar is used among several different micro services in one cluster.

There is a big problem in such architecture: once a new method is added to any of the service class in the dependency jar, it is next to impossible to change the method signature, since the method is used already by several microservices. This causes big maintenance cost on those service classes

Question: how to reduce the maintenance cost on the shared service jar? is there better alternative to share those service dependency jar among the microservices?

Answer 1

Combine the dependency and the cluster of micro-services into one monolith.

Adopting microservices should be about enabling independent development and deployment of individual parts, reducing interdependancies of work, and solving a problem that can't be solved in any other reasonable way.

It sounds like you aren't getting these benefits, since work on any one service probably often requires changes to that dependency. And since presumably the database is shared between the different microservices, all services will have to have a relatively recent version of the dependency at all times, as an old version would assume a database structure that no longer exists and not work.

So effectively you have to deploy the various services in near lockstep.

Combining them into a monolith would mean you deploy them exactly in lockstep, with a single command that deploys all of them together, and the possibility to easily run tests and static analysis in advance on each version of the monolith well before deploying it to production.

Changing a method signature at the method declaration and all method usages can then be done in a single commit, and often with an automatic refactoring command in an IDE.

(I don't know the OP's organization, so this answer may or may not be right for them, but I present it as an option to be considered and voted on)

Answer 2

Exported methods should be part of a stable API, which means that you never change the signature of a method once it is published, unless you create a new major version of the library.

If you use the semantic versioning terminology, addition of new backward compatible functionality, such as adding a new method, increases the minor version number when you publish that version. Clients of your library will normally specify which minimum minor version of a fixed major version they will need, and that's enough. They will continue to work with newer versions, as long as you keep the promise given by the semantic versioning rules.

If you make breaking changes to your library (such as removing previously exported methods, or changing signatures, or changing names), you need to create a new major version. Since old clients of your library will not know about this version, you will need to provide and maintain the latest minor version of that old version as long as those clients have not been migrated to the new version. This is normal, and the maintenance overhead for the old version should be minimal (it does not get any functional enhancements, you would just patch critical bugs, creating patch releases).

Answer 3

There really is no easy way to resolve this. The microservices are coupled at a much deeper layer than they should be. Reducing the maintenance cost means properly decoupling these things so that microservices are coupled to each other via web API endpoints or message brokers. You and your organization will need to reorient your perspective on code reuse.

Any change to a monolith requires the whole monolith to be deployed. As a result, it becomes very easy to couple code between modules in a monolith. Even loosely coupled code changes require the whole thing to be packaged, retested, and deployed. Microservices change the economics of coupling because coordinated deployments for multiple services are more costly in time and effort — the beating heart of your question. While shared libraries of code spanning wide swaths of behavior can be viable for a monolith architecture, microservices become even more complicated.

Instead of reusing code at a lower abstraction, for example sharing business classes or service classes, one entire microservice becomes the minimum unit of behavior that gets reused.

Get rid of the shared library.

This thing is a monolith disguised as a dependency.

The boundary of a microservice is defined by the business functions it serves, and the data for which the microservice should be considered the single source of truth. A microservice should wholly own a business process and the necessary data to perform that business process independently of other microservices. It's ok to copy data to other services, as long as those other services all agree on which one acts as the single source of truth for some particular data.

If one service needs to implement behavior owned by another service, then call the other service. Delegate that behavior to the service that owns that business process. Doing this allows you to remove the monolith service layer that leaves these services tangled and intertwined.

Of course, this is a tone deaf answer if your organization can't or is unwilling to support this separation. If this common dependency cannot be eliminated, then I wouldn't consider the ecosystem to be a microservices architecture. You will be stuck with versioned APIs or combining these microservices together. bdsl mentions this in their answer, but you aren't necessarily making a "monolith microservice". Remember the main characteristics of a microservice are that it is independently deployable and scalable. If you can combine these services and achieve that level of autonomy, you can still call it a microservice. It just might be a big one, that's all.

It's too bad that microservice has the word "micro" in it. Too often people equate microservices with tiny applications, and that is not the main characteristic. Smaller applications are a side effect of separating main lines of business functions into independently deployable and scalable units. The independently deployable and scalable unit becomes the unit of code reuse within your organization. Deeper levels of reuse often land you precisely where you are right now.

Answer 4

TL;DR: Change the signature and don't upgrade until ready.

I am, actually, in a similar situation at work, and it's an architecture I chose. In order to protect IP, our codebases are organized in the following way:

• A "public" codebase, to which every developer gets access to, which define common functionality, communication protocols, client libraries, etc... for all applications.
• Many "need-to-know" codebases, which are built atop the previous one.

Any change to the API of the public codebase requires a bit of integration work in the other codebases, and that's completely fine by us.

How it works:

• Dependency by commit, not version. Every release is a potentially breaking change, so no SemVer is used.
• Eager upgrade to affected applications in case of bugs.
• Lazy (deferred) upgrade to affected applications in case of functionality change/improvement; typically until the application actually needs to be changed for other reasons.

It does require commitment, and it does mean that sometimes you'd want to make a quick change to core functionality for an application that hasn't been upgraded in a while, and must first wade through unrelated integration changes.

It's a trade-off we accept so far, in exchange for the productivity we get out of the setup.

Answer 5

I think there are two main ways to think about this and how to deal with it.

One is that when you have a shared library in your code base, you need to really think about managing it the way an open-source library would be managed. It makes no sense to me to pretend like this is an unsolvable problem. Think about all the libraries that you use in a given application and all the other applications that use those libraries as well. We don't even know the authors and the other users in the vast majority of these cases. Building a shared library that is used and maintained by your own team has a lot of the same challenges but is a much simpler problem to solve. No professional developer would seriously suggest writing an entire application without any external dependencies. Suggesting that building and maintaining a shared lib on a much smaller scope is an intractable problem is just as ridiculous. Hans-Martin Mosner's answer has some practical advice relating to this. I've seen teams that cannot seem to move beyond copy-paste-modify approaches but don't let anyone convince you that is a sophisticated way to go about things.

The other thought is, if you are thinking of microservices as arbitrarily splitting up every endpoint/operation, perhaps consider a more (IMO) reasonable idea of microservices where you divide groups of related capabilities into mini-monoliths. That is, components of your design which operate on the same databases and/or are otherwise inherently intertwined with each other should be thought of as part of a single application, regardless of whether they are deployed independently. There are a lot of nonpragmatic recommendations in microservice literature which treat the benefits of independent deployment as inherently worth the costs. In many cases, this results in a lot of complication for little or no benefit. At this point, I think it's non-controversial to assert that blind adherence to a naive microservices model has resulted in a lot of poorly executed solutions and project failures.

Answer 6

Put all your code - services+libraries - in a monorepo

You've hit the classical problems with micro services. A better way would be to manage your project as a monorepo - a single repo, but managed with monorepo instrumentation so you don't problems associated with a less-well-managed monolith - dependency hell and others.

I found this site extremely well-written in describing the problem and suggested solutions: https://monorepo.tools

We use NX - one of the proposed monorep management tools - and it works great.

Answer 7

is there better alternative to share those service dependency jar among the microservices?

No, there isn't. Probably packaging method is package by tier and the entire service tier it is packaged in the service.jar. Packaging by feature might reduce the cost of service.jar maintenance by splitting the service.jar in archives with a reduced size thus improving the release cost, though the improvement will get lost in a new type of cost, the cost for administrating the versions matrix of micro services using services packaged by feature, it will be just a cost move around, without improvements on the overall cost. Package by feature might increase development flexibility that might increase the release frequency that might increase the revenue thus reducing the percentage from the revenue the service tier maintenance cost represents since the overall maintenance cost will barely change.