Hi Charlie, I completely agree with you. I'm glad that there are others that have the same opinion. I'm fine using Docker. I don't want to see great technologies go away because developers can use something like Docker as a way to get away with write crap code. On Apr 8, 2015 4:45 PM, "Charlie Mordant" <[email protected]> wrote:
> My 2 cents on this: > > On one side, you've the way to build real modular application the right > way, you just have to have a brain to do this, and its going simpler and > simpler with Karaf, bnd, and all Ops4j work. > > On the other side, you can mimic a nearly modular architecture, lowering > the problem on the infrastructure side. > * You'll never be able to build real modular application, you'll never be > able to have multiple version of the same product together, you'll never be > able to hotswitch your services (or you'll use kubernete, chef or another > provisioning tool, but it will always be harder than using OSGI itself). > * You'll also never be able to upgrade your app, just replacing an older > by a newer (so no automatic provision by Nexus listening). > * Your apps will always be as crappy as the previous one: no api/impl > package distinction, no intra vm services (and http ones like spring boot > add a non negligible overhead). > * All your 'microservices' will be 20mo sized (embedding tomcat and > spring-beans/context/boot has a cost). As an addition, all the > configuration will be duplicated (and slightly different) in all that > services. > > So, the choice is in your hands: coding well and really modular or coding > crappy and maintaining a hard-to-maintain infrastructure. > > Real Microservices architecture is here with Karaf/Camel, not with > Spring-boot and Docker. I hope people won't be cheated on the commercial > and hype on these wrong solution. > > I'm not against docker, I use this to provision ldap, ELK, Mail servers, > etc... They're just not suited for micro services (and for Spring boot, I > consider it always be better than JavaEE, but far from OSGI). > > 2015-04-08 20:54 GMT+02:00 Achim Nierbeck <[email protected]>: > >> 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 >> >> > > > -- > Charlie Mordant > > Full OSGI/EE stack made with Karaf: > https://github.com/OsgiliathEnterprise/net.osgiliath.parent >
