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 > >
_______________________________________________ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
