Thank you for this remarkable answer, I'm working on a research project about developping a highly distributed and dynamic communication platform, so we're looknig for using kubernetes to manage µservices life cycle, osgi is a condidate too. we can use an osgi container to deploy some µservices.. do you have an idea about using kubernetes for life cycle mangement and how integrate it's API
Thank you so much, Best regards Le ven. 3 mai 2019 à 12:25, Jürgen Albert via osgi-dev < osgi-dev@mail.osgi.org> a écrit : > 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> 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 > > _______________________________________________ > OSGi Developer Mail > listosgi-...@mail.osgi.orghttps://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 --
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
