OSGi After 20 Years

Post written by Peter Kriens, OSGi Fellow and CEO of aQute SARL 

Looking at the current adoption of microservices it is hard to not think, "We told you so 20 years ago!” The reason why microservices work so well is it provides a well-defined API entry point into a module. The caller has a dependency to an API but can ignore the messy details of how that API is implemented; and even more important, what kind of dependencies that module has. Since software complexity grows exponentially with the number dependencies reduction in complexity can be humongous.

This is exactly the core idea of the OSGi service model we developed already 20 years ago, long before REST was a well-known term. Does that mean that OSGi can be retired since its architecture has become an overnight success? I don't think so because OSGi has one humongous advantage over REST services: choice.

OSGi applications are structured as nano-services. Nano services follow the architectural rules of the micro-services but have a much lighter weight. Calling a nano-service has no overhead, unlike calling a micro-service. The good news is that well-designed nano-services can easily be upgraded to micro-services with no impact on the implementations. This makes it possible to start simple in a simple container and then gradually promote nano-services to micro-services in other containers. No other environments but OSGi makes it so easy to do this kind of migration.

I point out this clear advantage of OSGi because it is so recognizable for every OSGi developer. However, when you use OSGi in anger you also learn that it provides more advantages. OSGi provides the plumbing that puts you in control of your development process in a way that I've not seen anywhere else. Few people outside the OSGi even remotely understand the requirements and capability model, and that is their loss. However, organizations that reach the maturity level to use it will never let it go.

Last week, we had the perfect example. One designer had made a change to the runtime setup and 10 minutes later the CI build failed because he had forgotten a crucial capability that was used in one of the hundreds of bundles. Something that might not have been found until the code had been deployed to hundreds of thousands of gateways. OSGi provides the type safety between modules that Java provides between classes.

Being the first in the Java market to do modularity we've taken a lot of bad rap for problems caused by the nature of modularity. JPMS has by now shown that modularity is not a secret sauce that can be sprinkled over a code base. And yes, there is a certain amount of vindication.

To reach modularity maturity requires hard work because our industry has a surprising number of unmodular practices. However, as I can see with my customers, OSGi does deliver when you apply it as it was intended. The road to maturity is a drag but once you're on cruise level, it is indeed very smooth flying.