[01/09/2022] El lenguaje de programación Java ha entrado en su tercera década, y el lenguaje y su código de bytes han encontrado un hogar en todo, desde los chips integrados hasta las grandes granjas de servidores. La combinación de Java de una máquina virtual sólida como una roca y una gran colección de librerías crea un ecosistema fértil para escribir código que se ejecuta en todas partes.
Sin embargo, un área en la que Java ha tenido problemas es el mundo de los servidores, que a menudo deben hacer malabarismos con las conexiones de miles o incluso millones de usuarios. En los primeros años, las herramientas de Java se encontraban entre las mejores para crear aplicaciones del lado del servidor que aplicaran la lógica empresarial a todos los usuarios. Los marcos de trabajo de Java como J2EE, Hibernate, Spring y el modelo básico de servlets de Java hacían relativamente fácil crear aplicaciones web sólidas.
[Reciba lo último de CIO Perú suscribiéndose a nuestro newsletter semanal]
La tecnología prosperó hasta que aparecieron JavaScript y Node.js. Node.js acaparó mucha atención y los desarrolladores comenzaron a migrar al entorno de ejecución de JavaScript. En general, había dos razones: En primer lugar, los desarrolladores agradecieron la oportunidad de ejecutar el mismo código en el servidor y en un cliente del navegador. En segundo lugar, los servidores Node.js solían ofrecer un rendimiento mucho más rápido, gracias a su modelo reactivo.
El ecosistema Java se adaptó para competir. Para empezar, algunos desarrolladores adoptaron herramientas como Google Web Toolkit, que traduce Java a JavaScript. A continuación, trabajaron para acelerar Java en el servidor. Los primeros marcos de trabajo de Java para el servidor tenían una limitación: cada solicitud entrante tenía su propio hilo. Esta era una forma limpia de organizar los datos entrantes y salientes, pero también era agotadora. La creación de un hilo requiere miles de bytes de sobrecarga, lo que podía limitar el número de usuarios que podía manejar cada servidor. Node.js utilizaba un modelo diferente que le permitía hacer malabares con muchos más usuarios sin esta sobrecarga.
Más recientemente, los desarrolladores de Java han llevado las innovaciones de Node.js a la pila de Java, en particular los marcos Java nativos de la nube. Estos marcos imitan el enfoque de Node.js y admiten funciones ligeras que se ejecutan en máquinas en la nube y pueden iniciarse y detenerse rápidamente. Prescinden de las bibliotecas adicionales para apoyar el despliegue rápido en las instancias de servidor más delgadas disponibles. Los marcos Java nativos en la nube están diseñados para soportar constelaciones de microservicios que pueden instalarse y reiniciarse de forma independiente. Por lo general, se entregan en contenedores como Docker o Podman para que las construcciones e instalaciones sean lo más rápidas posible.
Los desarrolladores modernos de Java que buscan una experiencia nativa en la nube tienen una serie de opciones. Un marco Java nativo en la nube ideal aprovecha la profunda experiencia invertida en la plataforma Java y sus bibliotecas de terceros, adaptándolas al mismo tiempo para que se ejecuten más rápidamente y con menos peso en la nube. A continuación, se presentan ocho marcos de trabajo de Java creados desde cero para el desarrollo y la implementación nativos en la nube.
Micronaut
Los creadores de Micronaut querían tomar las mejores partes de los frameworks clásicos de Java como Spring y Grails, como la configuración flexible y la inyección de dependencias, pero eliminando la pesada huella de memoria y la lentitud de inicio que los hacía menos deseables para el desarrollo de microservicios. Han diseñado cuidadosamente anotaciones que proporcionan suficiente información para las inyecciones de dependencias sin la reflexión que llena la memoria utilizada en los marcos más antiguos. Conseguir que una mayor parte de la configuración de Micronaut se realice en tiempo de compilación significa que el código se ejecuta más rápido y más ligero.
El marco está construido para soportar una variedad de lenguajes basados en JVM (actualmente, Java, Kotlin y Groovy) y ejecutarlos en varias nubes. Los archivos de configuración predefinidos simplifican el despliegue del servidor o de las funciones sin servidor en todas las nubes principales, y hay páginas de documentación bien escritas para todas las principales conexiones de bases de datos.
Los desarrolladores de Micronaut también quieren que el marco apoye un buen trabajo en equipo de desarrollo. Una implementación de HttpClient se incluye en el proyecto para simplificar la escritura de pruebas unitarias sin salir de Micronaut o añadir más trabajo. Estas pruebas son a menudo más simples y más completas que las pruebas requeridas para los marcos dinámicos. Esto es, de nuevo, gracias al trabajo realizado en tiempo de compilación.
Micronaut no solo sirve para desarrollar aplicaciones con funciones en la nube. El framework es lo suficientemente general como para soportar funciones tradicionales y algunas aplicaciones de escritorio. Su estrecha integración con GraalVM permite utilizar Micronaut para generar aplicaciones nativas.
Quarkus
Los desarrolladores que quieran utilizar una mezcla bien entendida de código imperativo y reactivo pueden recurrir a Quarkus. El equipo de Quarkus comenzó por anticipar los casos de uso más comunes para el desarrollo nativo en la nube, y luego construyó el marco con ejemplos que soportan esos casos de uso con tan solo cero configuración. El resultado se enrolla fácilmente en un contenedor y se despliega en un clúster Kubernetes.
El equipo de desarrollo prestó especial atención a garantizar tiempos de arranque rápidos para que los clústeres de Kubernetes puedan escalar rápidamente. Se trata de una característica ideal para las funciones que se ejecutan de forma esporádica, ya que pueden dejarse en frío hasta que sean invocadas.
Uno de los objetivos del proyecto es adoptar y ampliar muchos estándares y bibliotecas existentes que son comunes en la comunidad Java. Por ejemplo, las anotaciones JAX-RS definen los puntos finales REST. La configuración comienza con Eclipse MicroProfile. El equipo de desarrollo de Quarkus también integró más de 50 bibliotecas estándar, por lo que es muy probable que reconozcas los patrones de diseño en ciertos casos.
Puede utilizar el marco básico de Quarkus para una variedad de servicios. A partir de Quarkus 2.8, los desarrolladores de Quarkus están fomentando suavemente el modelo RESTeasy Reactive. Es la opción estándar si está comenzando un nuevo proyecto, pero no tiene que utilizarlo. RESTeasy Reactive ofrece una estructura y unos patrones más sencillos y sin bloqueos. En lugar de asignar un hilo a cada solicitud, un conjunto de hilos no bloqueantes maneja toda la E/S e invoca su código cuando es necesario.
Quarkus también abarca una amplia gama de opciones de despliegue. Aunque se dice que es "contenedor primero", puede ejecutarse en bare metal. También hay una opción de configuración incorporada llamada Funqy que simplifica la creación de las funciones aceptadas por AWS Lambda, Azure Functions, Knative y algunas otras opciones.
Spring Cloud Functions
Los desarrolladores de Java están bien familiarizados con el framework de Spring porque ha sido la base de muchos proyectos durante unas dos décadas. Los desarrolladores de Spring deciden crear una nueva versión que se adapte mejor a la implementación en la nube, así como a algunas otras funciones. Las funciones de Spring Cloud Functions están pensadas para ser fácilmente redistribuidas a una variedad de tareas como servicios web, procesamiento de flujos o trabajo en segundo plano.
El framework de Spring Cloud Functions continúa con muchas de las mismas tradiciones filosóficas de las que fue pionero Spring. Las funciones en la nube de este marco admiten un estilo reactivo o imperativo, así como una mezcla híbrida de ambos.
Admitir una amplia variedad de opciones es un gran objetivo del proyecto. Hay adaptadores que meten con calzador las funciones en AWS Lambda, Microsoft Azure, Apache OpenWhisk, Google Cloud Platform, y algunos otros entornos comunes de funciones en la nube. También hay adaptadores para los principales marcos de streaming como Apache Kafka, Solace y RabbitMQ, así como la opción independiente Spring Cloud Stream. El empaquetado y el despliegue están fuertemente automatizados para que pueda concentrarse en el desarrollo de las propias funciones.
El equipo de desarrollo de Spring Cloud Functions también ha trabajado duro para manejar muchos de los escollos y desafíos comunes del despliegue en la nube. Spring Cloud Skipper puede utilizarse para hacer malabares con las implementaciones en varias nubes. Spring Cloud Sleuth ayuda a la depuración rastreando los flujos de datos. Spring Cloud Security gestiona muchas de las tareas para asegurar una aplicación de manera que solo las personas adecuadas puedan ejecutar las funciones. Solo hay varias docenas de subproyectos diferentes.
El proyecto es una muy buena base para distribuir aplicaciones empresariales a través de una variedad de plataformas. Una vez que la lógica de su aplicación está encapsulada en un POJO de Cloud Function, puede encontrar un hogar trabajando en docenas de funciones diferentes.
Vert.x
Los creadores de Vert.x querían crear un framework muy rápido simplificando el bucle de eventos y optimizando la conexión con la base de datos. Vert.x tiene un único bucle de eventos como Node.js, lo que le permite hacer malabares con múltiples conexiones a medida que llegan los eventos. También aprovecha el modelo de hilos de Java para procesar los eventos con múltiples hilos en un pool, que pueden ejecutarse en varios núcleos si están disponibles.
La estructura también está pensada para simplificar la creación del pipeline para procesar un flujo de eventos. Toma prestadas construcciones como las promesas y los futuros para evitar el código desordenado con las devoluciones de llamada en capas. Las opciones asíncronas ayudan a producir un código limpio y legible lleno de simples cadenas de invocaciones de métodos a medida que los eventos se mueven a lo largo del bus de eventos.
El equipo de desarrollo de Vert.x no es dogmático sobre su visión. Suelen decir que Vert.x es un kit de herramientas, no un framework. El código es modular, por lo que se puede elegir qué características utilizar y montar una arquitectura que se adapte a su aplicación. Los programadores que quieran una estructura más imperativa en lugar de reactiva pueden encontrar soporte para las coroutines de Kotlin.
Este proyecto forma parte del ecosistema de Eclipse. Una variedad de versiones y opciones ofrecen mucha libertad. El generador de aplicaciones Vert.x, por ejemplo, producirá código Java o Kotlin con docenas de posibles dependencias como motores de plantillas o soporte de API.
Eclipse MicroProfile
El equipo de Eclipse creó el proyecto MicroProfile como una forma de adaptar Jakarta EE para ejecutar constelaciones más pequeñas de microservicios. Elimina parte de la sobrecarga de la plataforma más grande, a la vez que agrupa bibliotecas que son bastante estándar para muchas arquitecturas de microservicios.
El enfoque es más atractivo para los desarrolladores que podrían estar migrando código desde proyectos Java EE o Jakarta EE más grandes y antiguos. Gran parte de la configuración y la arquitectura siguen siendo las mismas. En muchos casos, los ajustes son menores. Pero el diseño fomenta el tipo de decisiones que simplifican la creación de un código más ligero y rápido. Algunos desarrolladores utilizan MicroProfile como un peldaño en el camino hacia marcos nativos de la nube más modernos.
Dropwizard
Algunos desarrolladores tienen un afecto natural por los módulos más antiguos y bien probados y disfrutarán de Dropwizard. El equipo de desarrollo de Dropwizard siempre ha enfatizado palabras como estable y maduro. Recogieron módulos para conexiones de bases de datos como Hibernate, y mezclaron en marcos para formularios y otros componentes estándar de aplicaciones web. Dropwizard también agiliza la inyección de dependencias y los procesos de mantenimiento en tiempo de ejecución, como la configuración y el registro.
Dropwizard es el favorito de los equipos que trabajan para revisar y ampliar una aplicación existente. Su estructura es compatible con los enfoques más antiguos y maduros, ya que se basa en ellos.
Frameworks de inicio para plataformas en la nube
A veces, no hay necesidad de algo complejo o elaborado. Todas las nubes mantienen ejemplos básicos que son buenos lugares para empezar a escribir funciones simples. Están diseñados principalmente para soportar decisiones muy simples y ayudar a los desarrolladores a empezar rápidamente.
Por ejemplo, el equipo de desarrollo de Google Cloud Platform ha abierto su marco básico para las funciones Java que se ejecutan en su función como servicio (FaaS). El código construido con él está pensado para integrarse rápidamente con los activadores estándar de GCP, aunque también puede ejecutarse con éxito en cualquier máquina local.
Microsoft también ha abierto su marco de trabajo para Java. El modelo incluye varias rutinas para simplificar las transferencias de datos, como una biblioteca para traducir datos JSON a y desde POJOs de Java. Si el desencadenante de la función suministra metadatos con la invocación, el marco se encarga de ello directamente.
Ambos marcos permiten realizar muchas tareas sencillas escribiendo una sola clase con una sola función. Los proyectos más complicados pueden querer combinar esta herramienta básica con algunos de los otros marcos que hemos descrito. Estos son solo puntos de partida, pero a veces eso es suficiente.
Basado en el artículo de Peter Wayner (InfoWorld) y editado por CIO Perú
Puede ver también: