Hi Serge, Docker learning curve is lower than the maven-Bnd-pg one? This is just hype, not reality...
Regards, 2015-04-12 8:19 GMT+02:00 Achim Nierbeck <[email protected]>: > Hi Serge, > > since you wanted to integrate ES in Karaf, take a look at decanter. About > the modularization of ES, I'm with you. A colleague of mine just recently > talked to Shay Banon about this, but right now they aren't in for OSGi, I > guess we have to push them there a little. > > About tooling, yes I think we could need some better tooling here and > there, but as usual the devs here just scratch their own itches. So if we > miss things, since we do it just a bit different or don't feel the pain > we're not going to build those tools ;) > > Personally I think the learning curve used to be steeper, but with > blueprint and DS it turns out to be much simpler. Until people stumble over > service-trackers in Activators ;) > > The thing about Docker is, it's a nice tool and does help here and there, > for showcases, POCs and such. In the end people will use > it as the hammer for every issue they have. > > regards, Achim > > > 2015-04-12 3:52 GMT+02:00 Serge Huber <[email protected]>: > >> 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 > > -- Charlie Mordant Full OSGI/EE stack made with Karaf: https://github.com/OsgiliathEnterprise/net.osgiliath.parent
