Difference between OSGi services and REST microservices [closed]

Question

OSGi talks about microservices and the press talks about microservices. However, they do not seem to be the same. What is the difference between these microservices.

Kawasaki

"is there anything i can do with micro services that i can not do with OSGI modules": You can solve lots of very complex issues (transactions, session handling, performance issues coming from the communication between nodes, etc.) that you would not have if you had not chosen microservices. – Astromancy

This question seems fine to me, I think it should be reopened. – Brocade

Answer 1

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.

Pathogenesis

Do you mean by "Having a unified architectural style for the most basic functions" with the help of OSGI and and "by highest level functions" with help of microservices? – Kawasaki

Making everything as microservice needs network call overhead so we should break up our high level functions into microservices and lower level basic functionalities with the help of OSGI. Hence we can use mix up approach to avoid network call overhead – Kawasaki

Correct. OSGi allows you to work not only with one paradigm but also with the same code constructs to do low level stuff and high level stuff. I.e. a REST API becomes a choice. – Pathogenesis

err ... is this not the description of an good old RPC system? replace "nano service" with "remote procedure" ...The "gate" reason of existence seems not clear? Is that a logical unit aka clustering of micro services or a technical necessity? by the way I like your level of abstraction and consistent definitions. In case it seems I don't. – Swihart

actually this might also be a description of a SmallTalk runtime environemnt, but with different terminology. Objects + messages, SmallTalk concept, seems a lot like micro/nano services to me .. Ah well again it is good to know a bit of a history supporting your architecture. – Swihart

@ChefGladiator you are missing a crucial part and that Microservices are brokered. There is a dynamic publish, discover, bind cycle. This is quite different from the object oriented technology that you are referring to. – Pathogenesis

@PeterKriens you know I am not "missing it" regardless of not mentioning it :) Distributed system == brokering. SmallTalk run-time are Objects that are "brokered" IMHO. SmallTalk is distributed system, although AFAIK with no remotes. RPC is of course brokered; "heavily". RPC is still in the "core of everything" but fiendishly difficult to use. No sane person will develop business systems using RPC. -- I like your (and your coworkers) classification and formalization and work in general. Peace. – Swihart

Answer 2

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:

1. Individual microservices are easy to deploy, test, and maintain.
2. 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.
3. 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.
4. Each microservice in your system owns its own data. This ensures clear boundaries and separation of concerns.

However, they also have some drawbacks:

1. There are more infrastructure concerns when deploying.
2. It's difficult to keep messaging between microservices clean and efficient.
3. It's harder to do end-to-end testing on a system with many moving parts.
4. 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.

Soble

I'd say that from your list of benefits, only number 2 (language agnosticism) is actually a limitation of OSGi microservices versus process microservices. OSGi microservices are independently deployable, independently scalable, can own their data. They are currently limited though to the JVM and languages that run on the JVM: Java, Scala, Groovy, Closure, JRuby, etc. – Midvictorian