Arquitectura de microservicios: qué es, ventajas y desafíos : Kamilinux

La arquitectura de microservicios organiza una aplicación como un conjunto de servicios autónomos, cada uno responsable de una capacidad de negocio y conectado a los demás mediante interfaces definidas. Su ventaja potencial es permitir que equipos publiquen y escalen partes del sistema por separado. A cambio, introduce comunicación de red, consistencia distribuida y más trabajo de operación; dividir una aplicación en procesos pequeños, por sí solo, no garantiza independencia.

Qué hace que una arquitectura sea de microservicios

Un microservicio se delimita por una responsabilidad de negocio coherente, no por un número fijo de líneas ni por una función aislada. Debe poder desarrollarse y evolucionar con un equipo, exponer un contrato claro y gestionar su lógica y sus datos sin depender de que otros servicios conozcan sus detalles internos. El tamaño puede variar: la cohesión y la autonomía son más importantes que hacerlo diminuto.

Los servicios pueden comunicarse con peticiones síncronas —el emisor espera una respuesta— o mediante mensajes y eventos, donde quien publica no necesita que todos los consumidores respondan en ese instante. La elección depende del caso. Añadir llamadas de red entre componentes que antes se ejecutaban dentro del mismo proceso cambia los tiempos de respuesta y los modos de fallo.

Ejemplo: una compra en una tienda en línea

Una aplicación de comercio electrónico podría separar catálogo, pedidos, inventario y pagos si cada área tiene reglas propias y necesita evolucionar de forma autónoma. Al confirmar una compra, el servicio de pedidos registra la solicitud y coordina la reserva de existencias y el cobro. El resultado de una operación puede llegar unos instantes después, por lo que el sistema debe comunicar si el pedido está pendiente, confirmado o cancelado.

Capacidad	Responsabilidad posible	Dato que debe controlar
Catálogo	Productos, precios visibles y disponibilidad publicada.	Información descriptiva y comercial del producto.
Pedidos	Estado y ciclo de vida del pedido.	Pedido, líneas y transiciones de estado.
Inventario	Unidades disponibles y reservas.	Existencias y movimientos de reserva.
Pagos	Autorizaciones, cobros y devoluciones.	Referencias y estados de pago, protegiendo los datos sensibles.

Esta división es solo un ejemplo: la frontera correcta depende de las reglas reales del negocio. Si catálogo, pedidos e inventario cambian siempre juntos, pertenecen al mismo equipo y necesitan transacciones inmediatas entre sí, separarlos puede empeorar el diseño en vez de mejorarlo.

Propiedad de los datos y consistencia

Cada servicio debe controlar la información de la que es responsable. Otros servicios solicitan esos datos mediante una interfaz o reciben eventos; no deberían depender de leer y modificar directamente las tablas internas de otro servicio. Esto reduce el acoplamiento al cambiar un esquema. La separación es lógica y de propiedad: varios servicios pueden usar el mismo servidor de base de datos si sus datos y cambios permanecen bajo límites claros.

Un límite importante aparece cuando una operación de negocio afecta a más de un servicio. Una base de datos monolítica puede resolver varias escrituras con una transacción local; entre bases de datos independientes no suele existir una única transacción simple que confirme o deshaga todo. A menudo cada servicio guarda su parte y comunica el resultado, lo que lleva a consistencia eventual: durante un intervalo, dos vistas del sistema pueden mostrar estados distintos.

Para un flujo como el pedido, se pueden definir acciones compensatorias: si el cobro falla después de reservar inventario, liberar la reserva; si un paso tarda, mantener el pedido pendiente y permitir que el cliente consulte su estado. Este patrón de coordinación se conoce como saga. Requiere manejar reintentos, mensajes duplicados y operaciones idempotentes para no cobrar o reservar dos veces por error.

Ventajas posibles y condiciones necesarias

Ventaja posible	Cuándo aparece	Qué hay que preparar
Despliegue independiente	El servicio tiene un contrato compatible y no obliga a publicar al mismo tiempo a sus consumidores.	Versionado, pruebas de contrato y despliegues automatizados.
Escalado por capacidad	Un servicio concreto consume más recursos que otros.	Métricas que muestren el cuello de botella y una plataforma capaz de escalarlo.
Propiedad clara entre equipos	Los límites reflejan capacidades de negocio y cada equipo puede mantenerlas.	Responsabilidad operativa, documentación y objetivos de servicio.
Aislamiento de fallos	Los consumidores toleran la indisponibilidad de dependencias.	Timeouts, límites de reintentos, degradación controlada y monitorización.
Elección de tecnología	Hay una necesidad real de usar herramientas distintas por servicio.	Capacidad de mantener más runtimes, dependencias y conocimientos.

Ninguna de estas ventajas se obtiene automáticamente. Una cadena de llamadas síncronas puede propagar una caída; una API que cambia sin compatibilidad puede romper consumidores; y escalar más instancias solo ayuda si la aplicación y sus datos admiten esa estrategia.

El coste operativo de distribuir la aplicación

Con más servicios aparecen más procesos, despliegues, configuraciones, credenciales y dependencias de red. Una petición del usuario puede atravesar varios componentes; para investigar una demora o un error hacen falta registros correlacionados, métricas y trazas distribuidas. También se debe proteger la comunicación entre servicios, gestionar secretos y versionar los contratos que usan.

Los límites entre servicios exigen decisiones sobre datos y fallos que una arquitectura dentro de un único proceso puede evitar. Si el equipo aún no dispone de automatización, observabilidad y experiencia de operación, el coste de esas piezas puede superar el beneficio de publicar módulos por separado.

Microservicios, monolito modular y Docker

Un monolito es una unidad que se compila o despliega en conjunto; no tiene por qué ser un bloque de código desordenado. Un monolito modular puede separar responsabilidades internamente y conservar una publicación sencilla. Si los límites todavía no están claros, empezar con módulos dentro de una aplicación puede permitir aprender del dominio antes de convertirlos en servicios de red.

Docker puede empaquetar tanto una aplicación monolítica como los procesos de una arquitectura distribuida. Usar un contenedor por servicio puede facilitar despliegues separados, pero Docker no decide las fronteras del negocio ni resuelve las transacciones entre servicios. Es una herramienta de empaquetado y ejecución; el diseño distribuido requiere contratos, gestión de fallos y observabilidad propios.

Cómo decidir si convienen los microservicios

¿Hay capacidades de negocio con límites claros y datos que puedan tener propietarios definidos?
¿Se necesita desplegar o escalar esas capacidades con ritmos realmente distintos?
¿Los equipos pueden mantener los servicios y responder por su operación?
¿Hay automatización de despliegues, monitorización y trazas para diagnosticar peticiones que cruzan la red?
¿El beneficio esperado supera el trabajo añadido de consistencia, seguridad y coordinación?

Si la mayoría de respuestas es no, conservar una aplicación modular puede ser una opción más sencilla y fiable. La arquitectura debe resolver necesidades concretas de evolución, escala o autonomía; no es un objetivo por sí mismo.

Preguntas frecuentes

¿Un microservicio tiene que usar su propia base de datos física?

No necesariamente. Lo importante es que el servicio sea dueño de su modelo y de sus escrituras, y que otros no dependan directamente de sus tablas. La infraestructura física puede compartirse si se mantienen esos límites.

¿Los microservicios evitan que una avería afecte a toda la aplicación?

No por sí solos. Una dependencia caída puede bloquear a los servicios que la llaman. Para contener el impacto hay que definir tiempos límite, limitar reintentos, ofrecer alternativas y observar el comportamiento de la cadena.

¿Docker convierte una aplicación en microservicios?

No. Docker crea y ejecuta contenedores a partir de imágenes. Una aplicación monolítica puede ejecutarse en un contenedor; microservicios requieren límites de negocio y comunicación entre servicios diseñados explícitamente.