Howdy Christian, J-B, et al…. I’ve been working on such a thing for the last few weeks in a cloud of shelter-in-place frustration, and I believe I can donate what I have if it’s helpful at all (otherwise, I’ll be very interested in what you have to see how it differs). I had that moment of glorious arrival on Friday when my bundle finally deployed in gogo and the diagnostic print from my activation routine printed to System.out.
Now, for my stuff, it’s currently a bit of what a former Irish company president of mine would call a “dog’s dinner”, since I have tons of redundant export-package references and such to remove. I also am thinking the well-established packages (like the ones pulled from referencing the felix obr repository) do really want to remain separate bundles, just cleanly pulled in and activated at the time of REST/microservice deploy (which is what mine is doing). Really, what I did was to consolidate other examples I had, none of which built or activated properly on Felix 6.0.3 for me and I got frustrated and created my own which did after a moderate amount of struggle. Also, mine is about 50% Apache Jersey (which might be reduandant w.r.t some of the karaf-ery), 50% Felix content/reference-wise. Do you want to make it pure felix? It’s all just pom.xml references otherwise. And just to be clear, is there anything manifestly “microservice”-y that would distinguish from a reasonably well-featured REST framework? I take it you’re looking to pull in karaf (I haven’t yet, but will, I’m just learning to go slow because one false/erroneous move can break the entire thing I’m finding). I have it up and speaking, I just need to create a notion of universal deploy-ability (and that includes guidance for docker-ization, which I’m thinking I’ll do by having container initialization that drives felix/gogo via commands to do the resolve and deploy). In summary, if you’d rather go solo, that’s cool, but I’m all over this this week and could help if it helps at all, would be happy to contribute. Regards, Wayne On Sun, Apr 12, 2020 at 1:46 PM Jean-Baptiste Onofre <j...@nanthrax.net> wrote: > > Hi Christian, > > That’s interesting, but I think that people are expecting more than that. > > 1. Most of the time, we do things too much complex. > 2. Assembly again layers is not always easy > 3. Where’s the runtime ? > > Your main point is valid: lot of people went too far in fine grained services > and now, they are thinking about "smart" micro services. > That’s exactly the purpose of Netflix using Apache Karaf. > > Back on your point, that’s the target of "new" Karaf tool that I restarted > (re-starting/founding Karaf Boot we discussed while ago that addressed > exactly the points you mentioned). > > So, why not having a blueprint (I still think people wants to create their > own blueprint), but having tool + runtime is more interesting and that’s why > I’m working on Karaf "DevX code" PoC. > > Regards > JB > > > Le 12 avr. 2020 à 11:58, Christian Schneider <ch...@die-schneider.net> a > > écrit : > > > > In recent years we saw a big trend towards micro services and cloud. > > Lately people discovered though that such services are often made too fine > > grained. > > The newest trend goes to building bigger micro services on the level of > > domain driven design bounded contexts. > > > > Especially for these services OSGi is a very interesting platform as they > > need more internal structure than the more fine grained services. > > Unfortunately it is quite hard to build a cloud native service in OSGi from > > scratch. > > > > So I would like to offer a blueprint for cloud native micro services inside > > the felix community. The goal is to provide all parts of a cloud native > > system that are usually needed, like: > > > > * Declarative services as dependency injection > > * Aries Jaxrs Whiteboard for REST > > * Dropwizard metrics exported as Prometheus metrics > > * Swagger > > * Halbrowser > > * Felix healthchecks > > * Configuration using OSGi configurator + Environment variables plugin > > * Logging to console > > * Final application is provided as a runnable jar > > * Example docker build files > > * Example kubernetes yaml > > > > What do you think? > > > > Christian > > > > -- > > -- > > Christian Schneider > > http://www.liquid-reality.de > > > > Computer Scientist > > http://www.adobe.com >
