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 <fragility...@gmail.com> 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" <bcanh...@googlemail.com> 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 <fragility...@gmail.com>: > > > >> 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" <shu...@jahia.com> 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 <niels...@gmail.com> 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 <fragility...@gmail.com> 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" <bcanh...@googlemail.com> > >>> 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 <fr...@dexels.com>: > >>>> > >>>>> 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 <fragility...@gmail.com> > >>>>> 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 < > >>>>>> vincent.zurc...@linagora.com> 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 > > > >
