Hi Mohamed,
I had the fortune and in parts misfortune of being part of a few such
migration projects. Besides our own internal one, everyone decided
against OSGi. The descension was always because of personal resentment
and/or because everybody had his personal favourite toy they wanted to
play with. The reasons ranged from " We don't want to use Eclipse"
(enroute with maven wasn't available at the time) over "We want spring
because we don't understand OSGi and it seems to complicated" to " Java
is outdated, we want to build it with NodeJS". They all jumped on the
Martin Fowler approach without really considering what it means in the
end. Each ended in disaster or went through a hard phase of near
disaster with jobs and reputations on the line. Most ended up with
something OSGiish with a lot of the pain going along with modularity but
missing most of its benefits.
The issue is complex but we Identified one main reason:
Modularity is an abstract concept for many developers. Spring for
example does not really teach and force a developer to think in a
modular fashion. All I saw was a bunch of smaller Monoliths packed in
Docker containers. The dynamic nature of a Microservice environment OSGi
addresses with its Bundle and Service life cycle , was pushed in the
realm of Kubernetes. But Kubernetes (or comparable Systems) is made for
managing your Containers and not for any application and service life
cycle. Thus one needs at least a few Developers/Architects that have
modularity internalised and address issues early on.
Another issue with the Martin Fowler approach you have already
addressed. A fully distributed system comes with a lot of different
problems (e.g. caches). Also the point of network latency and the time
serialization and deserialization is an underestimated issue.
Like Neil stated: If you are already have an OSGi application you
already have a microservice architecture, but maybe no distributed one.
The way to go is build a good microservice monolith (or modulith, like
it is called nowadays) and then move only the services to there own
containers, that really need scaling. Graham Charters talk from the 2016
EclipseCon Europe addresses this quite nicely:
https://de.slideshare.net/mfrancis/microservices-osgi-better-together-graham-charters
By your mention of blueprint, I deduct that you might use an older
version of OSGi. Our internal project was somewhat similar and we
managed to go distributed without major problems. We migrated to the
latest OSGi Version and used bnd instead of PDE. Later we moved some
service to there own container. It worked like charm. We could even show
the process to a customer, with zero downtime, by pulling up the new
containers and removing bundles with the local service implementations
while the system was running.
Regarding your point of finding/keep OSGi developers: This is something
we are confronted with rather often. The best way get developers sold on
OSGi is using the latest version of it together with bnd (pure or with
the maven integration). The development speed you can reach and maintain
even in complex applications makes most other Java developers jealous
and interested to learn more.
Regards,
Jürgen.
Am 03/05/2019 um 10:57 schrieb Mohamed AFIF via osgi-dev:
Hi Andrei,
My question had as aim to collect some experiences of suchs migrations
if this exist, we're in brainstorming phase and I'm not making any
judgement value about OSGI or microservices architecture, but what we
push to believe that we should probely move toward another technology,
is: the business requirement, indeed we want to expose our service to
clients as API, and the several technical complications we 've ve been
faced to everytime we want to implement a feature easily provided and
could be implemented by other open framework in the market, there is
also the Human ressource question is involved beacause it's not easy
find/keep OSGI developers.
personaly I think that OSGI is a perfect tehcnology for servers or
embedded system, but I've some doubt when it's regarding applications
with open architectures, it's my own view and I could be wrong
Regards
Mohamed.
@Neil
Obviously a simple
Le jeu. 2 mai 2019 à 16:52, Andrei Dulvac <dul...@apache.org
<mailto:dul...@apache.org>> a écrit :
Hi Mohamed, Neil.
Neil, while I agree with you, I think Mohamed means it in the more
"modern", widely-accepted sense:
https://martinfowler.com/articles/microservices.html
"""
In short, the microservice architectural style [1]
<https://martinfowler.com/articles/microservices.html#footnote-etymology>
is an approach to developing a single application as a suite of
small services, each running in its own process and communicating
with lightweight mechanisms, often an HTTP resource API.
"""
Mohamed, I'm curious what you end up with. Without getting too
much into it, I dismissed the idea as something "not worth it".
- Andrei
On Thu, May 2, 2019 at 12:37 PM Neil Bartlett via osgi-dev
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
Well the good news is that OSGi is already a microservice
architecture, so you have already finished. Congratulations!
If that answer doesn't quite satisfy you, maybe you'd like to
describe in more detail what you are attempting to achieve and
why?
Regards,
Neil
On Thu, 2 May 2019 at 11:06, Mohamed AFIF via osgi-dev
<osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>> wrote:
Hello everybody,
We 're starting to study the possibility to transform our
architcteure in order to migrate from OSGI to microservice
architecture, and I would like to know if there is alreay
some people who had thought about this subject or already
start this migration.
Because at first sight it would not be an easy task, many
problems/issues we will be facing to them (blueprint
injections, managing ditrubued caches instead of one cache
in one JVM...)
Many thanks
--
Cdt
Mohamed AFIF
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org <mailto:osgi-dev@mail.osgi.org>
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Cdt
Mohamed AFIF
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
--
Jürgen Albert
Geschäftsführer
Data In Motion Consulting GmbH
Kahlaische Str. 4
07745 Jena
Mobil: 0157-72521634
E-Mail: j.alb...@datainmotion.de
Web: www.datainmotion.de
XING: https://www.xing.com/profile/Juergen_Albert5
Rechtliches
Jena HBR 513025
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
