¿Los beneficios de desarrollo de usar Docker se niegan cuando se usa Java en comparación con otros lenguajes más cercanos a los binarios de Unix?

En absoluto.

Imagine que está ejecutando la versión 1.8.0 de Java tanto en su máquina de desarrollo como en el servidor. Por cierto, estás trabajando simultáneamente en dos proyectos, ambos usando Java.

Un día, se encuentra un error en JVM, y los servidores que ejecutan el primer proyecto en el que está trabajando se migran a 1.8.1. Por cierto, los servidores que ejecutan el segundo proyecto no se ven afectados por el error, y son administrados por un equipo diferente de administradores de sistemas, que pueden no estar dispuestos a actualizar a la versión 1.8.1.

Ahora, al menos para uno de los proyectos, estás ejecutando una versión diferente de Java.

Esto puede no molestarlo demasiado (hasta que un servidor migre a 1.9, mientras que el otro conserva la versión anterior), pero esto significaría que ya no estará replicando el entorno de producción en su máquina local, lo que lo hace es posible que pequeños bichos se introduzcan.

Si imagina que su sistema de archivos, sus dependencias, su configuración de seguridad, su configuración local y su propia versión de Linux difieren de la producción, se arriesga a escribir código que fallará en la producción. En lugar de tomar este riesgo, podría estar usando la virtualización o Docker, con una pérdida de productividad menor o nula.

Rara vez solo implementas una "aplicación Java". Su aplicación java tiene muchos programas de soporte diferentes a su alrededor. Usamos Apache HTTPD, Apache Tomcat, ActiveMQ para mensajería, un Deamon FTP, MySQL y un puñado de servicios personalizados para integrar con programas que no funcionan directamente con Java.

Esto ni siquiera se aplica al software de desarrollo que lo acompaña: eclipse, ant, adobe flex, groovy, firefox y subversion (me estoy saltando algunos)

Se tarda entre un día completo y una semana para configurar una nueva estación de trabajo; hemos discutido el cambio a Docker para simplificar este problema. Sería increíble si pudiéramos implementar una nueva estación de trabajo de manera confiable en un par de horas.

Sin mencionar el hecho de que cuando implementamos debemos mantener más de 20 servidores; ¡Docker está empezando a parecer una buena oferta!

(20 parece bastante doloroso para una aplicación que solo se ejecuta en un solo servidor a la vez ... pero multiplique ese servidor por clusters (x2), test / staging / prod (x3), Internal / External (x2) y el sitio principal / sitio de copia de seguridad (x2) y usted sube allí bastante rápido)

Esta pregunta también sería pertinente para Golang, donde puedes extraer archivos binarios estáticamente vinculados y ejecutarlos en cualquier lugar, a diferencia de Python o C ++, donde normalmente tienes una gran cantidad de bibliotecas vinculadas, lo que lleva a las personas a construir un contenedor docker. fuera del entorno de desarrollo.

Hay dos puntos para responder aquí:

Uno: allí tiene que haber una mejor manera , y existe: usted puede construir contenedores acoplables más pequeños (y más eficientes) usando solo el entorno de instalación, lo que lleva a ventajas similares como en el caso de Golang-with-environment frente a Golang-just-binaries. En el caso de Java, puede crear un frasco grande o una aplicación instalable que contenga todos los archivos de biblioteca y un script de shell; en el caso de Python, podría usar auditwheel para construir ruedas autocontenidas que son independientes del entorno de compilación (y podría usar C ++ con enlaces estáticos a casi el mismo efecto).

Dos: ¿para qué necesitas la ventana acoplable? En Java land, puedes hacer mucha separación entre diferentes componentes utilizando cargadores de clases, pero el punto principal es qué hay alrededor de la aplicación Java. Ninguna aplicación Java se ejecuta por sí misma: si no se ejecuta en la ventana acoplable, normalmente tendría que ser supervisada por supervisor o por systemd o similares. Ingrese a la nube Kubernetes, Marathon o Docker, que utiliza la abstracción del contenedor para virtualizar no el host en sí, sino que virtualiza toda la red de tal manera que solo puede implementar contenedores y se ejecutan en algún host aleatorio.

Los microservicios generalmente se ejecutan en nubes basadas en ventana acoplable, ya que le permite tratar a sus anfitriones portuarios como ganado, no como mascotas, y de manera similar con las aplicaciones acopladas. Por supuesto, esta abstracción se vuelve permeable tan pronto como monta los volúmenes del host en la ventana acoplable y necesita ejecutar contenedores de la ventana acoplable exactamente en el host que tiene estos volúmenes. Algunas personas se ponen de acuerdo con eso.

Esta es una muy buena pregunta, pero después de trabajar con Docker, lo cambiaría:

  

¿Los beneficios de la JVM se ven afectados por la contenedorización (por ejemplo, Docker)?

Los contenedores realmente desafían muchas de las suposiciones que tengo sobre el desarrollo que provienen de mi experiencia. Por ejemplo, si alguien tuviera que codificar una ruta de acceso a un archivo de recursos en una aplicación, muchos desarrolladores con experiencia sabrían que esto es problemático y que debería configurarlo. Pero si está apuntando a un contenedor, ¿es este realmente el caso? Cuando construyes el contenedor, le dices cuáles son las estructuras de directorio. Estás configurando el camino allí. ¿Entonces deberías configurarlo dos veces? ¿Cuál es el beneficio? Si no los hace coincidir, no funcionará así que ... ¿SECO?

Recientemente creé una aplicación prototipo con Java y Docker que esencialmente observaba los eventos del GC y cuando la parte anterior del montón alcanzó un porcentaje de umbral, se cerró. Docker (modo de enjambre) giraría uno nuevo. Esencialmente, eliminó la necesidad de ciclos de GC importantes en la JVM y permitió que la ventana acoplable los gestione. No funcionó tan bien como esperaba (los clientes vieron algún impacto del cierre) pero fue lo suficientemente funcional como para hacer una demostración en vivo para una multitud.

Deberías probar los contenedores si tienes curiosidad. Realmente es una tecnología disruptiva y tendrás que enfrentarte a ella. Docker es un gran lugar para comenzar, pero hay al menos otra alternativa viable que es buena para todos, IMO.