Del monolito a los microservicios

En un monolito, la interfaz, la lógica de negocio y el acceso a datos viven en el mismo código y se ejecutan en el mismo proceso. Las piezas se llaman entre sí con simples llamadas a funciones y suelen compartir una base de datos, así que una operación que toca pedidos, stock y facturas cabe en una sola transacción.

Para escalar, ejecutas varias copias idénticas detrás de un balanceador de carga. Es sencillo de desarrollar, probar y depurar: un repositorio, un despliegue y una sola pila de llamadas cuando algo falla.

Un monolito modular se despliega como un monolito, pero su código se organiza en módulos de negocio (catálogo, pedidos, pagos) que solo se comunican a través de una interfaz pública. Ningún módulo lee las tablas ni importa los archivos internos de otro.

Esas fronteras se hacen cumplir con herramientas: reglas de lint que prohíben ciertos imports, paquetes separados en un monorepo o un esquema de base de datos por módulo. Si un día un módulo necesita escalar aparte, extraerlo como servicio es mucho más fácil, porque ya tiene una frontera limpia.

En una arquitectura de microservicios, cada capacidad de negocio es un servicio independiente: tiene su código, su base de datos y su propio ciclo de despliegue, y lo mantiene un equipo. Los servicios se comunican por la red, con HTTP, gRPC o mensajes.

La gran ventaja es la autonomía: el equipo de pagos despliega varias veces al día sin coordinarse con nadie, y el catálogo puede escalar a cincuenta copias mientras el resto sigue con dos. El precio es que ahora tienes un sistema distribuido: la red falla, las llamadas son más lentas y ya no existe una transacción que lo abarque todo.

SOA (Service-Oriented Architecture) se popularizó en los años 2000 para que las grandes organizaciones reutilizaran funciones entre aplicaciones: un servicio «Clientes» o «Facturación» que consumen a la vez el CRM, la web y la contabilidad. Los contratos suelen ser formales, a menudo SOAP descrito con WSDL.

Una pieza típica es el ESB (Enterprise Service Bus), un intermediario que enruta los mensajes, transforma formatos y orquesta procesos. Los microservicios heredan la idea de servicio, pero rechazan el bus central: prefieren, como suele decirse, «extremos inteligentes y tuberías simples».

Con serverless escribes funciones pequeñas que se ejecutan cuando ocurre algo: una petición HTTP, un archivo subido, un mensaje en una cola. El proveedor de cloud arranca tantas instancias como haga falta, las apaga cuando no hay trabajo y te cobra por uso. Los servidores siguen existiendo, pero no son asunto tuyo.

A este modelo también se le llama FaaS (Functions as a Service). A menudo se combina con servicios gestionados, como bases de datos o colas, para no administrar nada de infraestructura.

En una arquitectura orientada a eventos (EDA, Event-Driven Architecture), un servicio que hace algo importante publica un evento: «PedidoCreado», «PagoRechazado». Otros servicios se suscriben a los eventos que les interesan y reaccionan por su cuenta. Quien publica no sabe quién escucha.

Un intermediario, el broker de mensajes (Kafka o RabbitMQ, por ejemplo), recibe los eventos y los entrega. Así puedes añadir un consumidor nuevo, como uno que calcula estadísticas, sin tocar el servicio de pedidos. El módulo de caché, colas y mensajería explica estos brokers a fondo.

La arquitectura microkernel separa un núcleo pequeño, con lo imprescindible, de un conjunto de plugins que añaden funciones. El núcleo define puntos de extensión (una interfaz que cada plugin implementa) y se encarga de registrarlos y llamarlos en el momento adecuado.

La usas a diario: VS Code se amplía con extensiones, los navegadores con complementos, y herramientas como ESLint, Vite o Babel hacen gran parte de su trabajo mediante plugins. El nombre viene de los sistemas operativos, aunque aquí se aplica a una sola aplicación.