Interesting discussion indeed. I'm currently at ApacheCon US and I've taken a few opportunities to promote Apache Karaf which surprisingly few people know about. But again what I was describing earlier is really a frequent feedback : is modularity worth the trouble when I can built "micro-services" that are actually running in docker containers ? Although I am convinced that the two are not in opposition, I think it would be great to have a killer use case to demonstrate what the benefits of using Karaf would be.
I'm really looking forward to meeting Jean-Baptiste in person ! I love Karaf and I hope to be able to exchange with him a few experiences around it. Regards, Serge - -- --- -----=[ shuber at jahia dot com ]=---- --- -- - CTO & Co-founder - Jahia Solutions Group, 9 Routes de Jeunes, 1227 Acacias, Switzerland twitter: @sergehuber <https://twitter.com/sergehuber> <http://jahiaone.com/register> JahiaOne <http://www.jahiaone.com/>, our international user conference is back! June 10-12 in Paris - Grab your tickets now <http://www.jahiaone.com/> ! Jahia is a leading open source User eXperience Platform (UXP) vendor, relentlessly working at transforming a siloed industry into a user-driven one, beyond technology constraints - http://www.jahia.com On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck <[email protected]> wrote: > Hey, > > yes I fully agree, also with the Spring-Boot stuff. > as already stated on the other thread, I think there are certain cases > where Docker images are useful. > For a POC, for CI I think a Docker Image is useful. In the end if you want > to run it in Production I rather have the Ansible setup. > > regards, Achim > > > 2015-04-13 17:02 GMT+02:00 Jean-Baptiste Onofré <[email protected]>: > >> Hi Ed, >> >> I can't agree more ;) >> I fully agree about your points. >> >> I quite have the same view on Spring Boot ;) >> >> Regards >> JB >> >> >> On 04/13/2015 04:32 PM, Ed Welch wrote: >> >>> I've really enjoyed following this thread, and I have to say, as a >>> Docker skeptic surrounded by people who want to bash my brains in with >>> docker images, it's nice to hear some feedback from people who seem to have >>> a healthy dose of skepticism like I do... >>> >>> So rather than rehash all the things I agree with that have been said so >>> far, I wanted to comment a few things I hadn't seen: >>> >>> The biggest discussion point I bring up with my peers regarding docker >>> that I've been using to kind of hold the floodgates back: Who is >>> responsible for updates to the underlying docker image OS? Our >>> organization is fairly segmented, we have a linux operations group, we have >>> a development group. If our development group deploys 50 docker images, >>> all with a variety of distros inside them, different versions of >>> everything... What happens if there is a big vulnerability found >>> (think/remember bash). Is our linux team now on the hook to learn docker >>> and handle digging through dozens to hundreds of potentially very different >>> docker images ( which would make you want to force standardization of your >>> docker images on a particular distro at a minimum ), or does the dev team >>> now own this responsibility? This is a hard question for our company to >>> answer... >>> >>> My other comment, is actually regarding what I think is the most >>> fantastic use case I've seen for docker, which was written up by Roland >>> Huss on his blog: https://ro14nd.de/Jolokia-Docker-Image/ >>> Using docker as part of your automated integration tests is a really >>> neat idea, especially if you work on a project that has to maintain support >>> for piles of application servers, operating systems, and versions of java. >>> I think there is some real opportunity here as was previously mentioned, to >>> build a docker image that sets up the OS, java, and karaf, and then at test >>> time you deploy your app and run your tests. With this kind of model you >>> can just keep adding new docker images to your test suite and retire old >>> ones when you finally drop support for something ( *cough* java 6 *cough*) >>> >>> Good discussion, really have enjoyed reading! >>> >>> Ed >>> >>> >>> On Mon, 13 Apr 2015 08:31:37 -0400, Ryan Moquin <[email protected]> >>> wrote: >>> >>> I guess the barrier to be able to write code has been lowered enough >>>> that >>>> more people are able to do it, probably for the money. That goes hand >>>> in >>>> hand with the whole Docker thing where it feels there is an expectation >>>> that everything should be easy to do rather than accept that like any >>>> profession, you have to learn in order to become good. Nothing wrong >>>> with >>>> asking questions, but I feel quality of code will probably continue to >>>> decline with tools being the crutch. >>>> >>>> Anyhow, thanks for everyone's input. Karaf is a fantastic piece of >>>> software, I just wanted to make sure that things like Docker weren't >>>> going >>>> to cause it to be dumbed down. Obviously like any growing technology, >>>> modularity has some rough spots to iron out, but that doesn't mean we >>>> should give up. Developers can do what they want, I would like to >>>> continue >>>> to choose what fits my requirements best out of the technologies that >>>> are >>>> available. >>>> >>>> Ryan >>>> On Apr 13, 2015 2:37 AM, "Achim Nierbeck" <[email protected]> >>>> wrote: >>>> >>>> I can't agree more ... and some questions on stackoverflow or this >>>>> mailinglist just reflect that ... >>>>> "please solve my issue for me, cause I forgot to use my brain today" :D >>>>> >>>>> regards, Achim >>>>> >>>>> 2015-04-13 0:44 GMT+02:00 Ryan Moquin <[email protected]>: >>>>> >>>>> Serge, >>>>>> >>>>>> Package the world applications were able to be built easily before >>>>>> Docker >>>>>> was around. Docker is simply a different way of deploying an >>>>>> application >>>>>> virtually. >>>>>> >>>>>> In my experience, developers who "package the world" with their code >>>>>> are >>>>>> usually either biased against modularity or just don't feel like >>>>>> putting >>>>>> forth the effort. Many technologies in use today take effort to >>>>>> figure >>>>>> out. A lot of developers seem to feel that any technology that >>>>>> requires >>>>>> effort above the maven shade plugin or using shell scripts to dump all >>>>>> their jars to a server isn't worth their time. >>>>>> >>>>>> Developers that care about the quality of the code or applications >>>>>> they >>>>>> produce won't be deterred from a technology they believe will help >>>>>> them >>>>>> make better applications just because it takes a little bit of >>>>>> effort. How >>>>>> did less experienced developers manage to survive when the only real >>>>>> choices for writing software was assembly, c or c++? >>>>>> >>>>>> Ryan >>>>>> On Apr 11, 2015 9:53 PM, "Serge Huber" <[email protected]> wrote: >>>>>> >>>>>> 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 <[email protected]> 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 <[email protected]> >>>>>>> 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" <[email protected]> >>>>>>> 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 <[email protected]>: >>>>>>>> >>>>>>>> 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 < >>>>>>>>> [email protected]> >>>>>>>>> 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 < >>>>>>>>>> [email protected]> 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> <https://twitter.com/VincentZurczak> >>>>>>>>>>> <linkedin_16.png> >>>>>>>>>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> >>>>>>>>>>> <skype_16.png> <callto://vincent.zurczak> <wordpress_16.png> >>>>>>>>>>> <http://vzurczak.wordpress.com> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> >>>>>>>> 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 >>>>>>>> >>>>>>>> >>>>>>>> >>>>> >>>>> -- >>>>> >>>>> 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 >>>>> >>>>> >>>>> >>> >>> >> -- >> Jean-Baptiste Onofré >> [email protected] >> http://blog.nanthrax.net >> Talend - http://www.talend.com >> > > > > -- > > 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 > >
