Os benefícios do desenvolvimento do uso do Docker foram negados ao usar o Java em comparação com outros idiomas mais próximos dos binários do Unix?

Nada disso.

Imagine que você está executando a versão 1.8.0 do Java na sua máquina de desenvolvimento e no servidor. A propósito, você está trabalhando simultaneamente em dois projetos, ambos usando Java.

Um dia, um bug é encontrado na JVM e os servidores que executam o primeiro projeto em que você está trabalhando são migrados para o 1.8.1. A propósito, os servidores que executam o segundo projeto não são afetados pelo bug e são gerenciados por uma equipe diferente de administradores de sistema, que podem não estar dispostos a atualizar para o 1.8.1.

Agora, pelo menos para um dos projetos, você está executando uma versão diferente do Java.

Isso pode não incomodar muito você (até que um servidor migre para 1.9, enquanto o outro mantém a versão antiga), mas isso significa que você não está mais replicando o ambiente de produção em sua máquina local, o que o torna possível que pequenos bugs se infiltrem.

Se você imaginar que seu sistema de arquivos, suas dependências, suas configurações de segurança, sua configuração local e sua própria versão do Linux diferem da produção, você está se arriscando a escrever código que falhará na produção. Em vez de correr esse risco, você pode estar usando a virtualização ou o Docker, com pouca ou nenhuma perda de produtividade.

Você raramente implementa um "Java App". Seu aplicativo java tem muitos programas de suporte diferentes em torno dele. Usamos o Apache HTTPD, o Apache Tomcat, o ActiveMQ para mensagens, um FTP Deamon, MySQL e vários serviços customizados para integrar com programas que não funcionam diretamente com Java.

Isso nem entra no software de desenvolvimento que o acompanha - eclipse, formiga, adobe flex, groovy, firefox e subversion (estou pulando alguns)

Demora entre um dia inteiro e uma semana para configurar uma nova estação de trabalho - discutimos a migração para o Docker para simplificar esse problema. Seria incrível se pudéssemos lançar uma nova estação de trabalho confiável em algumas horas.

Sem mencionar o fato de que, quando implantamos, precisamos manter mais de 20 servidores; O Docker está começando a parecer um ótimo negócio!

(20 parece bastante doloroso para um aplicativo que só é executado em um único servidor de cada vez ... mas multiplique esse servidor por clusters (x2), teste / teste / prod (x3), interno / externo (x2) e site primário / site de backup (x2) e você chega lá rapidamente)

Esta questão também seria pertinente para golang, onde você pode simplesmente extrair binários estaticamente vinculados e executá-los em algum lugar, em vez de Python ou C ++, onde geralmente há um grande número de bibliotecas vinculadas que levam as pessoas a criar um contêiner docker fora do ambiente de desenvolvimento.

Há dois pontos para responder aqui:

Um: lá tem que ser uma maneira melhor , e há: você pode construir containers docker menores (e mais eficientes) usando apenas o ambiente de instalação, o que leva a vantagens semelhantes como no caso de recipientes Golang-com-ambiente versus recipientes Golang-apenas-binários. No caso do Java, você pode construir um fat jar ou um aplicativo instalável que contém todos os jars da biblioteca e um shell script; no caso do Python, você poderia usar o auditwheel para construir rodas autônomas que são independentes do ambiente de construção (e você poderia usar o C ++ com link estático para quase o mesmo efeito).

Dois: para que você precisa do docker? Em Java, você pode fazer muita separação entre diferentes componentes usando carregadores de classes, mas o ponto principal é o que está ao redor do aplicativo Java. Nenhum aplicativo Java é executado sozinho - se ele não for executado no docker, normalmente ele deve ser supervisionado pelo supervisord ou systemd ou pelos semelhantes. Insira a nuvem do Kubernetes, Marathon ou Docker, que usa a abstração do contêiner para virtualizar não o host em si, mas, na verdade, virtualize toda a rede, de modo que você possa simplesmente implantar contêineres e eles sejam executados em algum host aleatório.

Os microsserviços geralmente são executados em nuvens baseadas no docker, pois permitem tratar seus hosts do docker como gado, não como animais de estimação e, da mesma forma, com os aplicativos dockerized. Naturalmente, essa abstração fica com defeito assim que você monta os volumes do host no docker e precisa executar os contêineres do Docker exatamente no host que possui esses volumes. Algumas pessoas ficam ao redor disso.

Esta é realmente uma boa pergunta, mas depois de trabalhar com o Docker, eu mudaria:

Are the benefits of the JVM negated by containerization (e.g. Docker)?

Os contêineres realmente desafiam muitas das suposições que tenho sobre desenvolvimento que vêm da minha experiência. Por exemplo, se alguém codificar um caminho para um arquivo de recurso em um aplicativo, muitos desenvolvedores experientes sabem que isso é problemático e você deve torná-lo configurável. Mas se você está alvejando um container, este é realmente o caso? Quando você constrói o contêiner, você diz quais são as estruturas de diretórios. Você está configurando o caminho lá. Então você deve configurá-lo duas vezes? Qual o benefício? Se você não os fizer combinar, não vai funcionar ... DRY?

Recentemente, criei um protótipo de aplicativo com Java e Docker, que essencialmente observava os eventos do GC e, quando a parte antiga do heap atingia uma porcentagem de limite, ele se desligava. O Docker (modo de enxame) acionaria um novo. Essencialmente, eliminou a necessidade de grandes ciclos de GC na JVM e permitiu que a janela de encaixe os gerenciasse. Não funcionou tão bem quanto eu poderia esperar (os clientes viram algum impacto do desligamento), mas foi funcional o suficiente para fazer uma demonstração ao vivo para uma multidão.

Você deve simplesmente experimentar os contêineres se estiver curioso. É realmente uma tecnologia disruptiva e você precisará lidar com isso. O Docker é um ótimo lugar para começar, mas há pelo menos uma outra alternativa viável que é boa para todos, IMO.