It's not necessarily about one or the other. What you mention is the k8s control plane that can take over your traffic/scaling needs. However, the beauty of dynamic services on OSGi can be that you reflect the "as-is" service topology (controlled and managed by k8s). OSGi services can understand and adapt to the availability (or non-availability) dynamically. It gives you fine-grained control which leads to smarter services. They are not black and white anymore (on or off) but can help re-reoute, cache or otherwise mitigate short term changes in the service topology.
Note that this is complementary to remote services mentioned above. RSA help you partition your (micro-)services easier. Though i think the story is not as easy because.. you know.. the network is not reliable, etc. There is a lot more to this, and its a great discussion you are having here. And its up to your needs if you want smarter services or can live with cheap & dump instances (that ultimately leads you towards FaaS) - which can be totally fine. Toni Toni Menzel / rebaze consultancy Alleestrasse 25 / 30167 Hannover / Germany M +49 171 6520284 www.rebaze.com Software Engineering Therapy rebaze GmbH, Zollstrasse 6, 39114 Hannover, Germany Managing Director: Toni Menzel Phone: +49 <+49%2030%2054909582> 171 6520284 / E-Mail: h...@rebaze.com Registration Court: District Court of Stendal Registration Number: HRB 17993 Sales Tax (VAT) Registration Number: DE282233792 On Sat, May 11, 2019 at 10:05 PM Jürgen Albert via osgi-dev < osgi-dev@mail.osgi.org> wrote: > Depends on how you build your services. If you go the classic way, with a > normal HTTP API with e.g. docker compose or swarm, you would get load > balancing out of the box. They do a DNS round robin, the moment you scale a > service there. I believe Kubernetes does the same. The remote service Admin > does not really specify something like this. Here you can do the load > balancing on the application side. if you have e.g. 3 instances of the > billing container, you would find 3 service instances on your consumer > side. > > Am 11/05/2019 um 10:36 schrieb Andrei Dulvac: > > Hi Jürgen. > > Ok, I missed the context of your previous mail - how modularity helps even > if you have multiple containers. > > I get it... It's fast to develop and easy to switch boundaries. One other > thing that I have on my mind: in your example, how easy would it be to > scale the billing container? I assume it would be easy to route calls at > least through a load balancer (I am not at all familiar with e. g. JaxRS) > > I might start to consider again the whole idea of microservices and using > OSGi to modularize code inside them. > > > On Fri, May 10, 2019, 22:26 Jürgen Albert <j.alb...@data-in-motion.biz> > wrote: > >> Hi Andrej, >> >> I think you got us wrong. Nobody suggested to use OSGi or Http >> MIcroservices as you have called them. The Concepts behind both are >> modularity. The following Definition would fit both: >> >> The smallest unit is a module that defines Service APIs as Interaction >> points. >> >> Thus OSGi is the best tool to create Http Microservices. I would prefer >> Distributed Microservices because you don't necessarily need HTTP for the >> Communication between your containers/processes. You can split your Bundles >> over as many Containers as you like and I will guarantee that is it easier >> to achieve and maintain then with anything else. >> >> A short and every much simplyfied example to show what Todor was >> describing: >> >> We have a small application that provides a REST API for an shop order >> process. We have written the following bundles: >> >> rest.api -> contains the REST Resources; uses the order.api interfaces >> order.api -> contains the order service interfaces >> order.impl -> implementation of the order service, needs the billing.api >> interface >> billing.api -> contains the billing service interfaces >> billing.debit -> a billing implementation for debit card payment >> >> Scenario A - We want everything in one JVM: >> We throw this in one run configuration, let the resolver do its job, we >> would end up with one Framework, containing our bundles, the JaxRS >> Whiteboard, HttpWhiteboard some persistence stuff and e.g. some XML stuff >> for debit provider. Export a self executable jar and of you go. Because we >> can, we wrap it in a docker container to. >> >> Scenario B - We want the Billing stuff to run in its own process : >> >> We add the remote service properties to the billing service and create >> two run configurations. One names the rest.api and the order.impl, the >> other one contains only the billing.debit and a RSA (Remote Service Admin) >> Implementation for both. Resolve both, export both to their jars, wrap them >> in docker. The Service with the REST API now has the JaxRS Whiteboard, >> HttpWhiteboard some persistence, the RSA and the billing.api. The other one >> has only the billing.api, billing.impl, some XML Stuff and the RSA. >> Congratulations, we have our first containerized microservice environment >> ready. >> >> If you use OSGi everywhere, you will get containers that contain only >> what they need and nothing else. Ideally nobody needs to write any extra >> REST APIs for the internal communication. If you use OSGi Services as >> intended, you will already have the API bundles with the interfaces. As a >> developer, I don't necessarily need to give any thought If the service I >> use is a remote or a local service. The framework does it for me. If you >> want to use other languages for your containers you can even implement the >> RSA for them as well and communicate with the OSGi Containers. The RSA has >> no java specific part and you only need to get the serialisation >> compatible. >> >> The amount of flexibility OSGi gives you in such a scenario is priceless. >> If you have developers that think modular, you will get well structured >> bundles. So you can redraw the lines of you boundaries from logic to >> business and back with out much risk or effort. >> >> I haven't found a Framework that comes even close to what I can do with >> OSGi in half the time everybody else needs. >> >> Jürgen. >> >> Am 10/05/2019 um 15:50 schrieb Andrei Dulvac: >> >> >> >> On Thu, May 9, 2019 at 2:01 PM Boev, Todor <todor.b...@softwareag.com> >> 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). >> >> Right. What I meant is BOTH choices have an impact on the size of the >> microservice, and you can end up with a smaller service if you split by >> business domains than the boundaries of sharing code or the opposite. >> >> >>> 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. >>> >> Debatable. I personally think it's not better off as a library unless >> it's "complete" and I won't have to change it whenever I change my >> services. If I introduce new functionality and dimensions to my service and >> start differentiating offerings to my customers by e.g. age, i'd have to >> change the library and update it in all my services. >> If it's just applying a generic mathematical function (based on >> literature and with no ties to my business domain), of course it should be >> a library. Classic example is calendar or date libraries, where we should >> all use an open-source library, everywhere :) >> >> >>> >>> 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. >>> >> >> I fully accept your analysis of how OSGi gives you a lot of what http >> microservices designs give you. Like "each bundle is an independent unit >> with its own lifecycle". But it doesn't reach the same level of decoupling >> like doing them with separate processes. If you run microservices in >> separate processes, you can rewrite some of them in a different language, >> you can move one microservice in a different network, and, most >> importantly, you can scale them horizontally (maybe elastically) beyond >> what you could do in an OSGi instance >> >>> >>> 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. >>> >> >> I agree, but I still stand beside my statement that OSGi would be limited >> in terms of decoupling and scalability, compared to what you could do with >> separate process, if you get it right. And yes, huge footprint and overhead >> (and risk) of defining APIs differently (like "REST APIs"), code >> duplication. But in some situations (If you're Netflix or Uber), you might >> trade that off for the extra bit that you don't get with OSGi. >> >>> >>> 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 >>> >> >> -- >> 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 >> >> > -- > 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
