I think there is not necessarily a decision between OSGi and microservice approach.
Instead (and this is what I think Todor also means) you can build each (or some) individual microservices on OSGi. To the outside it communicates using messaging or REST or any other useful protocol, internally it consists of OSGi μ-services that communicate really light weight. This architecture makes the most sense if your microservice style is towards system of systems (coarse grained microservices) that have minimal coupling to other microservices. Such a microservice often also contains a UI together with the logic. - In this approach each microservice is rather large so you can profit from the decoupling OSGi provides internally. - Using OSGi also makes it easier to move functionality from one microservice to the other if you find that you did the cuts wrong. (Which is not unusual) So I think it makes sense to start with a modular monolith and design it well. Then as you grow you split it into microservices as you see fit. With the new OSGi R7 specs around JAX-RS as well as the new requirement annotations creating and assembling such microservices in OSGi has become a lot easier than it used to be. So as actual advice for the system of Mohammed I propose the following steps: - Move from blueprint to DS to prepare you system for the future. This step is not absolutely necessary .. but I honestly see no big future for blueprint. - Attach external systems using JAX-RS whiteboard and messaging to get practice with it. Maybe do the remoting as a layer above the OSGi services. - Analyse where there is need to split up the system - Prepare the split by minimising dependencies where the cut needs to be and by separating the storage backends. (While still remaining in one process). Maybe even use REST or messaging to communicate inside the process to make the next step easier. - Then change the deployment to do the actual split to two release and deployment units. If you did the steps before well then this should be quite easy. So staying with OSGi might have some benefits. - There is less migration than going from OSGi to e.g. spring boot - You can stay longer inside one codebase and release unit. This makes it a lot easier to correct mistakes. - In the long run OSGi modularisation makes your code a lot more maintainable (if you do it well) Christian Am Fr., 10. Mai 2019 um 15:50 Uhr schrieb Andrei Dulvac via osgi-dev < osgi-dev@mail.osgi.org>: > I agree, but I still stand beside my statement that OSGi would be limited > in terms of decoupling and scalability, compared to what you could do with > separate process, if you get it right. And yes, huge footprint and overhead > (and risk) of defining APIs differently (like "REST APIs"), code > duplication. But in some situations (If you're Netflix or Uber), you might > trade that off for the extra bit that you don't get with OSGi. > >> -- >> > -- Christian Schneider http://www.liquid-reality.de Computer Scientist http://www.adobe.com
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
