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 >>>> >>>> [image: Twitter] <https://twitter.com/VincentZurczak> [image: Vincent >>>> Zurczak @ LinkedIn] >>>> <http://fr.linkedin.com/pub/vincent-zurczak/18/b35/6a7> [image: My >>>> Skype ID] <callto://vincent.zurczak> [image: My English blog] >>>> <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 > >
