Asesoramiento en la implementación de archivos war vs jar ejecutable con contenedor integrado

Parece haber una tendencia actual en el espacio java para alejarse de la implementación de aplicaciones web java a un contenedor de servlet java (o servidor de aplicaciones) en forma de archivo war (o archivo ear) y, en su lugar, empaquetar la aplicación como un jar ejecutable con un servidor servlet / HTTP integrado como jetty. Y me refiero a esto más en la forma en que los marcos más nuevos influyen en la forma en que se desarrollan e implementan las nuevas aplicaciones en lugar de cómo se entregan las aplicaciones a los usuarios finales (porque, por ejemplo, entiendo por qué Jenkins usa un contenedor integrado, muy fácil de tomar y usar ). Ejemplos de marcos que adoptan la opción jar ejecutable: Dropwizard , Spring Boot y Play (bueno, no se ejecuta en un contenedor de servlets pero el servidor HTTP está integrado).

Mi pregunta es, viniendo de un entorno en el que hemos implementado nuestras aplicaciones (hasta este punto principalmente Struts2) en un solo servidor de aplicaciones tomcat, qué cambios, mejores prácticas o consideraciones deben realizarse si planeamos usar un enfoque de contenedor integrado ? Actualmente, tenemos alrededor de 10 aplicaciones propias que se ejecutan en un solo servidor Tomcat y para estas aplicaciones más pequeñas, la capacidad de compartir recursos y administrarse en un servidor es agradable. Nuestras aplicaciones no están diseñadas para distribuirse a los usuarios finales para que se ejecuten en su entorno. Sin embargo, avanzando si decidimos aprovechar un marco Java más nuevo, ¿debería cambiar este enfoque? ¿El cambio a archivos jar ejecutables está impulsado por el uso creciente de implementaciones en la nube (por ejemplo, Heroku)?

Si ha tenido experiencia en la gestión de múltiples aplicaciones en el estilo de implementación de Play en comparación con la implementación de archivos de guerra tradicional en un solo servidor de aplicaciones, comparta sus conocimientos.

Interesante pregunta. Esta es solo mi opinión sobre el tema, así que tómate todo con un grano de sal. Ocasionalmente he implementado y administrado aplicaciones utilizando tanto contenedores de servlets como servidores integrados. Estoy seguro de que todavía hay muchas buenas razones para usar contenedores de servlets, pero intentaré concentrarme en por qué son menos populares hoy en día.

Versión corta: los contenedores de servlet son excelentes para administrar múltiples aplicaciones en un solo host, pero no parecen muy útiles para administrar una sola aplicación. Con entornos en la nube, una sola aplicación por máquina virtual parece preferible y más común. Los marcos modernos quieren ser compatibles con la nube, por lo tanto, el cambio a servidores integrados.

Por tanto, creo que los servicios en la nube son la principal razón para abandonar los contenedores de servlets. Al igual que los contenedores de servlets le permiten administrar aplicaciones, los servicios en la nube le permiten administrar máquinas virtuales, instancias, almacenamiento de datos y mucho más. Esto suena más complicado, pero con los entornos en la nube, ha habido un cambio a máquinas de aplicación única. Esto significa que a menudo puede tratar toda la máquina como si fuera la aplicación. Cada aplicación se ejecuta en una máquina con el tamaño adecuado. Las instancias en la nube pueden aparecer y desaparecer en cualquier momento, lo que es ideal para escalar. Si una aplicación necesita más recursos, crea más instancias.

Los servidores dedicados, por otro lado, suelen ser potentes pero con un tamaño fijo, por lo que ejecuta varias aplicaciones en una sola máquina para maximizar el uso de recursos. Administrar docenas de aplicaciones, cada una con sus propias configuraciones, servidores web, rutas y conexiones, etc., no es divertido, por lo que usar un contenedor de servlets te ayuda a mantener todo manejable y a ti mismo sano. Sin embargo, es más difícil escalar. Los contenedores de servlets en la nube no parecen muy útiles. Deberían configurarse para cada instancia pequeña, sin aportar mucho valor, ya que solo administran una única aplicación.

Además, las nubes son geniales y las cosas que no son nubes son aburridas (si todavía creemos en las exageraciones). Muchos marcos intentan ser escalables de forma predeterminada, de modo que se puedan implementar fácilmente en las nubes. Los servidores integrados son rápidos de implementar y ejecutar, por lo que parecen una solución razonable. Los contenedores de servlets generalmente todavía son compatibles, pero requieren una configuración más complicada.

Algunos otros puntos:

• El servidor integrado podría optimizarse para el marco o estar mejor integrado con las herramientas del marco (como la consola de juegos, por ejemplo).
• No todos los entornos de nube incluyen imágenes de máquinas personalizables. En lugar de escribir scripts de inicialización para descargar y configurar contenedores de servlets, el uso de software dedicado para la implementación de aplicaciones en la nube es mucho más sencillo.
• Todavía tengo que encontrar una configuración de Tomcat que no lo reciba con un error de espacio de generación permanente cada pocas redespliegues de su aplicación. Tardar un poco más en (re) iniciar los servidores integrados no es un problema cuando puede cambiar casi instantáneamente entre las instancias de ensayo y producción sin ningún tiempo de inactividad.
• Como ya se mencionó en la pregunta, es muy conveniente que el usuario final simplemente ejecute la aplicación.
• Los servidores integrados son portátiles y convenientes para el desarrollo. Hoy en día todo es rápido , los prototipos y MVP deben crearse y entregarse lo más rápido posible. Nadie quiere pasar demasiado tiempo configurando un entorno para cada desarrollador.