For a pure Java stack, you might not find any advantage in Docker. There is still one however -- Kubernetes. Run many instances of a Docker container in Kuber

For a pure Java stack, you might not find any advantage in Docker. There is still one however -- Kubernetes. Run many instances of a Docker container in Kubernetes as a cluster. Oh, but I can set up various Java technology clusters without Kubernetes. Think of Kubernetes as doing for clusters what an OS does for a single computer. 1960s: Joe: can I use the computer today to run my workload? Bob: yeah, but my workload is running the computer until about 3 PM. Today: Joe: can I use the (let's say Hadoop) cluster to run my workload? Bob: yeah, but my workload is running the cluster until about 3 PM. An OS lets Joe and Bob both use the computer at the same time. Kubernetes lets Joe and Bob both use a generalized cluster at the same time. Joe has his Docker container (say a Java workload set up as a Hadoop node). Bob has his Docker container (say some other kind of Java parallel computing workload, or maybe Python or other). Joe tells Kubernetes to run 50 instances of his workload. Bob tells Kubernetes to run 30 instances of his workload. Joe and Bob's workloads can each see each their own nodes on a private network that cannot see the other's nodes on the network. Maybe the physical hardware cluster only has 45 nodes. Kubernetes might schedule multiple docker containers running on the same physical node. Kubernetes is something you would expect from Google running a giant data center where many different people want to run multiple-node clusters ad-hoc at any given time. Even multiple instances of the same type of workload, such as Jane wanting her own 50 node Hadoop, while Carol runs a 40 node Hadoop cluster, but they don't interfere with each other.