Hi Serge, I think there are some drawbacks with Microservices which you run into over time, that to my personal opinion have already been addressed with OSGi. As a short list of what I presented at the JavaLand conference last month: - operations overhead (Java, ruby, node.js, python ... what else) - dev-ops skills are required - implicit interfaces - changes in syntax/semantics - complexity of distributed systems - asynchronity - Testability challenges
Most of those are addressable with the right modularity and within the same JVM when using OSGi. If one takes those experiences to a "bigger" level, between different Servers, you end up with Microservices in a manageable way. In the end those Microservices applications are just as modular as OSGi services, just as one Application on each different instance. just my 2 cents. Regards, Achim P.S. I still need to move those slides to slideshare ... :D 2015-04-13 21:49 GMT+02:00 Serge Huber <[email protected]>: > 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 >> >> > -- 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
