Elige el runtime de Java adecuado para el trabajo – IBM Developer

Elige el runtime de Java adecuado para el trabajo

Introducción

El IBM® adquisición de Red Hat® significa que la empresa conjunta ahora tiene varios runtimes de aplicaciones Java, que incluyen:

Esto ha llevado a los clientes a hacerse dos preguntas:

  • ¿Qué runtime debo elegir?
  • ¿Cuándo se racionalizarán los ‘runtimes A y B’?

La respuesta a la segunda pregunta es simple: no hay planes para eliminar o fusionar ninguno de los runtimes. Cada uno tiene una base de clientes significativa y leal que necesita la continuidad de los runtimes que están usando. Las eficiencias de desarrollo ya se logran mediante la colaboración en proyectos de code patter, como SmallRye y Apache CXF.

Este artículo abordará la primera pregunta. La respuesta no es tan simple como «Usa runtime X» o incluso: «Para microservicios, usa runtime X». Para elegir un runtime o runtimes, es importante comprender tres cosas:

  • Tu estado actual de aplicaciones, necesidades comerciales y estrategia para esas aplicaciones
  • Las fortalezas del estilo de la arquitectura de la aplicación de cada runtime
  • Los estilos de arquitectura de la aplicación que esperas desplegar

Las secciones siguientes de este artículo detallan los dos últimos puntos. El artículo también analiza cómo elegir un runtime basado en los tres.

La evolución de los runtimes

Para comprender las características de cada runtime y cómo pueden aplicarse, vale la pena recordar su historial, ya que esto influye en gran medida en los tipos de aplicaciones para las que son más adecuados.

Aplicaciones empresariales tradicionales

La comercialización de la World Wide Web y la estandarización de la tecnología de servidor de aplicaciones Java hicieron con que varios proveedores crearan productos de servidor de aplicaciones. WebSphere Application Server y lo que se convirtió en Wildfly y JBoss EAP, se lanzaron por primera vez a fines de los años 90. El hardware en el que se ejecutaban tenía una eficiencia informática sencilla para los estándares actuales: las redes eran significativamente más lentas y aún tenían que estandarizarse en torno a Ethernet, además, las capacidades de memoria y disco eran limitadas (pasarían 10 años antes de que se liberara el primer HDD de 1 TB). La entrega de software también estuvo dominada por Waterfall y por las prácticas de ingeniería asociadas. Esto claramente llevó al desarrollo y a la entrega de aplicaciones monolíticas. Por supuesto, en aquellos días se les llamaba simplemente «aplicaciones» porque no había otros tipos. Vale la pena aclarar que las aplicaciones monolíticas no son malas: los monolitos que no se pueden mantener son malos y es posible crear sistemas que no se pueden mantener utilizando cualquier estilo de arquitectura. A principios de la década de 2000, las máquinas virtuales surgieron con el objetivo de simplificar los despliegues de servidores, pero el clustering se realizó de una manera específica para cada tipo de runtime desplegado (por ejemplo, WebSphere ND Cells).

Las restricciones, prácticas y ciclos de entrega prolongados llevaron a que los runtimes de Enterprise Java se optimizaran para tiempos de actividad largos, estables y de alto rendimiento; una vez desplegados el servidor y la aplicación, querías que siguiera funcionando de cualquier forma.

La agilidad empresarial exige agilidad en runtime

En los años que siguieron, la demanda cada vez mayor de una entrega más rápida y escalable impulsó avances significativos en la infraestructura y en las metodologías. Los procesadores, la red y el almacenamiento crecieron en velocidad y capacidad, y la entrega de software adoptó prácticas ágiles. El impulso por un tiempo de comercialización más rápido llevó a una creciente demanda de runtimes más leves que ayudaron al objetivo de entregar aplicaciones más rápido. En respuesta a estas demandas, en 2012 IBM creó WebSphere Liberty.

Liberty tomó una nueva visión sobre cómo abordar las demandas de entrega y desarrollo rápidos de aplicaciones: las necesidades de ser sencillos, simples de configurar, simples de desplegar y admitir las mejores prácticas y herramientas emergentes. Las aplicaciones desarrolladas en ese momento seguían siendo en su mayoría monolíticas pero, con la ayuda de Liberty, eran más fáciles y rápidas de entregar. Liberty comenzó apoyando aplicaciones web simples, pero debido a la demanda de los clientes creció rápido para admitir todas las capacidades de Java EE. La capacidad de Liberty para instalar y configurar ‘el runtime suficiente’, solo las capacidades requeridas por la aplicación, significaba que no sufría el exceso de runtime normalmente asociado con los servidores de aplicaciones empresariales. Con anterioridad a los contenedores y plataformas de orquestación de contenedores, Liberty también agregó las capacidades de gestión de clustering y salud (basadas en Liberty Collectives) exigidas por las empresas.

Durante los siguientes cinco años, el open source se convirtió en un aspecto cada vez más importante de la adopción de software. En apoyo de este cambio, en 2017, Liberty pasó a un modelo de desarrollo primero de open source mediante el open source de WebSphere Liberty como Open Liberty bajo la licencia pública Eclipse.

Arquitecturas para despliegues rápidos, flexibles y escalables

Muchas aplicaciones monolíticas crecieron a lo largo de los años y, a menudo, se perdía cualquier consideración por su modularidad, lo que las hacía difíciles de mantener y ampliar. Las empresas que buscaban reducir aún más el tiempo de entrega y aumentar la escalabilidad para demandas de carga de trabajo mucho mayores se vieron limitadas por la naturaleza inherente del monolito de «desplegar todo, escalar todo». Para lograr una mayor flexibilidad y escalabilidad, estas aplicaciones debían reinventarse como muchas unidades más pequeñas, que podrían desarrollarse, desplegarse y escalarse de forma independiente, es decir, microservicios y funciones (a menudo desplegadas en nubes en entornos Functions as a Service [FaaS]).

El cambio de una aplicación monolítica a muchos microservicios o funciones ha impulsado la demanda de tecnologías que simplifican las operaciones y reducen los costos de infraestructura. Los contenedores y las plataformas de orquestación de contenedores basadas en Kubernetes, personificadas por Red Hat OpenShift®, se han convertido rápidamente en sinónimos de microservicios. Contenedores que permiten despliegues aislados sencillos y Kubernetes que permite el despliegue, gestión y clustering consistentes de contenedores, eliminando la necesidad de enfoques de clustering centrados en el runtime, como ND Cells y Liberty Collectives.

El aumento de la popularidad de los microservicios llevó a la demanda de nuevos estándares de API, por lo que varios proveedores y grupos de usuarios de Java se unieron, lo que resultó en la creación de las especificaciones de Eclipse MicroProfile. MicroProfile evolucionó rápidamente para proporcionar un conjunto completo de API de microservicio abierto, con varios runtimes que también brindan soporte, incluidos Liberty, WildFly, JBoss EAP, Payara, TomEE y Quarkus.

El impulso por componentes más detallados desplegados como microservicios o funciones ha llevado a una mayor demanda de runtimes más sencillos y rápidos. En 2019, Red Hat liberó Quarkus, un runtime diseñado específicamente para estos estilos de arquitectura. Al hacerlo, posicionó firmemente a Quarkus para nuevas funciones y microservicios, solo admitiendo el subconjunto de las API de Java cubiertas por la compilación nativa.

Liberty y Quarkus ofrecen excelentes perfiles de runtime basados en JVM para microservicios, respondiendo a las primeras solicitudes en aproximadamente un segundo. Además, Quarkus ofrece una capacidad nativa de compilación, lo que brinda un perfil de ejecución adecuado para las funciones, donde la optimización para un solo pedido es importante.

Espectro de estilos arquitectónicos

Los últimos años han tenido un fuerte enfoque en la entrega de arquitecturas de microservicios. Al igual que con cualquier concepto nuevo, el sector pasa por un proceso de descubrimiento y, últimamente, aprende la mejor manera de aplicarlo. Antes de alcanzar este estado planeado, existe una tendencia a aplicar en exceso una tecnología, lo que conduce a malos resultados. Gartner se refiere a este proceso de aprendizaje como el «Gartner Hype Cycle» y actualmente ubica los microservicios en el «Trough of Disillusionment». Esto no significa que los microservicios sean malos; simplemente que estamos en un momento en el que estamos comenzando a valorar realmente dónde los microservicios son apropiados y dónde no.

Una búsqueda rápida en internet revela un número creciente de artículos que debaten sobre monolitos, microservicios y funciones. También hay ejemplos que hablan de estilos entre monolitos y microservicios, utilizando términos como «macroservicio» o «macrolito». En algunos casos, esta es una reacción a la descomposición excesiva en microservicios que son demasiado finos, lo que lleva a un sistema demasiado complejo donde la complejidad supera los beneficios. En otros, es un intento directo de encontrar el equilibrio adecuado entre las características funcionales y no funcionales de cada estilo de arquitectura. Entre los ejemplos destacados de empresas que cambian los estilos de arquitectura a lo largo del tiempo se incluyen Los equipos de Uber ahora desplegan macroservicios más generales, así como microservicios, y Segment, que cambió de un monolito a microservicios y luego volvió a monolito.

Lo que está claro es que estamos viendo una creciente apreciación de los pros y contras de diferentes estilos de arquitectura, y esperamos que continúe aumentando en los próximos años. En lugar de asumir que todas las aplicaciones serán microservicios, una mejor comprensión de las necesidades de la aplicación, infraestructura y capacidades del equipo informará la elección de un estilo de arquitectura apropiado. Habrá una mayor apertura para desplegar múltiples estilos de arquitectura y también para evolucionar entre estilos de arquitectura a medida que aumenten las necesidades.

Características de los estilos de arquitectura

Al elegir qué estilo de arquitectura puede ser apropiado, es importante comprender sus características. A seguir se muestran algunas características clave y cómo varían entre los diferentes estilos de arquitectura. Es importante comprender que algunas características no se logran automáticamente mediante la elección del estilo de arquitectura; son beneficios potenciales que requieren inversión tecnológica u organizacional para alcanzarlos. Por ejemplo, si no inviertes en tecnología de automatización, será difícil entregar actualizaciones de microservicios más seguido.

Diagrama que muestra cómo varían las características no funcionales a medida que pasamos de estilos de arquitectura más generales a estilos de arquitectura más detallados

Comenzando por las características más bajas, veámoslas con más detalle:

  • Precios: Hay pros y contras de CapEx (gasto de capital, un costo inicial único para la adquisición) y OpEx (gasto operativo, un gasto regular que autoriza/cubre el uso). Functions as a Service es inherentemente OpEx y con la medición más detallada de cualquier modelo. Los monolitos son a menudo CapEx, pero hay formas de minimizar el costo a más de un modelo de OpEx (por ejemplo, licencias de plazo comprometido).

  • Frecuencia/complejidad de entrega y complejidad operativa: Ambos se relacionan con el hecho de que a medida que pasamos de estilos de arquitectura más generales a más detallados, estamos aumentando la cantidad de artefactos que creamos, desplegamos, gestionamos, depuramos y reparamos. Hay un costo asociado con esto, pero también beneficios.

  • Modularidad: Una de las grandes desventajas de los monolitos es la dificultad para hacerlos modulares y preservar esa modularidad a lo largo del tiempo. A medida que pasamos de más general a más detallado, descomponemos aún más una aplicación en partes cada vez más pequeñas, pero también introducimos límites de proceso y red como una forma de imponer la modularidad. Esto aumenta las posibilidades de crear soluciones más flexibles y sin conexión directa. Una advertencia, ya que algunos han encontrado muy fácil crear un monolito distribuido, lo peor de ambos lados, no hay sustituto para una buena arquitectura.

  • Demanda de red y aislamiento de fallas: Estos dos vienen juntos. La distribución de más y más componentes significa mayor uso y dependencia de la red. El rendimiento de la red se convierte en un factor clave en el rendimiento general de la solución. La confiabilidad de la red también afecta la disponibilidad general de la solución. Un mayor aislamiento ayuda a evitar fallas en cascada que destruyen toda la solución, pero es necesario desplegar técnicas defensivas de tolerancia a fallas, como mamparos, reintentos y soporte, para aprovechar el aislamiento.

  • Exigencias de runtime: Los diferentes patrones de arquitectura favorecen no solo diferentes características de runtime, sino también diferentes enfoques para usar el runtime. Para aplicaciones más generales, los ciclos de entrega suelen ser más largos y, por lo tanto, favorecen la estabilidad del runtime durante un período prolongado. La prioridad es que el runtime funcione bien durante el período más prolongado en el cual se despliega la aplicación. También es típico que el servidor sea algo que tú administras y optimizas directamente, y luego despliegas una o más aplicaciones. Para aplicaciones más detalladas, debido a que los ciclos de entrega son más cortos, la cantidad de solicitudes es menor y la cantidad de instancias es mucho mayor, la atención se enfoca en que los runtimes sean pequeños y rápidos de comenzar. También hay un cambio del despliegue centrado en el servidor a centrado en la aplicación, donde el servidor se lleva junto con la aplicación (por ejemplo, en una capa de imagen de contenedor inferior).

    Un último punto que exploraremos en la siguiente sección es la correlación entre las necesidades de API y los patrones de arquitectura. Para las aplicaciones más generales, normalmente usas muchas API diferentes en una sola aplicación, mientras que, para las aplicaciones más detalladas, cada función o microservicio tiene necesidades de API más sencillas.

Elección de runtimes

Hemos visto cómo la historia y la evolución de cada runtime ha influido fuertemente en los estilos de arquitectura para los que son más adecuados. Hemos visto cómo las empresas aprecian cada vez más los beneficios de los diferentes estilos de arquitectura y cuántas serán flexibles en su uso. También hemos visto muchas de las características asociadas con cada estilo de arquitectura y cómo se pueden usar para ayudar a decidir qué estilos usar y, posiblemente, mezclar o cambiar estilos con el tiempo. Pero ¿qué significa eso en términos de elección de runtime?

Basado en el historial y evoluciones de cada runtime, la siguiente figura muestra los estilos de arquitectura a los que se aplica cada runtime, trazados contra las ‘necesidades de API’ de una aplicación (las necesidades de API de una aplicación tienden a estar correlacionadas con el ‘tamaño’ de la aplicación).

Diagrama que muestra qué runtimes son adecuados para diferentes estilos de arquitectura según las necesidades de API de las aplicaciones

Este diagrama muestra que, sea cual sea el estilo de arquitectura elegido, IBM y Red Hat lo cubren. En un control más cercano, vemos que hay tres opciones para monolitos (WebSphere Application Server tradicional, JBoss EAP y Liberty) y dos opciones para microservicios (Liberty y Quarkus). Sin embargo, en lugar de discutir cuál es mejor para un estilo de arquitectura específico, es importante considerar la herencia de cada runtime, la estrategia para cada una de sus aplicaciones y los estilos de arquitectura que probablemente utilizarás. Los siguientes tipos de ejemplo pueden ayudar:

  • Si tienes monolitos existentes que deseas que sigan funcionando y estables con una mínima inversión en ingeniería, entonces deben permanecer en WebSphere Application Server y EAP tradicionales.

  • Si estás buscando desplegar nuevas funciones y microservicios, las API específicas y la compilación nativa de Quarkus hacen que sea una buena opción. La capacidad de imagen nativa de Quarkus te brindará las características de runtime ideales para las funciones.

  • Si estás buscando modernizar tus aplicaciones empresariales existentes, entonces el runtime sencillo y completo Java de Liberty es una buena opción. Estas aplicaciones a menudo se escriben en Java EE, por lo que elegir un moderno runtime con capacidades completas de Java EE será bueno a largo plazo. Si estás modernizando desde el WebSphere Application Server tradicional, WebSphere Liberty también proporciona API diseñadas para optimizar esta ruta de modernización.

  • Si estás buscando crear nuevos monolitos modernos, nuevos microservicios o algo intermedio, las capacidades y flexibilidad de Liberty hacen que sea una buena opción. Esto se debe a que Liberty fue diseñado como un moderno runtime de Java completo para aplicaciones monolíticas, además de estar optimizado para microservicios sencillos y de alto rendimiento, lo que te brinda la flexibilidad de elegir y cambiar entre estos estilos de arquitectura.

Conclusión

Este artículo ha mostrado cómo la apreciación del sector por los diferentes estilos de arquitectura de aplicaciones está evolucionando hacia un enfoque más matizado, donde los estilos de arquitectura se eligen en función de las necesidades comerciales de la aplicación, tecnología y capacidad organizativa. Este artículo también discutió cómo el historial de un runtime de Java influye fuertemente en su aplicabilidad a los diferentes estilos de arquitectura. Finalmente, mediante el uso de una pequeña cantidad de situaciones, el artículo ha proporcionado un enfoque para seleccionar el runtime o runtimes correctos, para adaptarse a tu estilo o estilos de arquitectura preferidos. Esperamos que te haya sido útil.