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]> 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]> 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]>:
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]> 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]> 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]> 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]>
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
<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]
http://blog.nanthrax.net
Talend - http://www.talend.com
