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.