Los microservicios dividen un sistema por capacidades que pueden evolucionar de forma autónoma
Una arquitectura de microservicios organiza una aplicación como servicios pequeños desplegables de forma independiente, cada uno responsable de una capacidad de negocio y de sus datos. “Pequeño” no significa un número fijo de líneas ni una función aislada: el límite debe permitir que un equipo cambie el servicio sin coordinar cada entrega con todo el sistema. Si las partes comparten base de datos, despliegue y ciclos de fallo, pueden ser módulos distribuidos, no microservicios autónomos.
Un monolito reúne componentes en una unidad de despliegue. Puede estar bien modularizado, probarse con facilidad y escalar como conjunto. Los microservicios trasladan fronteras internas a llamadas de red, lo que permite tecnologías y ritmos diferentes, pero introduce latencia, fallos parciales y operación distribuida. La decisión no es moderna frente a antigua: depende de tamaño del dominio, equipos y necesidad real de independencia.
La autonomía de datos evita acoplamiento, pero complica las transacciones
Cada servicio debería controlar su modelo y almacenamiento; otro accede mediante contrato, no leyendo tablas internas. Esto permite cambiar esquemas sin romper consumidores ocultos. A cambio, una operación que atraviesa pedidos, pagos e inventario ya no cabe en una transacción local única. Se coordinan eventos, compensaciones o sagas y se acepta que distintas vistas pueden ser temporalmente inconsistentes.
La consistencia eventual no significa datos aleatorios ni renunciar a reglas. Cada dominio mantiene invariantes locales y los procesos distribuidos necesitan estados, identificadores idempotentes y manejo explícito de reintentos. Un mensaje puede llegar dos veces o fuera de orden. Diseñar para esos casos es parte de la lógica del producto; esconderlos bajo una cola solo desplaza el fallo.
Los límites suelen buscarse alrededor de capacidades como catálogo, facturación o envíos, no de capas técnicas como interfaz y base de datos. El diseño guiado por dominio habla de contextos delimitados con vocabulario y reglas propios. Dos servicios pueden usar la palabra cliente con atributos distintos sin compartir un modelo universal. Forzar una entidad común vuelve a acoplarlos; ignorar procesos que cruzan contextos crea duplicaciones contradictorias. La frontera se ajusta observando cambios reales.
Una llamada remota nunca se comporta como una función local
En red hay tiempos de espera, pérdida, saturación y respuestas ambiguas: tras un timeout no siempre sabemos si la operación ocurrió. Los clientes necesitan límites de espera, reintentos con retroceso, circuit breakers y presupuestos de latencia. Multiplicar llamadas encadenadas aumenta la probabilidad de fallo y puede provocar tormentas de reintentos. Reducir dependencias síncronas suele mejorar más que añadir infraestructura.
La observabilidad debe unir trazas, métricas y registros mediante identificadores de correlación. No basta con comprobar que cada proceso está vivo: interesa si la solicitud completa cumple su objetivo. Contratos versionados, pruebas de consumidor y despliegues graduales reducen incompatibilidades. La computación distribuida aporta los conceptos; los microservicios son una elección arquitectónica concreta sobre ellos.
Contenedores y Kubernetes pueden alojarlos, pero no los definen
Los contenedores empaquetan procesos y dependencias; un monolito también puede ejecutarse en uno y un microservicio puede correr sin contenedor. Kubernetes programa cargas, reinicia instancias y ofrece descubrimiento y configuración declarativa. No decide buenos límites de dominio, consistencia ni contratos. Introducir orquestación antes de dominar el sistema añade una plataforma que también debe protegerse y actualizarse.
Escalar servicios por separado ahorra recursos cuando la carga es desigual, pero fragmentar demasiado multiplica imágenes, redes, secretos y pipelines. La plataforma necesita automatizar compilación, despliegue, certificados, telemetría y políticas. Sin una experiencia interna sencilla, cada equipo resuelve lo mismo de forma distinta y la supuesta autonomía se convierte en coste operativo.
Compensan cuando la independencia obtenida supera la complejidad distribuida
Una organización con varios equipos, dominios claros y ritmos de cambio diferentes puede beneficiarse. También ayudan a aislar cargas o requisitos de seguridad. Para una aplicación pequeña, un monolito modular suele permitir aprender el dominio con menos piezas. Extraer un servicio después es más fácil cuando existen fronteras internas limpias; empezar distribuido no corrige un modelo confuso.
Las señales de mala adopción incluyen servicios que siempre se despliegan juntos, cambios que atraviesan numerosos repositorios y una base compartida. También el “monolito distribuido”: toda la latencia y ninguna autonomía. Evaluar arquitectura exige medir frecuencia de entrega, incidentes, coste de operación y capacidad de cambio. El objetivo no es acumular servicios, sino reducir el tiempo y el riesgo de evolucionar un sistema.
Migrar con el patrón estrangulador reduce riesgo: nuevas funciones rodean al monolito y se extraen capacidades cuando existe una razón medible. Una capa de adaptación mantiene contratos durante la transición. Reescribir todo de una vez pierde conocimiento implícito y retrasa valor. También puede ocurrir el camino inverso: fusionar servicios demasiado finos disminuye coordinación y latencia. La arquitectura es reversible si los contratos, datos y objetivos están documentados.
La seguridad también se distribuye. Cada servicio autentica llamadas, protege secretos y valida entradas, mientras una puerta de enlace puede aplicar políticas comunes. Confiar en que la red interna es segura permite movimiento lateral tras una intrusión. Identidades de carga, cifrado y autorización por acción reducen ese riesgo, pero aumentan certificados y configuración. Un mapa de flujo de datos ayuda a decidir dónde reside información sensible y qué registros pueden conservarse sin duplicarla por todo el sistema.
