Hello Jürgen

Yes I  agree with you, that a microservice architecture has become a
fashion more than a technology, in itself, and a lot of projects ended up
failing,
this is why we're tryin to find out how new microservice architecture could
be more efficient for our business need and if it will bring a real added
value to our projets.
 in other hand,   , we use maven-bundle-plugin (apache.Felix) to build our
osgi jars and when you deduce that we use an older vesion of osgi  because
we use Blueprint, do you recommand that we replace it by DS when we upgrade
our karaf version, now we use Karaf 4.0.6
regarding BND tools, honestly I don't see the added value that can bring in
OSGI project (except testing).

Regards,

Mohamed

Le ven. 3 mai 2019 à 13:25, <osgi-dev-requ...@mail.osgi.org> a écrit :

> Send osgi-dev mailing list submissions to
>         osgi-dev@mail.osgi.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
>         https://mail.osgi.org/mailman/listinfo/osgi-dev
> or, via email, send a message with subject or body 'help' to
>         osgi-dev-requ...@mail.osgi.org
>
> You can reach the person managing the list at
>         osgi-dev-ow...@mail.osgi.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of osgi-dev digest..."
>
>
> Today's Topics:
>
>    1. Re: Migrating from OSGI to Microservices (Scott Lewis)
>    2. Re: Migrating from OSGI to Microservices (Mohamed AFIF)
>    3. Re: Migrating from OSGI to Microservices (J?rgen Albert)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 2 May 2019 09:55:20 -0700
> From: Scott Lewis <sle...@composent.com>
> To: osgi-dev@mail.osgi.org
> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
> Message-ID: <5e8a5823-f3d1-3a0e-543b-ee4389c0f...@composent.com>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> Another option is to use OSGi Remote Services [A].
>
> Some implementations allow use of both Jaxrs or non-Jaxrs (e.g. legacy)
> REST providers [B].
>
> Scott
>
> [A]
> https://osgi.org/specification/osgi.cmpn/7.0.0/service.remoteservices.html
>
> [B] https://wiki.eclipse.org/Distribution_Providers
>
>
> On 5/2/2019 7:51 AM, BJ Hargrave via osgi-dev wrote:
> > With OSGi's JAX-RS support [1], you can easily publish and consume
> > RESTy endpoints in your OSGi application.
> > So there is no need to "leave" OSGi to participate in a microservice
> > environment.
> > [1]:
> > https://osgi.org/specification/osgi.enterprise/7.0.0/service.jaxrs.html
> > --
> >
> > BJ Hargrave
> > Senior Technical Staff Member, IBM // office: +1 386 848 1781
> > OSGi Fellow and CTO of the OSGi Alliance // mobile: +1 386 848 3788
> > hargr...@us.ibm.com
> >
> >     ----- Original message -----
> >     From: Neil Bartlett via osgi-dev <osgi-dev@mail.osgi.org>
> >     Sent by: osgi-dev-boun...@mail.osgi.org
> >     To: Mohamed AFIF <afif.moha...@gmail.com>, OSGi Developer Mail
> >     List <osgi-dev@mail.osgi.org>
> >     Cc:
> >     Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
> >     Date: Thu, May 2, 2019 6:37 AM
> >     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
> >     https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
> >
> > _______________________________________________
> > OSGi Developer Mail List
> > osgi-dev@mail.osgi.org
> > https://mail.osgi.org/mailman/listinfo/osgi-dev
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.osgi.org/pipermail/osgi-dev/attachments/20190502/828c915f/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 2
> Date: Fri, 3 May 2019 10:57:29 +0200
> From: Mohamed AFIF <afif.moha...@gmail.com>
> To: Andrei Dulvac <dul...@apache.org>
> Cc: OSGi Developer Mail List <osgi-dev@mail.osgi.org>
> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
> Message-ID:
>         <
> ca+h-v5ouzzmdgno9mrpw0bfnmb+psqw93uhnqzba-35esys...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> 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> 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> 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> 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
> >>> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >>
> >> _______________________________________________
> >> OSGi Developer Mail List
> >> osgi-dev@mail.osgi.org
> >> https://mail.osgi.org/mailman/listinfo/osgi-dev
> >
> >
>
> --
>
> Cdt
> Mohamed AFIF
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.osgi.org/pipermail/osgi-dev/attachments/20190503/926b7ab7/attachment-0001.html
> >
>
> ------------------------------
>
> Message: 3
> Date: Fri, 3 May 2019 13:25:31 +0200
> From: J?rgen Albert <j.alb...@data-in-motion.biz>
> To: osgi-dev@mail.osgi.org
> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
> Message-ID: <e3336ebd-37c3-8c90-9981-dc70082d0...@data-in-motion.biz>
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> 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
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <
> http://mail.osgi.org/pipermail/osgi-dev/attachments/20190503/71689492/attachment.html
> >
>
> ------------------------------
>
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev
>
> End of osgi-dev Digest, Vol 151, Issue 3
> ****************************************
>


-- 

Cdt
Mohamed AFIF
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to