Estos frameworks más ligeros combinan la flexibilidad de la nube nativa con la ingeniería de Java, de eficacia probada, para que puedas escribir código responsive que sea fácil de implementar en cualquier lugar.

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 embebidos hasta las enormes granjas de servidores. La combinación de Java de una máquina virtual sólida como una roca y una gran colección de bibliotecas constituye un ecosistema fértil para escribir código que se puede ejecutar 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 malabares 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 frameworks 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.

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 frameworks 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 frameworks 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 frameworks 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 envían 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 framework 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 frameworks 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 frameworks 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 framework 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 framework 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 frameworks dinámicos. Esto es, de nuevo, gracias al trabajo realizado en tiempo de compilación.

Micronaut no es sólo 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 framework con ejemplos que soportan esos casos de uso incluso con cero configuración. El resultado se enrolla fácilmente en un contenedor y se despliega en un clúster de 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 reconozca los patrones de diseño en ciertos casos.

Puedes utilizar el marco básico de Quarkus para una variedad de servicios. A partir de Quarkus 2.8, los desarrolladores 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 I/O 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 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 decidieron 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 iniciadas por Spring. Las funciones en la nube de este framework admiten un estilo reactivo o imperativo, así como una mezcla híbrida de ambos.

El apoyo a una amplia variedad de opciones es un gran objetivo para el proyecto. Hay adaptadores para 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 frameworks 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 puedas concentrarte 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 sólo las personas adecuadas puedan ejecutar las funciones. 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 tu 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 callbacks 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 conjunto de herramientas, no un framework. El código es modular, por lo que puedes elegir qué características utilizar y montar una arquitectura que se adapte a tu 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 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 de 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 frameworks nativos de la nube más modernos.

Dropwizard

Algunos desarrolladores que tienen un afecto natural por los módulos antiguos y bien probados disfrutarán de Dropwizard. El equipo de desarrollo de Dropwizard siempre ha hecho hincapié en 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 framework 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 framework 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 framework se encarga de ello directamente.

Ambos frameworks 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 frameworks que he descrito. Estos son sólo puntos de partida, pero a veces es suficiente.

-Peter Wayner, cio.com