Lección 162: Diferencias entre arquitecturas monolíticas y de microservicios

Si has usado servicios de streaming en los 2010s, lo más probable es que fueran una única aplicación grande, donde el sistema de recomendaciones estaba pegado al reproductor, y éste a su vez no podía funcionar sin el sistema de usuarios. Si la base de datos se apiada y se toma un par de segundos para pensar, todo se para, incluida la consola de administración. Eso es el monolito: un enorme nudo de código entrelazado que sólo puedes actualizar, escalar o arreglar entero.

Ahora mira un servicio de streaming moderno: el reproductor va por su cuenta, las recomendaciones están en otro lado, los perfiles de usuario quizás en otro servidor. ¿Se cayó el sistema de comentarios? No pasa nada, las películas siguen viéndose. ¿Pico de espectadores por Año Nuevo? Simplemente aumentamos la potencia de los servidores de vídeo sin tocar el resto. Eso es la arquitectura de microservicios: un conjunto de componentes independientes que saben comunicarse, pero también pueden funcionar por separado.

Ahora veamos con más detalle las características de ambos enfoques.

Monolitos

Características principales de la arquitectura monolítica:

1. Código único y centralizado: toda la aplicación se empaqueta en un solo "bloque", ya sea un JAR o un WAR.
2. Estructura acoplada: todas las partes de la aplicación (controladores, servicios, repositorios) están tightly coupled — es decir, fuertemente ligadas entre sí.
3. Despliegue único: incluso si cambias una línea de código, necesitas reconstruir y reiniciar toda la aplicación.

Ventajas del monolito

• Despliegue sencillo: un archivo = menos líos con la configuración del entorno.
• Depuración más cómoda: es más fácil arrancar todo el proyecto en local y depurar el sistema.
• Base de código unificada: todos los módulos están en un único lugar y los cambios se aplican de forma centralizada.
• Modo principiante: para la gente que empieza en el equipo es más fácil entender una única aplicación que un zoológico de microservicios.

Desventajas del monolito

• Problemas para escalar: un monolito se escala normalmente sólo verticalmente (añadiendo más CPU, RAM y otros recursos al servidor). ¿Y si necesitas escalar sólo una parte pequeña de la app? Por ejemplo, tu API para procesar imágenes es mucho más popular que el resto. Lamentablemente, igual toca escalar todo el monolito entero.
  • Complejidad en las actualizaciones: es difícil desplegar cambios en un monolito. Incluso una pequeña mejora requiere reconstruir toda la aplicación. Si algo sale mal durante el despliegue, todo tu rascacielos (sí, recuerda nuestro rascacielos) puede venirse abajo.
  • Vulnerabilidad a fallos: un fallo puede hacer que toda la aplicación deje de funcionar. Por ejemplo, si tu servicio de pagos falla, todo el sitio puede quedar inaccesible.

Microservicios

Ya hemos puesto el ejemplo del servicio de streaming moderno —un cine online— donde los módulos son independientes entre sí.

Los microservicios son módulos independientes que:

1. Hacen una tarea concreta.
2. Se desarrollan y despliegan de forma autónoma.
3. Se comunican entre sí a través de interfaces de red estándar (por ejemplo, REST o mensajes vía Kafka).

Ventajas de los microservicios

• Despliegue independiente: puedes actualizar, arreglar o incluso cambiar el stack tecnológico de un microservicio sin tocar los demás. Esto reduce el riesgo de introducir breaking changes.
• Escalabilidad: es fácil escalar solo los microservicios que tienen carga. ¿Tu API para subir gatitos está en llamas de popularidad? Lanza más instancias del servicio de procesamiento de imágenes.
• Resiliencia ante fallos: la caída de un microservicio no arrastra todo el sistema. Por ejemplo, si se rompe tu servicio de correo, los usuarios aún pueden pagar compras, comprobar el estado de pedidos y añadir productos al carrito.
• Variedad tecnológica: cada microservicio puede usar distintos lenguajes de programación y bases de datos adecuados para su tarea.
• Independencia de los equipos: los microservicios permiten que distintos equipos trabajen de forma autónoma, algo muy útil en empresas grandes. Cada equipo puede centrarse en su área y hacer deploy de los cambios de forma independiente.

Desventajas de los microservicios

• Desarrollo más complejo: hacer una arquitectura distribuida es más difícil. Hay que prever la gestión de fallos, diseñar la estrategia de interacción entre servicios y a menudo equilibrar entre comunicación sincrónica y asincrónica.
• Despliegue complejo: a diferencia del monolito, desplegar microservicios exige coordinar muchas piezas. Tendrás que montar CI/CD, tener un sistema de gestión de configuraciones (por ejemplo, Spring Cloud Config) y monitoring.
• Network Overhead: los microservicios intercambian datos por la red. Esto añade latencia y exige una estrategia pensada para serialización y deserialización de datos.

Comparación entre monolito y microservicios

¿Cuándo elegir monolito y cuándo microservicios?

Cuándo usar un monolito:

1. Estás empezando el proyecto y el equipo es pequeño.
2. No necesitas alta escalabilidad por ahora.
3. Quieres desarrollar rápido y sacar el producto al mercado.

Cuándo elegir microservicios:

1. La aplicación se ha hecho grande y pesada para añadir nuevas features.
2. Necesitas escalar módulos por separado.
3. Dispones de equipos grandes trabajando en distintas partes del sistema.
4. Necesitas alta tolerancia a fallos.

Trampas y errores típicos

Pasar de monolito a microservicios no es una varita mágica que arregla todo. Al contrario, puedes meterte en más problemas si no planificas la arquitectura correctamente.

1. Sobredivisión: si tus microservicios son demasiado pequeños, te vas a dar dolor de cabeza con la comunicación en red y la coordinación.
2. Antipatrón del monolito distribuido: cuando los microservicios siguen dependiendo demasiado unos de otros, un fallo en un bloque rompe toda la aplicación.
3. Falta de herramientas: sin herramientas de monitoring (por ejemplo, Spring Boot Actuator o Prometheus) corres el riesgo de perder visibilidad del sistema.
4. Dificultades con la consistencia de datos: mantener la coherencia entre microservicios es un reto, especialmente con comunicación asincrónica.

Ahora estás un paso más cerca de decidir qué construir: ¿un "rascacielos" o un "barrio de tienditas"? Los microservicios son una gran opción para sistemas complejos y escalables, pero solo si estás preparado para los retos que traen.