Martin Fowler ha publicado recientemente otro artículo sobre los microservicios, en concreto sobre el bombo que les rodea. Afirma que, aunque los microservicios son un tema candente en estos momentos, añaden una complejidad innecesaria a sistemas que estarían bien con una única aplicación monolítica construida con una buena modularidad.
Aunque estoy de acuerdo con su punto de vista de que los microservicios añaden complejidad, especialmente cuando se trata de operaciones, creo que todavía pueden tener sentido para pequeñas bases de código.Para exponer la declaración de Fowler, puedes encontrarte con problemas al construir monolitos cuando se trata de escalar la tecnología y tu equipo en una base de código. Si no se maneja con mucho cuidado, la base de código puede enredarse rápidamente, añadiendo sobrecarga a las operaciones al igual que los microservicios. Varias tecnologías deben ejecutarse juntas en lugar de ejecutarse por separado, un problema que un enfoque basado en servicios solucionaría.
Además, las tareas monolíticas, como asegurarse de que se mantienen los límites, se realizan revisiones de código en la base de código más grande y compleja, y el código se refactoriza regularmente, tampoco son gratuitas. La construcción de una infraestructura más compleja que pueda hacer funcionar esta base de código más grande es otra cuestión.
Al hablar con nuestro equipo y con otros equipos, he visto dos estilos distintos de arquitecturas de microservicios. Una es una infraestructura monolítica con servicios salpicados, y la otra va a por todas con los servicios.
Arquitectura de microservicios con un núcleo monolítico
Después de construir una aplicación monolítica durante un tiempo, puede ser útil trasladar algunas partes del sistema a pequeños servicios para reforzar los límites, acelerar las suites de prueba individuales y facilitar su escalado independiente. En otras palabras, aunque el monolito sigue conservando la funcionalidad principal, muchas piezas pueden externalizarse en pequeños servicios secundarios que den soporte a la base de código principal.
La lógica de negocio principal permanecerá en el núcleo del monolito, pero cosas como los trabajos en segundo plano, las notificaciones u otros pequeños subsistemas que pueden ser activados por mensajes, por ejemplo, pueden ser trasladados a sus propias aplicaciones.
Este método de núcleo monolítico salpicado de servicios funciona especialmente bien cuando todos los datos necesarios para un trabajo pueden compartirse a través del mensaje enviado para iniciar el trabajo. El servicio no necesita almacenamiento de datos, y básicamente hemos creado un servicio de delegación para la aplicación principal que debería ser fácil de escalar.
Al centrarse en un maestro monolítico que impulsa otros servicios pequeños, se pueden conservar muchas de las ventajas de una infraestructura monolítica con sólo un poco de mantenimiento adicional en los servicios más pequeños. Al poner esos servicios en la nube, se puede limitar aún más la necesidad de gestionar la infraestructura en torno a ellos.
Con el tiempo, este monolito con pequeños servicios adjuntos puede convertirse en una arquitectura totalmente orientada a los servicios.
Arquitectura totalmente orientada a servicios
La principal diferencia entre un núcleo monolítico y un enfoque totalmente orientado a los servicios es que no hay un código base claro que dirija el resto de los servicios. Cada servicio controla su función empresarial y sus datos, y todos desempeñan un papel más o menos igual en la infraestructura general.
En el estilo de núcleo monolítico, la aplicación que recibe la solicitud será probablemente la que contenga los modelos, hable con la base de datos y ejecute la mayoría de las funciones de negocio. En un estilo totalmente orientado a servicios, la aplicación que recibe las solicitudes simplemente se pone en contacto con otros servicios y devuelve una respuesta unificada sin contener toda la lógica de negocio.
El estilo totalmente orientado a servicios de la construcción de una arquitectura parece ser más frecuente en los equipos que comienzan con el objetivo inicial de construir una arquitectura basada en microservicios. Mientras que con el tiempo un núcleo monolítico puede crecer hasta ser totalmente orientado a servicios, el núcleo se mantiene durante mucho tiempo.
Definir claramente la infraestructura que se desea
Cuanto más grande sea una aplicación, más discusiones surgirán en torno al traslado de algunas partes a los servicios. Como dijo Fowler, los microservicios son un tema muy candente ahora mismo. Hay que asegurarse de que esas discusiones se producen con un objetivo claro y compartido en mente, no sólo porque algo esté de moda.
Con demasiada frecuencia, he visto equipos que discuten una futura arquitectura orientada a servicios con algunos que se aferran al modelo central monolítico, mientras que otros planean orientarse totalmente a los servicios. Esto choca de forma natural, ya que introduce expectativas muy diferentes en el debate.
Conclusiones
Las aplicaciones monolíticas pueden ser más sencillas de manejar con el tiempo. Al pasar de un monolito puro a una arquitectura de núcleo monolítico puedes conservar esas ventajas mientras divides tu aplicación. Con el tiempo puede ampliarla a una arquitectura totalmente orientada a servicios si es necesario. Esto también limita el impacto temprano que una infraestructura totalmente orientada a servicios puede tener en la productividad de sus equipos.