6 razones por las que Open Liberty es una opción ideal para desarrollar y desplegar microservicios – IBM Developer

6 razones por las que Open Liberty es una opción ideal para desarrollar y desplegar microservicios

Introducción

Cuando consideres los microservicios por primera vez, se te perdonará el pensar que lo único diferente es el tamaño de la aplicación. Después de todo, son solo un montón de pequeñas aplicaciones hablando entre sí, ¿cierto? Solo una vez que indagas un poco más, y tal vez te pones en práctica, comienzas a valorar que la creación, contenerización, despliegue y gestión de muchas aplicaciones interconectadas revelan tu propio conjunto de requisitos.

IBM® WebSphere Liberty se creó en 2012 debido a la creciente demanda de un runtime ágil y sencillo. En 2017, debido a la creciente demanda de open source, se creó Open Liberty, la distribución de open source totalmente capaz y ascendente de Liberty. WebSphere Liberty todavía existe y ofrece funciones adicionales que facilitan la modernización de las aplicaciones empresariales tradicionales, pero para la mayoría de las aplicaciones, Open Liberty ofrece todo lo que necesitas.

Liberty simplifica enormemente el desarrollo y el despliegue de aplicaciones sobre los runtimes tradicionales del servidor de aplicaciones. Proporciona la capacidad de crear despliegues del tamaño adecuado, desde menos de 24 MB hasta el soporte completo de Jakarta EE/Java EE. Su arquitectura de migración cero elimina los desafíos de la migración de versión a versión, el ajuste automático ofrece un rendimiento óptimo sin ciclos de ajuste costosos, es fácil de configurar y mucho más. Estas características son ideales para despliegues en la nube, y con la adición de soporte de contenedores de primer nivel y API nativas de la nube, como MicroProfile, Liberty es la elección perfecta para nuevas aplicaciones basadas en microservicios.

Veamos con un poco más de detalle las seis razones principales por las que Liberty es una opción ideal para microservicios nativos de la nube.

Razón 1. Imágenes de tamaño adecuado, sin carga adicional

Al desplegar microservicios, su consumo de recursos (CPU, memoria, etc.) equivale directamente al costo. Si estás desplegando decenas o cientos de microservicios donde alguna vez tuviste una aplicación monolítica, ahora tienes decenas o cientos de instancias más del runtime. Por lo tanto, es importante que tus microservicios consuman recursos de manera adecuada. Si estás desplegando cientos de microservicios pequeños, no quieres que cada microservicio obtenga cientos de megabytes de runtime del servidor y bibliotecas.

Liberty es un runtime completamente modular que te permite elegir las capacidades que necesitas para tu aplicación. Con Liberty, tienes un runtime, un enfoque, para desarrollar y desplegar aplicaciones que escalan desde pequeños microservicios hasta monolitos empresariales modernos completos y cualquier cosa intermedia.

La siguiente tabla muestra las medidas de memoria y disco para tres ejemplos de paquetes de runtime. La primera fila contiene todas las API más recientes para Java EE/Jakarta EE y MicroProfile (todo lo que puedes necesitar para un monolito moderno nativo de la nube), la segunda fila contiene suficiente runtime para admitir MicroProfile 3.3 (todo lo que puedes necesitar para un microservicio típico) y la tercera fila contiene suficiente runtime para ejecutar Servlet 4.0 (el mínimo absoluto que puedes necesitar para ejecutar un marco web simple). Es posible ver que a medida que ajustamos el tamaño correcto de Liberty para un conjunto reducido de necesidades, los requisitos de disco y memoria también disminuyen, que es exactamente lo que querrías de un runtime.

Paquete Tamaño en disco Memoria
Java EE 8/Jakarta EE 8 + MicroProfile 3.3 121 MB 165 MB
MicroProfile 3.3 59 MB 113 MB
Servlet 4.0 24 MB 72 MB

Razón 2. Bajo costo operativo: menos memoria, mayor rendimiento son la clave

El cambio de aplicaciones monolíticas a estilos de arquitectura que dio como resultado decenas o cientos de aplicaciones menores desplegadas ha llevado a un cambio en la importancia de las diferentes características de rendimiento del runtime. Es posible escuchar mucho sobre «arranque en frío», y esto es de vital importancia para las funciones de la nube (El tiempo de Liberty para la primera respuesta es de aproximadamente 1 segundo, por lo que no se queda atrás), pero para los microservicios es probable que cada instancia en ejecución atienda miles de solicitudes antes de ser reemplazada. Dado el perfil de uso esperado de decenas a cientos de servicios con miles de solicitudes, las métricas de rendimiento más importantes son el consumo de memoria y el rendimiento; estos son los que tendrán el mayor impacto en el costo.

Comparaciones del impacto

La siguiente figura muestra la comparación del impacto después del inicio para los servidores que ejecutan el punto de referencia Acme Air Microservices. En este contexto, Liberty utiliza entre 2,5 y 10 veces menos memoria que otros runtimes.

Comparación del impacto del gráfico de barras de Open Liberty, WildFly, TomEE, Payara y Helidon

Si has elegido Spring Boot para tu aplicación, entonces hay un beneficio de aproximadamente el doble de espacio en memoria de ejecutar en Liberty, como podrás ver en la siguiente figura que muestra el uso de memoria relativo cuando se ejecuta la aplicación Spring Boot Petclinic sometido a carga con un montón de 4 GB.

Gráfico de barras que muestra un beneficio de espacio de memoria 2 veces mayor cuando se ejecuta Spring Boot Petclinic en Liberty, en comparación con Tomcat, sometido a carga

Comparaciones de rendimiento

Liberty también tiene importantes beneficios de rendimiento en comparación con otros runtimes. La siguiente figura muestra las mediciones de rendimiento en comparación con el punto de referencia de Acme Air Microservices. Liberty tiene el mejor rendimiento general en todos los runtimes probados y es significativamente superior que la mayoría de ellos.

Gráfico de barras que muestra el rendimiento de Liberty mejor que WildFly, 2 veces mejor que TomEE y 5 veces mejor que Payara y Helidon

La siguiente figura muestra un beneficio de rendimiento de casi el doble cuando se ejecuta la aplicación Spring Boot Petclinic en Liberty, en lugar de Tomcat.

Gráfico de barras que muestra un beneficio de rendimiento 2 veces mayor cuando se ejecuta Spring Boot Petclinic en Liberty, en comparación con Tomcat, sometido a carga

La combinación de los beneficios de la memoria y el rendimiento equivale a un ahorro de más de 4 veces (rendimiento por MB) para esta aplicación Spring Boot en Liberty y un beneficio de 3,5 mayor que el más próximo de los otros runtimes comparados. Eso es posiblemente un ahorro de más de 3 veces en la nube y costos de licencia.

Razón 3. Entrega continua: bajo mantenimiento, deuda técnica cero

El cambio a microservicios y nativos de la nube a menudo conduce a un cambio en la responsabilidad de propiedad del runtime. Un solo equipo multidisciplinario desarrolla, empaqueta y despliega una aplicación (por ejemplo, microservicio) como un contenedor inmutable que incluye el runtime del servidor; incluso las aplicaciones Spring Boot integran un servidor (por ejemplo, Tomcat, Jetty o Liberty). El equipo de operaciones gestiona una plataforma en la nube basada en Kubernetes, como Red Hat OpenShift, en la que los equipos de aplicaciones despliegan sus contenedores.

En el nuevo mundo nativo de la nube, lo que a menudo no se valora, hasta que es demasiado tarde, es que el equipo de desarrollo ahora es responsable del mantenimiento del runtime, que forma parte del contenido del contenedor. Antes, el equipo de operaciones gestionaba la menor cantidad de instancias de runtime del servidor, implementando cuidadosamente las actualizaciones de versiones principales o de servicio, y asegurando que se aplicaran ‘arreglos provisionales’ de seguridad críticos. Ahora, los equipos de desarrollo que ofrecen decenas o cientos de aplicaciones, cada una de las cuales incorpora un runtime, son responsables de garantizar que esos runtimes se mantengan actualizados y libres de vulnerabilidades. Entonces, ¿de qué forma Liberty ayuda con este problema?

La primera parte de la respuesta es liberar con frecuencia. Liberty tiene un ciclo de versión de ‘entrega continua’, enviando una nueva versión cada cuatro semanas. Las correcciones enviadas para la versión anterior se transfieren de forma automática a la siguiente. Por lo tanto, con la entrega continua, no es necesario solicitar el servicio, lo obtienes de forma automática. Todas las versiones de Liberty están disponibles en Maven Central y Docker Hub, lo que hace que sea mucho más sencillo adquirir la más reciente a través de la automatización de compilación. Los equipos de desarrollo pueden simplemente recrear sus contenedores para obtener la última versión, confiando en que contiene correcciones a la versión anterior. La segunda parte de la respuesta es ‘migración cero’, que se analiza en la siguiente sección.

Por supuesto, si no estás cambiando la forma en que entregas tus aplicaciones, pero aún quieres los beneficios de Liberty, entonces el ciclo de versión de Liberty y las opciones de soporte también lo permiten. Cada versión de Liberty viene con cinco años de soporte, y cada tercera versión en un año (versiones que terminan con 3, 6, 9 y 12) viene con dos años de soporte de ‘arreglos provisionales’, lo que permite un ciclo de actualización más tradicional. Tampoco hay necesidad de extensiones de soporte porque cada nueva versión de cuatro semanas restablece el reloj de soporte de cinco años. Para más detalles, consulta la Política de soporte de Liberty.

Razón 4. Migración cero: mantenerse actualizado, sin esfuerzo

Liberty es el único runtime de Java que proporciona ‘migración cero.’ Migración cero significa que, en cuestión de minutos, es posible pasar a la última versión de Liberty sin tener que cambiar el código o la configuración de tu aplicación. Históricamente, este tipo de cambios causaba temor en los equipos, debían planificarse con meses de anticipación y demorar más de un año en completarse; eso es una gran inversión solo para mantenerse actualizados.

Liberty permite la migración cero mediante el uso de «funciones» versionadas. En Liberty, las API se proporcionan mediante funciones; por ejemplo, hay una función para servlet-3.1. Cuando se introducen nuevas capacidades que interrumpirían las aplicaciones existentes o cuando sale una nueva versión de especificación, Liberty proporciona una nueva versión. Entonces, cuando salió Java EE 8 y hubo cambios importantes, se creó una función de servlet-4.0 junto con la función de servlet-3.1, y una aplicación puede optar por usar una u otra. Por lo tanto, migrar tu aplicación es una decisión separada de la actualización del nivel de Liberty. Si quieres tener el último nivel de Liberty, pero no migrar tu aplicación y configuración, es posible continuar utilizando las mismas funciones (por ejemplo, servlet-3.1). Esto significa que es posible obtener las últimas correcciones en runtime sin tener que pasar por una migración difícil. Cuando estés listo para aprovechar las últimas API (por ejemplo, servlet-4.0), es posible actualizar la configuración y aplicación de tu servidor para usarlo.

Combinar la entrega continua con migración cero significa estar al día con las correcciones, con una inversión mínima y elegir invertir en cambios de aplicaciones cuando existe una necesidad comercial y un beneficio para hacerlo.

Razón 5. Optimizado para Kubernetes: ajuste automático, integración nativa

La mayoría de las grandes empresas ahora ejecutan Kubernetes en producción y los contenedores, así como Kubernetes se consideran parte integral de la entrega de microservicios nativos de la nube. La entrega continua de microservicios basados en contenedores necesita un runtime que admita las mejores prácticas de contenedores y orquestación de contenedores (Kubernetes). Tiene que ser fácil para:

  • Conseguir el mejor rendimiento sin saber dónde se desplegará el contenedor.
  • Crear y mantener imágenes seguras y compatibles.
  • Integrar el runtime y la aplicación con el entorno de orquestación de contenedores.

Sin estas cualidades, los microservicios serán ineficientes, difíciles de mantener y seguros, así como difíciles de gestionar. Las siguientes secciones explican cómo Liberty ayuda a brindar la experiencia ideal de Kubernetes.

Runtime de ajuste automático

Al desplegar a entornos de contenedores de nube pública o privada, es importante poder obtener el mejor rendimiento de la aplicación. Esto no es exclusivo de los contenedores, pero los contenedores hacen que el ajuste sea más desafiante. Para abordar esto, Liberty realiza dos cosas:

La siguiente figura muestra el rendimiento de Liberty basado en diferentes latencias de solicitudes. Es posible ver que el ajuste automático alcanza rápidamente el rendimiento óptimo. Y si la latencia cambiara con el tiempo, Liberty se ajustaría apropiadamente.

Gráfico de líneas mostrando que el rendimiento de Liberty alcanza rápidamente el rendimiento máximo mediante el ajuste automático de su grupo de subprocesos

Imágenes listas para producción

Para cada nueva versión de Liberty, se cargan nuevas imágenes de contenedor de Universal Base Image en Docker Hub. Las imágenes se pueden distribuir gratuitamente: cumplen con OCI (Open Container Initiative), con soporte disponible si lo deseas. Las imágenes de Open Liberty y WebSphere Liberty son cargadas y mantenidas según la [política de soporte] de Liberty(https://www.ibm.com/support/pages/single-stream-continuous-delivery-sscd-software-support-lifecycle-policy-websphere-liberty). Las correcciones a las vulnerabilidades de seguridad críticas se aplican automáticamente y las imágenes se actualizan, para que tú no tengas que hacerlo.

Si las imágenes no son exactamente de tu agrado, entonces los scripts y Dockerfiles Open Liberty y WebSphere Liberty utilizados para crearlos son de open source y están disponibles para su propia personalización y todos los artefactos necesarios están disponibles en repositorios públicos como Maven Central y Docker Hub.

Integración de Kubernetes

Kubernetes se ha convertido rápidamente en la tecnología de orquestación preferida cuando se pasa a contenedores. Las plataformas basadas en Kubernetes, como OpenShift, te permiten desplegar contenedores, ampliarlos o reducirlos e incluso para que llegue a cero.

Los operadores son el enfoque preferido de gestión de Kubernetes. El Open Liberty Operator permite una gestión de primer nivel de Liberty en Kubernetes y OpenShift. Simplifica enormemente el despliegue y configuración de aplicaciones, clustering, integración de persistencia, enlace de servicios, determinación de problemas y mucho más.

Algunos aspectos del ciclo de vida del contenedor y de la gestión del tráfico necesitan ayuda del runtime en el contenedor. Por ejemplo, Kubernetes reiniciará un contenedor si cree que no está funcionando y no enviará solicitudes a un contenedor si cree que no está listo. Las sondas de Kubernetes Liveness y Readiness proporcionadas por el contenedor se utilizan para indicar el estado del contenedor/aplicación. El soporte de MicroProfile Health en Liberty está diseñado para que sea realmente simple proporcionar este nivel de integración de orquestación de contenedores.

Razón 6. Herramientas para desarrolladores que ayudan, no obstaculizan: detección de contenedores, enfocadas en CD

Una experiencia de desarrollador de primer nivel es una parte integral de la entrega eficiente de nuevas funciones y correcciones. Durante muchos años, Liberty ha tenido un fuerte enfoque en ayudar a los desarrolladores a ser productivos con las herramientas que eligen. Liberty se integra con las herramientas de compilación más populares, Maven y Gradle, incluida la liberación de todos los binarios de runtime en Maven Central. El soporte de Liberty Maven y Gradle también proporciona, ‘modo de desarrollo,’ lo que significa que los desarrolladores pueden crear código y cambios de configuración y que tengan efecto inmediato en un servidor en ejecución local, incluso en un servidor que se ejecute en un contenedor local. Esto elimina la necesidad de una reconstrucción completa y un nuevo despliegue, reduciendo en gran medida el tiempo necesario para desarrollar y probar las actualizaciones; y el soporte de contenedores significa que es posible desarrollar y probar en un entorno más cercano a la producción.

Las pruebas de aplicaciones nativas de la nube presentan la necesidad de realizar pruebas en contenedores. Realizar pruebas de integración fiel a la producción en un contenedor reduce en gran medida las posibilidades de que los problemas lleguen a la producción. Las pruebas ‘MicroShed‘ permiten exactamente eso, con la capacidad de ejecutar pruebas de integración JUnit contra una aplicación Liberty que se ejecuta en un contenedor, incluida la integración con contenedores que ejecutan bases de datos y Kafka.

El modo de desarrollo permite el despliegue en caliente, pruebas en caliente, depuración en caliente y más en los editores de código más populares: IntelliJ, Eclipse, VS Code, incluso vi. La combinación del modo de desarrollo con las API de MicroProfile y las pruebas de MicroShed te ofrece una experiencia integral de desarrollador nativa de la nube. ¡Estamos continuamente brindando nuevas capacidades para que tu experiencia como desarrollador sea increíble!

Mira el siguiente video para ver cómo Open Liberty Tools para la extensión IntelliJ facilita aún más el desarrollo con el modo de desarrollo Open Liberty en IntelliJ:

Conclusión

El cambio a despliegues de microservicios nativos de la nube más detallados conduce a nuevos desafíos para los equipos de desarrollo y operaciones: la necesidad de runtimes con alto rendimiento y bajo uso de recursos; la necesidad de integración de contenedores y Kubernetes de primer nivel; la necesidad de poder mantenerse seguro actualizándose de forma sencilla y frecuente; y mucho más.

Este artículo ha destacado seis capacidades de Liberty que abordan estos nuevos desafíos:

  • Runtime del tamaño correcto
  • Bajo costo operativo
  • Entrega continua
  • Migración cero
  • Optimizado para Kube
  • Gran experiencia de desarrollador

Estas capacidades hacen de Liberty una opción ideal para el desarrollo y el despliegue de microservicios.

Próximos pasos

Si quieres tú mismo experimentar Liberty, consulta las prácticas de las guías de Open Liberty.