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.
