SOA for Internal Shared Libraries

SOA has the right principles for scalability with cohesion and consistency. Microservices are dying nowadays for several reasons like Lack of Isolation, Distributed Monolith & Shared Libs Abuse, and many other reasons such as the wrong boundaries. I deeply believe we need to double down in Services and SOA. Sometimes the Sidecar Pattern also makes sense and is an interesting approach.  However, there are times where we really need to go to Internal Shared Libraries.  When that's the case we can still apply SOA for Internal Shared Libraries and have a better a clean design such as having a clean CORE. Keep in mind there is a lot of shared libs abuse in companies but in the cases where internal shared libs are the right choice, there are some important considerations. SOA can philosophy can help internal shared libs to do better and by doing so we can have better solutions with much fewer headaches. I need to repeat Internal Shared Libs should not be your goto approach. Services should be your number 1 choice to deliver software.  

It's not about being a purist

So should we never ever use any lib and code in Java 1.2? NO. We should use libraries. We should use Frameworks. We should not re-invent the wheel. However, do we mind the dependencies we are imposing in people's classpath? Do we even realize how many jars we are adding there? That's the issue. There is a binary coupling, where upgrading libs is very hard. So the solution is not to go to the other extreme and say no libs any more, No that's not what I'm saying. We need to reach some middle ground where we need to Judge and analyze case by case. However, I need to say that we need to be much more RIGID and DISCIPLINED when come down to using shared libraries.  

Discipline is the key

The discipline is the key. We can copy and paste code from the internet on your CODE, that's 100% fine. We can also use plugging like SHADE and have a single jar with no dependencies. We can introduce dependencies as well as long as we are conscious and paying lots of attention to that. The whole java ecosystem of OSS libs often depend on Guava, People use guava a lot, guava is very hard to upgrade when you have different versions. NetflixOSS stack was very binary, Spring cloud used NetflixOSS and is even more binary. There is this effort to push reactive programming everywhere, meaning to call services you will need to use clients it would be impossible to do REST calls very soon. This is coming.  We should not trade performance for flexibility(never). 

So how can we fix this? Discipline is the answer. We need to Think, case by case, and analyze the options and make sound decisions. Changing one extreme for others is not the answer. We dont need to ban shared libs we need to be much much more disciplined about them. 

Functional Programing is about discipline as well(Discipline state management). DevOps, CI/CD are about discipline too, I should say there is no way you can get internal shared-libs right without discipline.

There is no Silver Bullet

There is no way we could create a single rule and have simple decisions we could just apply to all cases. Things are not that black/white we can't have a clear cut when we talk bout design and this particular libraries issue. In other words, there are no silver bullets. We need to fight complexity and all its forms and hidden costs. We need to stop creating Debt that kills us in the long term. So it's important to Reflect on old dogmas and sometimes the answer is an unpopular opinion. 

This is hard because it leaves us with no good default choice. If you are looking for a default choice should be serviced, not libraries. We have an obsession with Reuse. We should have an obsession with your consumers and freedom and isolation instead. The IT industry often takes a long time to see it's mistaken so just because few people are talking about(or you think is few people) it does not mean you should not pay attention.  Hopefully, we are just judging and making decisions by popularity.

Design Libs using SOA

SOA has principles. There is the SOA Manifesto. Jeff Bezos wrote in 2002 an SOA Mandate for Amazon. One way to see it is "Talk via Services not via Internal Shared Libs". 

SOA has Services. Services have Contracts and Implementations. The API in your Internal Shared Library should be your Contract. You should decouple you contract from your implementation and hide as many things as possibles. Doing so It's possible to apply SOA to Internal Shared Libraries. Which will give you more flexibility and less Intrusion to your lib consumers.  Proper versioning is also very important you should not break your consumers with MINOR and SECURITY/PATCH versions changes. IF you pay attention to your 3rd party libs you can make this possible. The benefits are countless such as:

  * Reduce the number of Lib Migration Efforts (Time and Money).

  * Increase the TRUST and IMAGE of your Platform team among your consumers.

  * Reduce the blast radius impact in your consumers via(3rd party deps and better contracts).

  * More time to Consumers focus on innovation + Increase the value of your solutions

  * More Freedon to change the Internal Shared Lib under the hood

  * Less coupling and more innovation for both sides (Provider and Consumers).

SOA is key for Better Designs and reducing complexity. SOA can be applied to Internal Shared libs and is not only a Service Thing. 

Cheers,

Diego Pacheco