¿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?

Tenía un amigo que dijo:

Docker es asombroso. Puede usarlo para replicar la producción y todas sus peculiaridades en su máquina local. Luego puede implementar esa instancia directamente a través de todos los flujos de trabajo de preparación súper rápidos .

Ahora esto sería cierto si los desarrolladores escribieran Ruby, PHP o Go , donde había un enlace binario de dirección al sistema operativo.

Pero cuando se usa Java , ya existe una capa virtual entre el sistema operativo y el lenguaje, lo que hace que la operación sea coherente independientemente del sistema operativo subyacente.

Podría decirse que, en este caso, se niegan los beneficios de ejecutar Docker para desarrolladores localmente para replicar el entorno de producción . (En comparación con Ruby, PHP o Go).

Estoy abierto a la discusión sobre esto y estoy ansioso por escuchar un punto de vista disidente (con evidencia).

¿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?

De ningún modo.

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 del sistema, que pueden no estar dispuestos a actualizar a 1.8.1.

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

Es posible que esto no le moleste demasiado (hasta que un servidor migre a 1.9, mientras que el otro mantenga la versión anterior), pero esto significaría que ya no está replicando el entorno de producción en su máquina local, lo que hace posible que sea pequeño errores para arrastrarse.

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

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

Esto ni siquiera entra en el software de desarrollo que lo acompaña: eclipse, ant, adobe flex, groovy, firefox y subversion (me estoy saltando bastantes)

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

Sin mencionar el hecho de que cuando implementamos necesitamos mantener más de - 20 servidores; ¡Docker está empezando a parecer un buen negocio!

(20 parece bastante doloroso para una aplicación que solo se ejecuta en un solo servidor a la vez ... pero multiplique ese servidor por clústeres (x2), prueba / puesta en escena / prod (x3), interno / externo (x2) y sitio primario / sitio de copia de seguridad (x2) y llegas allí bastante rápido)

Esta pregunta también sería pertinente para Golang, donde puede extraer binarios estáticamente vinculados y ejecutarlos en algún lugar, en lugar de Python o C ++, donde generalmente tiene una gran cantidad de bibliotecas vinculadas, lo que lleva a las personas a construir un contenedor acoplable desde el entorno de desarrollo.

Hay dos puntos para responder aquí:

Uno: tiene que haber una mejor manera , y la hay: puede construir contenedores acoplables más pequeños (y más eficientes) utilizando solo el entorno de instalación, lo que conlleva ventajas similares como en el caso de Golang-with-environment frente a Golang-just -binarios contenedores. En el caso de Java, puede crear un tarro gordo o una aplicación instalable que contenga todos los tarros de la biblioteca y un script de shell; en el caso de Python, podría usar auditwheel para construir ruedas independientes que sean independientes del entorno de construcción (y podría usar C ++ con enlaces estáticos para casi el mismo efecto).

Dos: ¿para qué necesitas docker? En la tierra de Java, puede hacer mucha separación entre los diferentes componentes mediante el uso de cargadores de clases, pero el punto principal es lo que está alrededor de la aplicación Java. Ninguna aplicación Java se ejecuta por sí sola; si no se ejecuta en Docker, generalmente tendría que ser supervisada por supervisor o systemd o similares. Ingrese a la nube de Kubernetes, Marathon o Docker, que usa la abstracción de contenedor para virtualizar no el host en sí, sino que virtualiza toda la red de tal manera que simplemente pueda implementar contenedores y se ejecuten en algún host aleatorio.

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

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

¿Los beneficios de la JVM son negados por la contenedorización (por ejemplo, Docker)?

Los contenedores realmente desafían muchos de los supuestos que tengo sobre el desarrollo que provienen de mi experiencia. Por ejemplo, si alguien codificara una ruta de acceso a un archivo de recursos en una aplicación, muchos desarrolladores experimentados sabrían que esto es problemático y usted debe hacerlo configurable. Pero si está apuntando a un contenedor, ¿es este realmente el caso? Cuando construye el contenedor, le dice cuáles son las estructuras de directorios. Estás configurando la ruta allí. Entonces, ¿debería configurarlo dos veces? Cual es el beneficio? Si no los haces coincidir, no funcionará así que ... ¿SECO?

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

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