Llegamos a ustedes gracias a:



Reportajes y análisis

13 frameworks de Java para crear microservicios sólidos

[15/01/2018] Ha sido un largo viaje para Java, un lenguaje que comenzó como la lengua franca para la caja en la parte superior del televisor en los días en que los televisores no tenían Roku o Chromecast integrados. Luego, poseyó la World Wide Web al animar el navegador antes de que apareciera JavaScript y la apartara del camino.

Java terminó por encontrar un nicho en las granjas de servidores donde una vez había arquitecturas de chips y sistemas operativos lo suficientemente diferentes como para hacer que el "write once, run anywhere sea prometedor; y es en esas granjas de servidores en las que Java, uno de los favoritos de los negocios de TI empresarial adictos a la confiabilidad y los desarrolladores apasionados por la tipificación, ha vivido.

Mientras tanto, JavaScript en general, y Node.js en particular, han desafiado a Java en el servidor, usando su alto rendimiento y velocidad libre de hilos para controlar una gran parte del tráfico en la web. Node ha capturado la imaginación de los nuevos programadores del lado del servidor, ofreciendo no solo velocidad y eficiencia de recursos, sino también la simplicidad del código que se ejecuta tanto en el cliente como en el servidor.

Sin embargo, a pesar del aumento de la competencia, Java continúa no solo sobreviviendo sino también sobresaliendo. Muchos de los equipos encargados del desarrollo de arquitecturas de microservicio siguen utilizando Java. Una razón importante debe ser porque la tecnología ha sido puesta a prueba por años en el frente de batalla analizando las solicitudes HTTP. Sun creó una máquina virtual sólida, y Oracle continúa nutriéndola y apoyándola.

Otra razón debe ser la continua evolución del lenguaje. Java 8 ofrece un soporte sólido para los lenguajes funcionales como Scala y Kotlin. La JVM es ahora una base para muchos de los mejores experimentos en desarrollo de lenguajes informáticos. Docenas de nuevos lenguajes pueden ser compilados en el código byte de Java, y conectarse entre sí para hacer que los proyectos complejos trabajen juntos. Muchas de las pilas que se ejecutan sin problemas en una JVM pueden estar formadas por una mezcla de Java y varios otros idiomas.

Sin embargo, la principal razón debe ser la pura inercia. Mientras escribo, 371 trabajos para programadores COBOL son enumerados en Dice. Hay muchos, muchos más trabajos con la palabra Java en ellos. ¿Acaso es una sorpresa que los equipos inteligentes estén viendo sus enormes pilas de códigos Java antiguos y piensen que la solución más sencilla sea simplemente agregar una puerta lateral que escupa los datos como estructuras de datos JSON? Voilà. El código antiguo sigue funcionando, pero actúa como un microservicio moderno en estas puertas laterales.

Todas estas opciones y más aseguran que Java continúe desempeñando un papel importante y vital en la revolución del microservicio, y no es de extrañar que la comunidad de código abierto de Java haya seguido adelante, creando muchas nuevas opciones para sus programadores, que necesitan enseñar su código Java para hablar como un microservicio.

Aquí hay una lista de 13 opciones de código abierto que los desarrolladores de Java están utilizando para desarrollar soluciones que forman la base de las arquitecturas de microservicio en todas partes.

Spring Boot

El mundo Java ha estado construyendo aplicaciones de Spring durante mucho tiempo. Spring Boot es una versión particular de Spring que facilita mucho el proceso al manejar muchos de los detalles de configuración por usted. Spring Boot fue creado para automatizar el inicio de los proyectos de Spring de cualquier tipo, no solo microservicios. Para simplificar aún más las cosas, una vez que ha terminado con la aplicación, Spring Boot se mezcla en un servidor web y emite un solo archivo JAR que es prácticamente todo lo que necesita, además de la JVM. Piense en ello como el contenedor original de Docker.

Toda esta inteligencia es apreciada por muchas de las personas encargadas de construir microservicios, porque la configuración se vuelve molesta cuando tiene que hacerla una y otra vez para cada una de la docena de microservicios. Si Spring Boot puede automatizarlo, producir muchas docenas de microservicios es mucho más fácil.

Los microservicios desarrollados con Spring siguen la misma filosofía MVC que las aplicaciones macro web que hemos estado construyendo durante años. El framework disfruta de todas las conexiones profundas construidas durante años de desarrollo de Java, incluyendo la integración con todos los almacenes de datos principales y secundarios, servidores LDAP y herramientas de mensajería como Apache Kafka. También hay docenas de características pequeñas y no tan pequeñas para mantener una colección de servidores en ejecución, tales como Spring Vault, una herramienta para mantener los secretos, contraseñas y credenciales que necesitan los servidores en producción. Todas estas ventajas muestran por qué los programadores de Java se han subido al carro por muchos años.

Eclipse MicroProfile

En el 2016, algunos de los fanáticos de la comunidad Java Enterprise miraron a su alrededor y decidieron limpiar todo el cruft de la mencionada edición para que las personas pudieran construir microservicios simples con las piezas clásicas. Lanzaron un número sorprendente de bibliotecas, pero mantuvieron el código para procesar las solicitudes REST, analizar JSON y administrar la inyección de dependencias. Así, terminaron con algo rápido y simple, Eclipse MicroProfile.

Desde entonces, la comunidad MicroProfile hizo un pacto para lanzar nuevas versiones trimestralmente, agregando un nuevo código para mantener los microservicios funcionando sin problemas y de manera segura. El proceso de desarrollo y la estructura del código serán muy familiares para cualquiera que haya vivido en el mundo de Java EE, pero las interminables dificultades de configuración se han eliminado. Es una prueba de que puedes enseñar a un perro viejo nuevos trucos.

Dropwizard

Cuando Dropwizard apareció en el 2011, les abrió los ojos a los desarrolladores de Java Enterprise sobre cuán poco código era realmente necesario. La infraestructura/framework de Dropwizard entregó un modelo muy simple para el desarrollo con muchas de las decisiones importantes que se tomaron en su nombre, y ha seguido este camino. Usted agrega algo de lógica de negocios, y luego casi todo lo demás es configurado por usted de acuerdo con la tradición. El resultado son archivos JAR delgados que los usuarios elogian por iniciarse rápidamente.

La mayor limitación puede ser la falta de inyección de dependencia. Si desea utilizarla para mantener su código limpio y sin acoplar, deberá agregar las bibliotecas usted mismo. No hay forma en que Dropwizard haga esto, a diferencia del mundo de Spring. Sin embargo, la mayor parte de los otros artículos de lujo ahora son compatibles, incluyendo el registro, los controles de estado y el código que proporciona resistencia. No necesitará hacer muchos sacrificios.

WildFly Thorntail

La gente de Red Hat construyó su propia versión de MicroProfile completada con una herramienta de configuración ingeniosa. El framework originalmente se llamaba WildFly Swarm, pero luego se le cambió el nombre a Thorntail. Su sitio web lo ayuda a crear su propio archivo de compilación de Maven simplemente especificando las características que necesita. Maven luego se encarga de ensamblar todo.

Thorntail también detectará los componentes principales que necesitará al escanear su código, pero puede anular esto con un archivo BOM (lista de materiales). Cuando todo se esté ejecutando, Thorntail eliminará las partes de la Edición Enterprise de Java que no se usarán y creará un archivo JAR pequeño y listo para implementarse con un solo comando -una característica ingeniosa que permite que el proyecto Thorntail lo llame Uber-JAR. Es otro enfoque a seguir en la tradición de la Edición Enterprise de Java sin guardar todo el equipaje pesado.

Helidon

Helidon solo ha estado disponible durante unos meses desde los comunicados de prensa y el primer compromiso con el repositorio de GitHub, pero el framework ya está atrayendo el tipo de atención que el respaldo de Oracle garantiza. Si bien el universo de Java es enorme, gran parte todavía gira en torno a Oracle.

Los arquitectos de Helidon siguieron muchos de los mismos temas que se repiten en los otros proyectos aquí. Extraiga el cruft de la Edición Enterprise de Java y conserve el núcleo ligero y basado en servlets que se ha ganado la confianza del mundo. En el caso de Helidon, los desarrolladores comenzaron con Netty y agregaron solo el código suficiente para hacer un poco de enrutamiento y manejo de errores. Para hacer las cosas interesantes, adoptaron dos modelos básicos para el código, las llamadas versiones SE y MP.

Helidon SE le resultará muy familiar a los programadores de Node.js, con las largas cadenas de llamadas de función unidas por puntos. Helidon MP le resultará más familiar a los programadores de Java que usan JAX-RS. También hay algunas herramientas útiles y bien apreciadas para verificar el estado de los servidores o rastrear el flujo de datos a través de un bosque de microservicios. Estas son buenas razones para explorar el potencial, incluso sin el soporte de Oracle.

Cricket

Otro framework para el desarrollo rápido de API es Cricket. Cricket es pequeño a pesar de incluir varios extras como un almacén de datos de valor fundamental para evitar que conecte una base de datos, y un programador para controlar el procesamiento repetitivo en segundo plano. No hay otras dependencias que agreguen complicaciones o bloqueos, por lo que es bastante fácil agregar su código a Cricket e iniciar un microservicio independiente.

Jersey

Uno de los enfoques estándar para desarrollar un servicio web es la API de Java para servicios web RESTful (también conocido como JAX-RS), una especificación general que se ha implementado en el framework de Jersey. El enfoque depende en gran medida del uso de las anotaciones para especificar la asignación de ruta y los detalles de retorno. Todo lo demás desde el análisis de los parámetros y el embalaje del JSON está a cargo de Jersey.

La principal ventaja de Jersey es que implementa el estándar JAX-RS, una característica que es lo suficientemente deseable como para que algunos desarrolladores combinen Jersey con Spring Boot para disfrutar de ambos juntos.

Play

Una de las mejores maneras de experimentar el poder de cross-language power de la JVM es con el framework Play, una pila de código Scala que se enlaza con Java o con cualquiera de los otros lenguajes de JVM. La base es muy moderna, con un modelo asíncrono y sin estado que no sobrecarga al servidor con subprocesos interminables intentando realizar un seguimiento de los usuarios y sus datos de sesión. También hay una serie de características adicionales que se pueden usar para desarrollar un sitio web como OpenID, validación y soporte de carga de archivos.

La base de código de Play ha evolucionado durante más de una década, por lo que también encontrará ecos de tiempos olvidados como el soporte para XML. Play es maduro y ágil a la vez, una combinación que puede ser rara en el campo.

Swagger

Crear una API puede parecer tan simple como escribir un código que escucha en un puerto y ofrece respuestas, pero los desarrolladores de Swagger empiezan a diferir. Han creado un lenguaje completo de especificación de API llamado OpenAPI que puede usar para escribir lo que su API hará. Esto puede parecer un paso adicional, pero el equipo de Swagger también ha proporcionado un código que convierte esta especificación en pruebas automatizadas, documentación y más.

La descripción simple y casi espartana de una API en el archivo de configuración de Swagger es integrada en el código Java para implementar la interfaz, documentar cómo se comporta y proporcionar un conjunto de herramientas para probar el código creado debajo de ella. Incluso hay un mecanismo para la gobernanza de la API, de modo que puede trabajar con las masas poco informadas que pronto golpearán la puerta de su API y esperarán respuestas.

Swagger es un ecosistema para las APIs que no se limita a Java. Si su equipo se muda a Node.js o a cualquiera de las varias docenas de otros idiomas, hay un módulo Swagger Codegen esperando para convertir su especificación de OpenAPI en una implementación en ese idioma.

Restlet

Una de las diferencias más grandes entre los distintos frameworks es el número de conexiones a otros servicios y bibliotecas. El proyecto Restlet ofrece una de las colecciones más grandes de funciones y conexiones. Ya está integrado con bibliotecas como JavaMail, en caso de que su microservicio necesite hablar POP, IMAP o SMTP a algún servidor de correo, y Lucene/Solr, en caso de que desee crear índices de grandes porciones de texto en los que se puedan realizar búsquedas y metadatos alrededor de estos.

Las posibilidades en Restlet simplemente continúan porque esta pila generalmente admite varias opciones diferentes para cada parte. No necesita utilizar JSON, por ejemplo, porque el código manejará XML, CSV, YAML y algunos otros formatos de archivo. Asimismo, obtendrá varias opciones diferentes para las plantillas para estructurar su respuesta. Una de las mejores características adicionales es el Restlet Client, que le permite probar sus APIs desde en navegador de Chrome.

Squash

La depuración de los microservicios suele ser un verdadero desafío, ya que las partes están ligeramente acopladas y es difícil rastrear el flujo de datos a través de todas las capas del sistema. Squash le permite configurar puntos de interrupción en su código, que se ejecuta en un clúster Kubernetes, y luego recibir todos los datos en su IDE como si fuera uno que se ejecuta localmente. Squash también se integra con los tiempos de ejecución de Node.js y Python en caso de que su colección de microservicios no sea solo para Java.

Telepresence

Otra opción para depurar es usar Telepresence para crear un proxy local para un microservicio en un clúster de Kubernetes distante. Sus llamadas para este servicio se desviarán a la versión local donde puede configurar puntos de interrupción o hacer cualquier otra cosa que pueda imaginar en su máquina local.

Zipkin

Zipkin es un mecanismo para registrar eventos en varios microservicios y luego correlacionarlos para que los problemas puedan ser aislados y estudiados a medida que se extiendes en/a través de la colección de máquinas. Hay una implementación de Zipkin para Java, así como al menos otros seis lenguajes para que los sistemas multilingües puedan ser abordados. Algunas de los frameworks más sofisticados como Spring ya tienen Zipkin integrado de alguna forma.