¿Qué son los micro­servi­cios?

Micro­servi­cios: definición

El modelo opuesto es el monolito: una aplicación en la que todas las funciones —desde la gestión de usuarios hasta el carrito de la compra o la factura— se encuentran en un bloque de código común y se despliegan juntas. En una arquitectura de microservicios, esta aplicación se divide en servicios individuales, como catálogo, pedidos, pagos y envíos.

Idealmente, cada servicio tiene su propio almacenamiento de datos y puede estar a cargo de un equipo pequeño. Los cambios en un servicio no obligan a publicar de nuevo toda la aplicación. La división se orienta a los ámbitos de negocio, no a las capas técnicas.

Cómo funcionan los micro­servi­cios

Los servicios se comunican a través de interfaces claramente definidas: de forma síncrona, por ejemplo mediante API REST o gRPC, o de forma asíncrona mediante sistemas de mensajería como RabbitMQ o Apache Kafka. A menudo, un API gateway agrupa las solicitudes externas y las reenvía al servicio correspondiente.

Para que la interacción funcione, cada servicio necesita un contrato claro: ¿qué datos acepta, cuáles devuelve y cómo reacciona ante los errores? Si un servicio cambia, sus interfaces deben seguir siendo compatibles con las versiones anteriores o versionarse.

• Servicios independientes con una función de negocio claramente delimitada
• Comunicación mediante API o mensajes
• Operación normalmente en contenedores, p. ej., con Docker y Kubernetes
• Monitorización y logging centralizados para todos los servicios

Ventajas y límites de los micro­servi­cios

Los microservicios permiten escalar de forma específica las partes con más carga, elegir la tecnología adecuada para cada servicio y que varios equipos trabajen en paralelo. Si un servicio falla, no tiene por qué detenerse necesariamente toda la aplicación.

En contrapartida, la complejidad es mucho mayor: datos distribuidos, errores de red, pruebas y monitorización más laboriosas. Para equipos pequeños y fases tempranas de un producto, un monolito modular bien estructurado suele ser la mejor opción: más adelante puede dividirse de forma específica cuando surja una necesidad concreta.

• Despliegue y escalado independientes de funciones concretas
• Trabajo en paralelo de varios equipos
• Mayor esfuerzo de operación, pruebas y supervisión
• Compensa sobre todo en sistemas grandes y en crecimiento

Ejemplo práctico: división progresiva de un monolito

Un comercio online opera una tienda que ha ido creciendo durante años. Sobre todo la búsqueda de productos sufre con la carga durante las promociones y ralentiza toda la tienda. En lugar de reescribirlo todo, primero se separa la búsqueda como servicio propio y se escala por separado. Otras áreas solo se separan allí donde existe un beneficio claro.

Nano Concepts evalúa con objetividad las arquitecturas existentes y solo recomienda microservicios allí donde realmente resuelven su problema; en caso contrario, una aplicación correctamente modularizada.