Difference between OSGi services and REST microservices
OSGi and microservices share the same architectural style but differ in their granularity. We actually used to call OSGi services microservices until the web stole that name. We now sometimes call them nanoservices.
The principle of (micro|nano)services is to tunnel the communications between modules through a gate with a well defined API. Since an API is, or at least should be, independent of the implementations you can change one module without affecting the other modules. One of the most important benefits is that designs of even large systems can remain understandable when looking at the service diagram. In a way, a service based design captures the essence of the system, leaving the details for the modules.
With web/micro services the gate is a communication endpoint (host:port for example) and protocol (REST for example). The API is defined informally or with something like Swagger/OpenAPI or SOAP.
OSGi defines a (nano) service as an object that is made available to other modules (bundles) to use. Java is used to define the API.
Since nanoservices are OSGi most important design primitive there is a lot of support to make them easy to work with. Interestingly, since the service registry is dynamic and reflective, it is quite straightforward to map a nanoservice to a microservice and vice versa. The OSGi Alliance standardized this in their model for distributed OSGi, the "Remote Service Admin". This specification allows you to take an OSGi nanoservice and map it to REST, SOAP, or other protocols.
Therefore, choosing OSGi allows you not only to defer the decision to support microservices, it also allows you to add microservices to your system afterwards. Having a unified architectural style for the most basic functions as well as the highest level functions makes systems easier to understand as well scale.
I don't think you're comparing apples to apples here. OSGI is an application architecture, while microservices is a distributed systems concept.
In my experience, microservices offer a number of benefits:
- Individual microservices are easy to deploy, test, and maintain.
- Microservices are language agnostic. That means you could write one microservice in python, another in javascript, a third in go, and a yet another in java.
- Microservices are easy to scale individually. That means that if one type of request is made more often than others, you could scale the microservice you need to, without scaling anything else in the system.
- Each microservice in your system owns its own data. This ensures clear boundaries and separation of concerns.
However, they also have some drawbacks:
- There are more infrastructure concerns when deploying.
- It's difficult to keep messaging between microservices clean and efficient.
- It's harder to do end-to-end testing on a system with many moving parts.
- There's more overhead in messaging. Instead of a call to another service being a direct method call, it needs to use HTTP or some other form of network communication.
There's a good article describing some of the differences here.