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 <shu...@jahia.com
<mailto:shu...@jahia.com>> 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 <http://www.jahia.com/>
On Mon, Apr 13, 2015 at 2:42 PM, Achim Nierbeck
<bcanh...@googlemail.com <mailto:bcanh...@googlemail.com>> 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é <j...@nanthrax.net
<mailto:j...@nanthrax.net>>:
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/
<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 <mailto: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
<mailto: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
<mailto: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 <mailto: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
<mailto: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
<mailto: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
<mailto: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
<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
<mailto: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/
<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
<mailto: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
<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
<mailto: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
<http://www.linagora.com>
<twitter_16.png>
<https://twitter.com/__VincentZurczak
<https://twitter.com/VincentZurczak>>
<linkedin_16.png>
<http://fr.linkedin.com/pub/__vincent-zurczak/18/b35/6a7
<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/
<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/
<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é
jbono...@apache.org <mailto:jbono...@apache.org>
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
