Very interesting thread guys :) Actually I recently started a project integrating Karaf with ElasticSearch and for me it was a little like what you guys are describing in this thread. ES, at least in the early versions is quite monolithic and it would clearly benefit from a framework such as OSGi. For example, the clustering technology is quite interesting but why can't it be reused without all the other stuff ? Or maybe you want to wire things a little differently ? Not have everything directly listen to ports without any security but be able to plugin whatever filter or modules you need ?
Personally I think that what is really needed in OSGi is better tooling, especially for making it a lot simpler to build high quality and minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is quite tedious and possibly error prone. I've built my own Maven plugin on top of the bundle plugin so that it can handle a lot more resources (including JSPs that include taglibs for example) and that also tries to be smarter at generating import-package statements. This makes it easier for OSGi newbies to adopt the technology. I'm also worried that the initial learning curve of OSGi might be putting less experienced developers off and more towards package-the-world solutions such as Docker, which while acceptable for some cases such as continuous integration, could also be dangerous if not maintained properly. Regards, Serge > Le 11 avr. 2015 à 19:43, Niels <niels...@gmail.com> a écrit : > > Could not agree more Achim. Good fad indicators are high promises which are > designed to target the ultimate need of decision makers to deliver software > quicker and cheaper. Just rewind 10 years and we will find the exact same > promises were made at the start of the SOA hype which are now touted by the > microservices believers. At the end of the day nothing will prevent people > from doing something really badly. > > I can see the value of docker but unless one really has all the lifecycle > ducks in a row I would not go down the path and containerise the all and > sundry. > > Cheers, > Niels > >> On 12 Apr 2015, at 08:28, Ryan Moquin <fragility...@gmail.com> wrote: >> >> I used to work somewhere with other developers who always became very >> spiritual about whatever the latest "cool" developer technology or >> methodology is. Microservices was one of them. It always made me laugh >> when I was told how super efficient and streamlined it was over any other >> solution because every fat jar deployed (Maven shade plugin abuse in order >> to be lazy) was between 500Mb and 1.7Gb. So much for being a >> "micro"-service. >> >>> On Apr 8, 2015 2:55 PM, "Achim Nierbeck" <bcanh...@googlemail.com> wrote: >>> I'm very ambivalent regarding this topic. >>> >>> On one hand I see a lot of move to Docker as heading for the holy grail on >>> fixing all the issues we had in the past. #FAIL >>> On the other hand I see some benefits of it, but still haven't found the >>> concrete use-case where it did top a bar-metal or bare virtualized machine. >>> >>> It's absolutely true that it does have some benefits for easier deployment >>> of "Infrastructure" but I also see a lot of failures in usage of Docker. >>> Just to mention one, where did the init daemon go, it's been there for a >>> reason in linux OS's and now we run applications on top of the system >>> without it ... I don't feel comfortable with that, especially if you don't >>> have a JVM as process running which starts spawning other processes (one >>> might remember the zombie processes). >>> In the end there are mostly more slopy/lazy people around[1] trying to get >>> something going, that's why Docker will be sufficient enough, while the >>> dynamic and re-configurable service oriented software architecture will be >>> on the decrease. One just needs to follow that Microservice hype. >>> Docker/SpringBoot are just part of this "mantra" :D >>> In the end people will just split their Monolithic rubbish up to different >>> small Monolithic piles of rubbish, but in case one of them is failing, >>> they'll end up with one big failing pile of rubbish. >>> >>> Besides this rant, I think building a custom Karaf with your application on >>> top, distributable as Docker image. Or as I did for a showcase building a >>> base Karaf Docker Image for Continuous Integration/Delivery Pipeline is a >>> good combination. As long as it's possible to configure the services inside >>> this docker image from the outside. >>> >>> regards, Achim >>> >>> [1] - http://blog.osgi.org/2014/08/is-docker-eating-javas-lunch.html >>> >>> >>> 2015-04-08 17:34 GMT+02:00 Frank Lyaruu <fr...@dexels.com>: >>>> I agree, I do feel that vibe from time to time, mostly due to the >>>> 'containers should be immutable' mantra. >>>> >>>> In my opinion, if you can get away with it, make it as dynamic as you >>>> want, but I guess we all know that building an application that can be >>>> reconfigured + updated on the fly is not easy at all. >>>> >>>> Anyway, while we're at it, I also wrote a few posts about OSGi + Docker, >>>> with quite a different approach: I explore monitoring the Docker API to >>>> discover services, and inject those services as OSGi configuration data: >>>> >>>> http://www.codemonkey.nl/discovery/ >>>> >>>> I think OSGi and Docker can complement each other very nicely. >>>> >>>> regards, Frank >>>> >>>>> On Wed, Apr 8, 2015 at 4:54 PM, Ryan Moquin <fragility...@gmail.com> >>>>> wrote: >>>>> Don't get me wrong, I don't mean that Docker and Karaf are >>>>> interchangeable. I mean that it feels like, from quite a few things I >>>>> read, that the trend may be to have a docker image built as part of every >>>>> CI build. The purpose being that deployments should be fully immutable >>>>> and if changes need to be made, then a new Docker image should be >>>>> generated and deployed. >>>>> >>>>> One particular conversation that I felt really expressed this type of >>>>> development track is this one: >>>>> >>>>> https://groups.google.com/forum/m/#!topic/fabric8/iEmyW0_rnSk >>>>> >>>>> Fabric8 used to be fully built on Karaf but has changed the approach to >>>>> support other runtimes. Nothing is wrong with that, but if that pattern >>>>> becomes a trend, then it feels that many of the nice features of Karaf >>>>> will become "discouraged" and I can't see them being furthered in Karaf >>>>> at that point. >>>>> >>>>> I love Karaf and everything it offers. I'm just a little concerned about >>>>> how Docker is being pushed and the mindset that seems to evolving around >>>>> it. The point is, I'm hoping that because Docker is immutable, that it >>>>> doesn't cause all software development to shoot to be immutable. >>>>> >>>>> Hopefully that makes sense. :) Lots of new technologies allow developers >>>>> to know less about software development and to write sloppier code >>>>> because they can get away with it. While building things faster and >>>>> minimizing redundant or error prone tasks is great. I guess I'm a little >>>>> concerned about how Docker can be misused and the effect it could have. >>>>> >>>>> Hopefully that makes sense :) I have no problem embracing Docker as a >>>>> container to run Karaf in, I'm just hoping Docker doesn't become a >>>>> liability or stifler to Karaf. >>>>> >>>>> These of course are only my opinion of the research I've been doing on >>>>> and off. I may be completely off the mark or misinterpreting things. >>>>> >>>>> Ryan >>>>> >>>>>> On Wed, Apr 8, 2015 at 10:04 AM, Vincent Zurczak >>>>>> <vincent.zurc...@linagora.com> wrote: >>>>>> Hi, >>>>>> >>>>>> I don't know if we can really compare Karaf and Docker. >>>>>> I use OSGi to build modular applications. My bundles are Java modules >>>>>> that I can assemble in one way or another. And I use Karaf to create a >>>>>> custom distribution of my OSGi applications. It is a developer thing. >>>>>> >>>>>> Now, I use Docker to execute applications in an isolated container on a >>>>>> machine. >>>>>> Even on VM, running Docker can simplify support and debug for >>>>>> applications. The fact we can isolate things is very helpful for that. >>>>>> And it is convenient to maximize the usage of VM resources. >>>>>> >>>>>> I do not see how one could replace the other. >>>>>> BTW, I already run Karaf in Docker containers. And one of our OSGi >>>>>> applications (which runs in Karaf) can create and interact with Docker >>>>>> containers. So, you can make both of them together when you need. >>>>>> >>>>>> >>>>>> Le 08/04/2015 14:31, Ryan Moquin a écrit : >>>>>>> I kind of feel like the big push of Docker in the development community >>>>>>> in general (as a whole, not talking about the Karaf developer >>>>>>> community), will potentially cause a lack of innovation and >>>>>>> improvements in the deploying of applications. Docker could become a >>>>>>> crutch. If an application is slowly leaking memory over a 24 hour >>>>>>> period, why fix it? When it crashes, just replace it with a new >>>>>>> instance. >>>>>> >>>>>> May I say that cloud computing and virtualization in general already >>>>>> setup this kind of approach? >>>>>> When a VM or a container has a problem, it may indeed be more simple to >>>>>> launch a new one, reconfigure your application to use it and kill the >>>>>> old one. But this is not new at all. And there are some little things to >>>>>> deal with, like reconfiguration. Docker works the same, at its level. >>>>>> And even if you can create new containers, the less procedures you have >>>>>> in production environments, the better it is. So, having applications >>>>>> with 99,99% uptime will always be better. >>>>>> >>>>>> BTW, Docker also has some limitations (with systems services as an >>>>>> example). >>>>>> So, it comes with its own problems. And I do not expect embedded systems >>>>>> to use Docker (at least, for the moment). >>>>>> >>>>>> To summer it up, I would say OSGi brings modularity to Java applications. >>>>>> And that Docker brings modularity to deployments. That's not the same. >>>>>> >>>>>> My 2 cents, >>>>>> >>>>>> Vincent. >>>>>> >>>>>> -- >>>>>> Vincent Zurczak >>>>>> Linagora: www.linagora.com >>>>>> >>>>>> <twitter_16.png> <linkedin_16.png> <skype_16.png> <wordpress_16.png> >>> >>> >>> >>> -- >>> >>> Apache Member >>> Apache Karaf <http://karaf.apache.org/> Committer & PMC >>> OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer & >>> Project Lead >>> blog <http://notizblog.nierbeck.de/> >>> Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS> >>> >>> Software Architect / Project Manager / Scrum Master
