James, I don't think JB cared. He was probably more than happy to have
a discussion than to have to simply walk through slides without any
feedback. At least that's how I prefer it.
Personally I think that OSGi is really a great way to make sure that
people get into the good practice about thinking about the full
lifecycle of code, not just developing it and starting it, but also
shutting it down, and what happens when dependencies are not present
or shutdown.
In that regard I've seen that in our team since we switched to OSGi,
although it took a little investment in terms of getting used to it,
people are a lot more productive because they can focus on the module
they are building without having to restart the whole container. This
is a huge improvement over Docker type of deployments where rebuilding
and restarting a container can take a lot longer to test a single change.
I believe that OSGi is also more than proven since it has been around
for a long time, and it is defined by a standard body that is quite
significant. I just wish it would get adopted more, and hopefully
Karaf will help with this effort.
Not to make me say that Docker or Spring Boot or the Play Framework
don't have their merits, but I think that it is not enough to look at
the time to get started, it is also important to look at the TMDT (an
acronym I just made up : Total Maintenance and Deployment Time :)).
cheers,
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 Sat, Apr 18, 2015 at 10:47 AM, James Carman
<[email protected] <mailto:[email protected]>> wrote:
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 <[email protected]
<mailto:[email protected]>> 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
<[email protected] <mailto:[email protected]>> 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é
<[email protected] <mailto:[email protected]>>:
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/
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
<[email protected]
<mailto:[email protected]>> 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"
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[email protected]>>:
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"
<[email protected]
<mailto:[email protected]>> 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
<[email protected]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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]
<mailto:[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
<https://groups.google.com/forum/m/#%21topic/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]
<mailto:[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
<http://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
--
Jean-Baptiste Onofré
[email protected] <mailto:[email protected]>
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
