La mayoría de las ofertas de trabajo para arquitectos y desarrolladores de microservicios solicitan experiencia con Spring Boot. Pero, ¿es Spring Boot la mejor manera de implementar sus aplicaciones de microservicios? Echemos un vistazo a la respuesta.

¿Qué tipo de problemas abordan los microservicios?

El patrón arquitectónico de microservicio aborda algunos de los problemas operativos, de implementación y desarrollo de software más urgentes de la actualidad mediante:

  1. Acortar los ciclos de desarrollo de software mediante la optimización de prácticas ágiles de desarrollo, entrega y mantenimiento de software .
  2. Habilitación de la iteración rápida de funciones de aplicaciones al simplificar las pruebas de software , la integración continua y la entrega continua .
  3. Explotar las capacidades automatizadas de implementación, escalado y conmutación por error disponibles con contenedores en la nube y orquestación de contenedores .

¿Cómo abordan los microservicios esos problemas?

Realizado correctamente, el patrón de microservicio cumple o supera todos los puntos y los propósitos del famoso memorando que ayudó a preparar el escenario para la agilidad comercial sin precedentes de Amazon. Vale la pena tomarse un momento para leer este memorándum . Es fundamental para las razones por las que los microservicios tienen sentido empresarial.

Para lograr sus objetivos, un microservicio individual:

  • Implementa una tarea (o un conjunto de tareas estrechamente relacionadas) dentro de un solo contexto delimitado por un dominio . Esta es una característica fundamental de un microservicio y promueve el alto nivel de granularidad y separación de preocupaciones que preserva la autonomía del microservicio y la capacidad de implementación independiente .
  • Está débilmente acoplado , se comunica a través del paso de mensajes o eventos, y necesita poco o ningún conocimiento de las definiciones de otros microservicios, lo que impone la separación de preocupaciones .
  • Es autónomo y se puede desarrollar y modificar con menos coordinación entre los equipos de desarrollo involucrados, lo que promueve prácticas sólidas de desarrollo ágil .
  • Se puede implementar de forma independiente y se puede probar, implementar y revertir individualmente sin afectar a otros microservicios, lo que permite la implementación, el escalado y la conmutación por error automatizados basados ​​en la nube .

Tenga en cuenta estas cuatro restricciones básicas. Si un componente de la aplicación no los cumple, aún puede ser un servicio, pero no es un microservicio, y es poco probable que brinde todos los beneficios prometidos por el patrón arquitectónico del microservicio, lo que dificulta, si no imposibilita, el realizar  la promesa completa de microservicios en la nube.

¿Qué es Spring Boot?

Spring Boot es un micro framework de código abierto mantenido por una empresa llamada Pivotal Software. Proporciona a los desarrolladores de Java una plataforma para comenzar con aplicaciones Spring Framework autoconfigurables de grado de producción. Con él, los desarrolladores pueden volverse productivos más rápidamente sin perder tiempo preparando y configurando su aplicación Spring.

Spring Boot hace que la creación de servicios de arquitectura orientada a servicios (o SOA, por sus siglas en inglés) sea más limpia y fácil al ocultar las complejidades de crear y configurar servicios que se ejecutan en contenedores de servlets de Java, y Spring Boot crea archivos JAR ejecutables que se pueden implementar en contenedores en la nube.

DISCUSIÓN: El término contenedor no debe confundirse con el contenedor web (también conocido como contenedor de servlet ) que es el componente de un servidor web que interactúa con los servlets de Java. El contenedor web crea instancias de servlet, carga y descarga servlets, crea y administra objetos de solicitud y respuesta y realiza otras tareas de administración de servlet. A menudo, los defensores de Spring Boot asumen erróneamente que sus servicios se implementan en contenedores porque se ejecutan en contenedores de servlet .

¿Qué tiene de malo Spring Boot?

Absolutamente nada, siempre que comprenda que está creando e implementando servicios SOA tradicionales, no microservicios. Spring Boot es una excelente opción para crear e implementar aplicaciones SOA, pero cada JAR ejecutable generado por Spring Boot contiene un servidor web incorporado y un subconjunto del marco Spring. No es un microservicio.

Entonces, ¿cómo se comparan los servicios SOA de Spring Boot con los atributos requeridos de los verdaderos microservicios? Vamos a ver:

  • Los servicios Spring Boot SOA están optimizados para implementar el modelo de mensajería de solicitud-respuesta HTTP síncrono. Los servicios bien diseñados utilizan el patrón arquitectónico REST para exponer los servicios a través de una API REST definida. Con una sola advertencia, eso es algo bueno. Esa advertencia es su modelo de mensajería de solicitud-respuesta síncrona, que es un limitador fundamental del rendimiento. Los verdaderos microservicios pueden implementar API REST a través de WebSockets y están diseñados para implementar comunicaciones asincrónicas de alto rendimiento entre un cliente y un servidor.

  • Los servicios Spring Boot SOA individuales no se pueden implementar de forma independiente y no se pueden probar, implementar y revertir individualmente sin afectar a otros servicios. Si bien podría empaquetar cada servicio por separado, cada ejecutable desplegable incluiría su propio servidor web integrado y las bibliotecas Spring Framework que usara, una solución que dista mucho de ser óptima. Una aplicación Spring Boot se puede implementar en un contenedor en la nube y en un orquestador como Kubernetes. Pero una aplicación no se puede escalar a un nivel de servicio individual y ciertamente no puede implementar la conmutación por error a un nivel de servicio individual.

  • Debido a que los servicios individuales de Spring Boot no se pueden implementar de forma independiente, no se pueden probar, implementar y revertir de forma independiente. Ese es uno de los impedimentos más serios para obtener los beneficios previstos de los microservicios.
  • Si un servicio Spring Boot es autónomo y puede desarrollarse y modificarse con una coordinación limitada entre los equipos de desarrollo involucrados es una cuestión de principios de diseño y prácticas de desarrollo dentro de su organización, no con Spring Boot en sí. Pero el hecho de que un servicio Spring Boot no se pueda probar, implementar y revertir de forma independiente hace que sea más difícil lograr altos niveles de autonomía del servicio y agilidad de desarrollo.
  • El lado del servidor de Spring Boot es esencialmente una arquitectura en capas. Las partes del ecosistema de Spring que desea utilizar se implementan junto con sus servicios de arranque de Spring. Es importante ser consciente tanto de los beneficios como de los costos de ese enfoque. Esas bibliotecas de Spring representan una funcionalidad reutilizable cuya implementación le costaría tiempo y dinero, suponiendo que tuviera las habilidades y los recursos disponibles. Representan un beneficio tangible. Aunque es poco probable que necesite todas las características, funciones y código dentro de una biblioteca completa, aún deberá implementar todo (incluidas las otras bibliotecas de las que depende) junto con sus servicios de Spring Boot. No hay nada micro en eso y ciertamente impacta el acoplamiento flexible. Elegir sabiamente.

Terminando

Spring Boot es una excelente manera de crear aplicaciones SOA tradicionales. Antes de la llegada de la computación en la nube híbrida, era una de las formas de mayor valor y menor riesgo. Esta publicación no pretende denigrar Spring Boot como un micro-marco bien diseñado. Tampoco pretende criticar su poder para implementar y administrar los servicios SOA tradicionales.

Sin embargo, esta publicación tiene la intención de dejar en claro que Spring Boot, aunque puede ser una excelente manera de crear servicios SOA del siglo XX, no fue diseñado para implementar microservicios. La documentación oficial de Spring Boot establece su propósito como:

  • Cree aplicaciones Spring independientes.
  • Incruste Tomcat, Jetty o Undertow directamente (no es necesario implementar archivos WAR).
  • Proporcione dependencias "iniciales" obstinadas para simplificar la configuración de su compilación.
  • Configure automáticamente Spring y bibliotecas de terceros siempre que sea posible.
  • Proporcione funciones listas para producción, como métricas, controles de estado y configuración externalizada.
  • Absolutamente sin generación de código y sin requisitos para la configuración de XML.

Quienes estén familiarizados con la creación de aplicaciones SOA (Spring o Jakarta), saben lo que puede ahorrar mano de obra. Pero Spring Boot no puede crear los microservicios autónomos, desarrollados de forma independiente, comprobables de forma independiente, implementables de forma independiente, escalables de forma independiente y conmutables de forma independiente (para conmutación por error) necesarios para las aplicaciones de microservicios del siglo XXI verdaderamente nativas de la nube.

Si su organización necesita explotar las ventajas de la computación en la nube híbrida con un desarrollo ágil, Spring Boot no es la respuesta.

Spring Boot fue diseñado e implementado para un entorno informático y una época que ya está pasando. La cuestión fundamental es la granularidad: el nivel de granularidad de los componentes en el que puede administrar el desarrollo, las pruebas, la implementación, el escalado y la conmutación por error de los componentes. En igualdad de condiciones, lo más fino es mejor.

El futuro está en la nube y los verdaderos microservicios son muy superiores a los servicios SOA para obtener los beneficios de la computación en la nube.


Dick Dowdell - Microservicios con Spring Boot

Compartir:

0 comentarios

Deja una respuesta

Marcador de posición del avatar

Tu dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.