Very good summary Todor. That would make a nice blog article :-) Christian
Am Do., 9. Mai 2019 um 14:01 Uhr schrieb Boev, Todor via osgi-dev < osgi-dev@mail.osgi.org>: > > 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 -- -- 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
