As we grow our application portfolio, we soon discover common bits of code used by two or more applications. Often our first reaction is to break these common bits out into shared libraries. If you’re still using an application server, you might even put these libraries in the server itself so other applications can pick them up. After all, why repeat yourself? Certainly there are situations where that makes a lot of sense. Improved application startup time is one benefit. But not always. Sometimes these shared libraries actually hinder your team’s ability to deliver working software. Here I’ll explain why there is such thing as too much sharing.
Don’t Repeat Yourself
Common bits of low-level functionality often find their way into shared libraries, such as String manipulation, collection wrangling, etc. Think of the Apache Commons set of libraries. Moving up the stack, functions like JMS publishing and subscribing, authentication and authorization end up in their own libraries. Even our own in-house routines that call these functions might be candidates for putting into a shared library.
Shared libraries do make sense from a code duplication perspective. Why repeat yourself by hand-coding the same piece of functionality in several applications? Stick it into a shared library, include it as a dependency, and let the developers call the appropriate function in the library. Let them focus on solving the business problem.
Applications Evolve at Different Cadences
Here’s the thing, applications do not evolve at the same pace. Some are updated every month or two in response to changing business requirements. Others may not need to be touched for a year or two because, well, they work just fine thank you. Let’s suppose your application server mandates the use of v1.2.1 of our-common-lib, but one application now needs v1.5.6 to use some new functionality in there to solve a particular problem. Now you have a problem.
You could replace the old version of corp-common-lib with the new one, but now that has an impact on any other app residing in the application server that uses corp-common-lib. You now have to update each tenant app to use v1.5.6 of corp-common-lib. Prudence demands you test all these tenant applications to prove there are no side-effects. Your scope has just blown out because a change to one app has also caught a bunch of other innocent apps in its net.
Think Carefully Before Sharing
Before succumbing to the temptation of moving code into a common shared library in your application server, think about how it will evolve. Think about the other applications that use that library. It just might make more sense to bundle corp-common-lib with each application instead having one copy for all tenant applications. Sure, that means the library is loaded once for each application in the server, leading to duplication in that respect. But it can give you the flexibility and the agility to evolve each application at their own pace in some degree of isolation.
As with everything else in software architecture, the right answer depends on the context. Think carefully about your team’s context before deciding which way to go. There is such a thing as too much sharing.