A container is not a VM (at least in the traditional sense). The advantages of running java inside of a container is that you can ship all of your things as one artifact, and run it on a bunch of different infrastructures, with all it's dependencies packaged together. So rather than needing to use something to ensure your properties are configured correctly, and all your passwords are where they need to be, and all your other bits and such are in place, you can pack it all in a container and run it anywhere (Well... "anywhere" being a bit of a stretch, but you get the idea haha)

I think the OP's point is, that's what a jar file was supposed to do. You can ship a bundled-up jar file to anyone and they can run it so long as they have the right JVM installed. Now, you replace 'the right JVM install' with, 'the right Docker install' and what have we really gained? It seems an added layer of complexity for little gain.

I like docker and use it, but it's not for everything everywhere and is overly-hyped IMO.

> they can run it so long as they have the right JVM installed

This is the key. The right JVM, the right classpaths, the right configuration, the right permissions, the right native libraries.

The setup process for every Java app we've used (thankfully just ActiveMQ and Kafka lately) have been incredibly complicated. JAR files in paths, long, convoluted shell scripts to set up all possible variables for every possible JVM, wrappers that wrap launchers, etc.

And then all of those steps are prone to breakage and are difficult to debug.

Shipping a Docker container lets you say "Here is a working environment that needs no configuration and won't suddenly fail until reconfigured when another app you have needs Java 9 and not Java 8".

This. Going from java 5 to java 5+n with everything have to use the same JVM, shared on a computer was a nightmare in my large organization.

Yes, when I tell people to start looking at Docker as an "complete application packaging" solution (vs a VM), the light seems to go on for most.

Wait until you get to Docker 5 -> Docker 6. I bet it will turn into Java basically.

"Right Docker install" - I agree, there will be that problem at some point. But containers are not just some extra layer: they do not solve the same problem as fat jar. JARs are used for the distribution of the code and related assets. With containers you can distribute and isolate the deployment configuration: you can run multiple applications on the same physical server and not worry about conflicts due to different versions of JRE or system libraries. Vulnerability in one app will not affect another one. Security patches and system updates may be tested in isolation in a single container, before propagating the change (in the form of a common base image) to others. And, of course, it's just very convenient to run the whole Linux-based production cluster or test load balancing on your work laptop with Windows. :)

So Java, which was supposed to be "write once, run anywhere", didn't meet that goal enough, so Docker wraps it in something that "actually for real" is supposed to be "write once, run anywhere", but even then doesn't quite meet that goal?

No. Java's "write once, run anywhere" promise is that you would not have to re-compile your source code to target different architectures like you do with C or C++. Docker's promise is that you don't have to rely on external things like databases, filesystem details, and other things _outside your program_ being in place across environments. Same idea, different levels of abstraction.

Java is perfectly capable of running everywhere, so containers are used not to solve this problem. With a container you ship the fixed version of the execution environment: JRE, system libraries, startup scripts, etc.

And so, the cycle continues

As others have pointed out, it's not a VM. In fact, running the same Java app outside the container will have the exact same performance as running it inside the container (if you don't add memory/cpu limits).

A VM is also super heavy: all those libraries, the package system, init/systemd and you need some Ansible/Chef/Puppet scripts to build all that. A container still has a lot of those libraries (most are build on a base distro image: ubuntu, debian, alpine, etc), but no init/systemd. Your process runs as 1 with cgroups used for isolation.

You also have this nice contained artifact. No packaging it as an RPM/DEB and having to install it. It comes with its JVM and dependencies in there. It will always run the same way where ever you put it. If you have five containers that all package the same way, when you deploy, you don't get 5x the space usage. Docker uses overlay filesystems so the base can be shared.

Also once it's in a container, you can use something fancy like Marathon, K8s, nomad or swarm to schedule it to run somewhere out on a cluster. These ecosystems have tools for monitoring the number of services you have running in parallel and the ability to scale them up and down.

You don't get the isolation/security you get in a VM (if the kernel has an exploit, it can be exploited from within the container. It shares the host's kernel), but they are as light as a process with some security guarantees via cgroups and with all your artifacts and dependencies packed into an image you can easily save off, transfer and deploy.

I see your point but Docker is not a VM, there is not a "redirection" cost or anything.

So you can see it as a convenient way to distribute the JVM. Say that the JVM makes your application portable wrt the OS, Docker makes the JVM itself more portable.

Improved deployments, repeatable builds, easier monitoring, makes it platform-agnostic, easier networking, resource limits. There are many reasons.

And, as other people have pointed out, a docker container isn't a VM. It's a chroot process with a bunch of tooling around provisioning, networking, security, etc around it.

One of the big wins of docker is that it allows you to ship file-systems around and run them as if they were binaries.

To truly set up a Java application in a production-ready way (not just running something quickly), you need to be sure of all these things:

1. A compatible JVM is installed somewhere.

2. When you run your application, it uses that JVM and not some other JVM.

3. You have the right flags passed to the JVM. For example, max heap size matching your application's actual usage, garbage collector tuning, thread stack size, and any properties that are set via -D.

4. Your jar file is there.

5. There is a place to write log files, and your application's logging system knows to write them there.

6. If you are using any native libraries through JNI, they need to be installed, and the JVM must be able to find them and use them.

7. If you listen on port, an available port number is found, your application knows what it is, and the rest of the world knows where to find you.

I believe Docker addresses all these points.

I had the same question as you 2 years ago. Here is the long answer http://blog.codepipes.com/containers/docker-for-java-big-pic...

It’s not a VM, it’s faster and far lower overhead per container. Obviously it also looses some of the isolation guarantees.

It's the same advantages as running anything else in a container, cgroups and namespaces.

so it can be scheduled and managed by kubernetes/swarm .