Hi Christian, I agree concerning the microservice hype and that you have to differ between development and runtime time. OTH. I've already seen it working in production to replace a single bundle due to bug-fixing a critical bug. So I disagree about that you only deploy a single server setup and replace that. It is actually much more complex and therefore requires an appropriate deployment strategy.
regards, Achim 2015-04-19 8:12 GMT+02:00 Christian Schneider <[email protected]>: > I really like the deployment of bundles into a running instance at > development time. For example it allows to debug through my bundle, do a > fix and redeploy the single bundle while the debugger stays open. That > really speeds up the development process. > > At production time though I never saw that for a single application that > deployment at runtime was used. Typically a certain set of bundles is > tested together and released together. So I think in this case docker is a > nice fit as we can pack karaf together with this set of bundles into an > image. This can then be deployed as a simple singular unit which is good > for admins. Rolling back then is also easy as you can just install the > previous image. > > There is one case where runtime deployment makes a lot of sense. This is > the case of an integration server where you deploy lots of small > integrations. Each of these has its own lifecycle and it would not make > sense to build a container for each of them. > > Then there is a case in between represented by the micro services hype > (not in the sense of OSGi Services). There you have an application that is > built from individual modules that each have their own lifecycle and > dependencies. For this case you could use one container and runtime > deployment but you could also create one container for each. I recently > helped to port an application from spring/tomcat to OSGi. The application > was already design to have modules with different lifecycles. In tomcat > this was represented as one war per module / "microservice". The problem in > OSGi was that the application was not modularized in an OSGi way. So for > example there was no semantic versioning. Some of the bundles had to be > installed in one single version over all the modules. If versions were > mixed the wiring of module A could change when a new version of module B > was installed. For this case having separate containers can help. > > So the picture I painted shows that there is no one size fits all solution > and I think docker can be a good match for some of the use cases in > deployment. > > Christian > > Am 19.04.2015 um 02:44 schrieb Serge Huber: > > James, I don't think JB cared. He was probably more than happy to have a > discussion than to have to simply walk through slides without any feedback. > At least that's how I prefer it. > > Personally I think that OSGi is really a great way to make sure that > people get into the good practice about thinking about the full lifecycle > of code, not just developing it and starting it, but also shutting it down, > and what happens when dependencies are not present or shutdown. > > In that regard I've seen that in our team since we switched to OSGi, > although it took a little investment in terms of getting used to it, people > are a lot more productive because they can focus on the module they are > building without having to restart the whole container. This is a huge > improvement over Docker type of deployments where rebuilding and restarting > a container can take a lot longer to test a single change. > > I believe that OSGi is also more than proven since it has been around > for a long time, and it is defined by a standard body that is quite > significant. I just wish it would get adopted more, and hopefully Karaf > will help with this effort. > > Not to make me say that Docker or Spring Boot or the Play Framework > don't have their merits, but I think that it is not enough to look at the > time to get started, it is also important to look at the TMDT (an acronym I > just made up : Total Maintenance and Deployment Time :)). > > cheers, > 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 Sat, Apr 18, 2015 at 10:47 AM, James Carman <[email protected] > > wrote: > >> Serge, >> >> We had some pretty good discussions during JB's talk (hope we didn't >> hijack it too much, JB). I don't think this topic really has anything to >> do with Docker, necessarily. Docker is merely a tool people employ to >> implement a deployment strategy. I think it basically boils down to the >> notion that in the "cloud era", it's simpler and cheaper to spin up a new >> node configured the way you want. Cloud-enabled applications need to be >> "cloneable" in this way already, so you kind of get this benefit for free. >> >> This doesn't mean we can't use OSGi to piece together these nodes. >> OSGi isn't only about being able to runtime-refresh your modules. There >> are many other benefits of the OSGi programming model that make it suitable >> for building statically-configured applications as well. >> >> Just my $0.02 >> >> James >> >> On Mon, Apr 13, 2015 at 3:49 PM, Serge Huber <[email protected]> wrote: >> >>> 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
