Yup.
Kind regards,
Peter Kriens
> On 9 May 2019, at 14:01, Boev, Todor via osgi-dev <osgi-dev@mail.osgi.org>
> wrote:
>
>> Others say you need to distribute based on your business domains, not on the
>> low level need to share some code
>>> But neither choice has an impact on the size of the (micro-) service
> I tend to disagree. Splitting along business domains (e.g. "product
> inventory") tends to require that the microservie is a full-blown,
> self-container, three-tier web application. It implies state and storage and
> more logic to integrate with other microservices (e.g. call "user management"
> for access control). If you split the service by "logic reuse" you may end up
> with something like "interest calculator" - a stateless generic piece of
> logic with one rest endpoint to take input and return output. This is better
> off as a library.
>
> So "well designed" microservies actually include a lot of stuff which in turn
> makes OSGi more attractive: rest sever, rest client, db access, sso,
> component runtime to integrate all of this... What people tend to do is to
> pick a set of these things they feel are generic enough, call it "the
> platform" or "the microservice chassis" and pay the cost of having it
> everywhere. Think of "MicroProfile" - it's a fixed set of things and try as
> they might to keep the list small it inevitably will bloat up with every
> subsequent release
>
> OSGi gives you a way out. The "platform" is actually a shared bundle
> repository and the OSGi build will put together for you exactly the pieces
> you need in each microservice. Then because each bundle is an independent
> unit with its own lifecycle they snap together just by being loaded into the
> OSGi runtime. If you try to escape the "platform syndrome" with plain maven
> for example you may be forced to provide the glue code yourself since outside
> OSGi code tends to be shared as libraries with the expectation that the user
> of the library will drive it's lifecycle. If you notice service dynamics are
> not used in this scenario yet they are an important tool to enable the
> bundles to hook together even though this happens only once at startup.
>
> In short you are right that for simple enough microservices plain maven and
> plain jars are simpler. However I believe this gets out of hand very quickly
> simply because the correct way to design microserviecs puts the bar of
> functionality (and footprint) pretty high.
>
> As an example I have built a microservice with REST, JDBC, SSO through JWT
> and some hello-world business logic in ~10 mb (the JVM excluded). Another
> microservie did not need the JDBC so it was ~8 MB. What came into the image
> was driven almost entirely by the requirements of my business code out of a
> common bundle repository.
>
> Regards
> -----------------------------------
> Todor Boev
> OSGi Platform
> Software AG
>
> From: Andrei Dulvac [mailto:dul...@apache.org]
> Sent: Monday, May 6, 2019 6:21 PM
> To: Boev, Todor; OSGi Developer Mail List
> Cc: Jürgen Albert; SMAIL LOUNES
> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
>
> This is a great and coherent answer and it made me think a lot.
>> Others say you need to distribute based on your business domains, not on
>> the low level need to share some code.
>
> But neither choice has an impact on the size of the (micro-) service
>
>> So microservice modularity runs orthogonally to in-process modularity.
>> Indeed you need efficient in-process modularity to build good microservces.
>
> What I meant when I said there's an overlap it's the modularisation part.
> Yes, with OSGi you can and might want to modularise your service further, but
> if you're going through the infra and ops cost of maintaining and deploying
> microservices, you can split down a larger service further into two
> microservices (if performance and the arch permits).
> And if your services are quite split already, how much benefits do the extra
> in-process modularisation bring you?
>
> Don't get me wrong, I love OSGi and, on top of that, I think it's actually a
> better way to start a project from a green field and make use of that
> modularisation. So start with a monolith in that strict sense (as you don't
> have the scalability part). And when you need all the advantages of
> microservices in the strict sense, your service is already modular (*) and
> you can just take out the part that needs to scale and make it a separate
> service that you can scale independently.
>
> A wise man once told me: "You will never get the architecture and domain
> boundaries right from the start with microservices"
>
> (*) As long as you future-proof a bit and don't make an architecture that
> assumes blindly that osgi services are sharing the process with other
> services.
>
> - Andrei
>
>
>
> On Fri, May 3, 2019 at 5:32 PM Boev, Todor via osgi-dev
> <osgi-dev@mail.osgi.org> wrote:
> I work on tools build OSGi-based microservices for the likes of K8S. By
> extension this includes thinking/experimenting to discover whether/how OSGi
> is applicable in these environments.
>
> One thing I noticed is that when you have a distributed application all of
> its pieces must coordinate their internal lifecycles across the network. This
> is more in the realm of communication between the microservices, rather than
> in the realm of deploying containers. For example K8S can maintain replicas
> of your containers, but this is for scalability rather than to create the
> illusion network calls can’t fail. The application running on top is expected
> to adapt on the fly. You really need good programming models.
>
> OSGi provides one elegant programming model. You already have services that
> coordinate their independent dynamic lifecycles. If you model an external
> entity as a service (e.g. a remote client object) you can hook your
> application internal state directly to it. Then use discovery to distribute
> knowledge when things are coming/going/relocating and have the distributed
> system keep itself in balance while K8S takes care of responding to load – it
> is a good fit.
>
> The other thing I have noticed is the inclination to think of microservices
> as a universal modularity solution. People brag about having hundreds of
> services with some consisting of one function. To share this one piece of
> code you seem to pay the cost of handling distribution, memory/cpu/network to
> maintain extra processes. This ultimately translates to paying raw money.
> While Martin Fawler promotes modularity through microservices he explicitly
> does not say where to stop if I remember correctly. Others say you need to
> distribute based on your business domains, not on the low level need to share
> some code. So microservice modularity runs orthogonally to in-process
> modularity. Indeed you need efficient in-process modularity to build good
> microservces.
>
> Here again OSGi can be a compelling solution since it tends to build really
> small footprint images, because it has deep understanding what each jar
> needs. This does not come for free – you need to describe your code well in
> the module metadata.
>
> The third thing I noticed is that it only really works well when you use
> simple/light OSGi components. Use http whiteboard, not web bundles. Use
> declarative services, not blueprint. And so on. Even if you use “traditional”
> distribution without the dynamic lifecycle it is still quite fun and OSGi has
> a lot to offer (e.g. JAX-RS whiteboard).
>
> So in general if you choose a microservice architecture and choose to build
> immutable small containers you are not at odds with OSGi. It actually can
> help. If you already have an OSGi application you can consider it a head
> start. You will have to refactor a lot to split your business logic into
> independent services, but you won’t refactor less if you were not OSGi based.
> Mohamed however mentioned he’d like to use ready-made solutions to implement
> application features and has issues with OSGi in that respect. What are they?
> OSGi can provide means to structure distributed applications, but it sure
> can’t provide an independent analog of every heavy-lifting framework out
> there.
> -----------------------------------
> Todor Boev
> OSGi Platform
> Software AG
>
> From: osgi-dev-boun...@mail.osgi.org [mailto:osgi-dev-boun...@mail.osgi.org]
> On Behalf Of Jurgen Albert via osgi-dev
> Sent: Friday, May 3, 2019 3:41 PM
> To: SMAIL LOUNES; OSGi Developer Mail List
> Subject: Re: [osgi-dev] Migrating from OSGI to Microservices
>
> Well, like I said: Kubernetes only knows and cares about Containers (Pods)
> and nothing about any application life cycle. You can define e.g.
> dependencies like an application container requires a container with a DB. So
> when someone triggers the start of your application container it will make
> sure that the DB container is started and as far as I remember will set the
> coordinates to the DB as system properties for you. However, It will not know
> the state of readyness of your application or the DB. As an example, we have
> search server tailor maid for one of our customers. On first start it
> rebuilds the index from the raw data in their DB. This can take a couple of
> minutes. For Kubernetes the container is up and running, but the server will
> not be available to answer queries until the index is ready.
>
> Thus, if you want to use the Kubernetes API to start a Pod for a specific
> services it you can do that, but everything else is not in its scope. It is
> just a convenient tool to manage an Infrastructure. The rest belongs to your
> application domain.
>
> Regards,
>
> Jürgen.
>
> Am 03/05/2019 um 14:16 schrieb SMAIL LOUNES:
> 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] 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 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
>
>
> --
>
>
> --
> 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
_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev
