Microservices

Un perfil de autonomía con costos distribuidos

Microservices es un Architecture Profile que combina servicios delimitados, despliegue independiente, comunicación de red, ownership y capacidades operativas. Para el Atlas no es una elección aislada de decomposition ni una categoría determinada por tamaño de código.

Lewis y Fowler describen servicios organizados alrededor de capacidades de negocio, desplegables independientemente, con énfasis en gobierno y datos descentralizados. Microservices. Richardson presenta un marco de problema, fuerzas y consecuencias para esta aproximación. Microservice Architecture pattern.

Las denominaciones style y pattern siguen siendo válidas dentro de sus fuentes. architecture-pattern-terminology documenta esa variación; architecture-profile explica la convención del Atlas. architectural-style-vs-architecture-profile muestra cómo Microservices puede ser style para Lewis y Fowler, pattern para Richardson y profile para el Atlas. El valor se evalúa por compromisos efectivos, no por adoptar el nombre.

Service boundaries y change coupling

Un servicio reúne responsabilidades que pueden evolucionar con una autonomía útil. La alineación con capacidades de negocio o dominios ayuda a evitar una distribución basada solamente en capas técnicas o entidades de datos.

Micro no significa cantidad de líneas ni de endpoints. El límite debe examinar cohesión, invariantes y cambios que ocurren juntos. Si completar una operación requiere numerosas conversaciones entre partes que siempre cambian conjuntamente, conviene revisar la descomposición.

La autonomía tampoco significa ausencia de dependencias. Un servicio ofrece contratos y puede consumir otros; necesita preservar su significado mientras cambia su implementación. Separar procesos sin controlar change coupling puede producir una arquitectura distribuida cuyas entregas siguen fuertemente coordinadas.

Independent deployability y evolución

Independent deployability permite cambiar y entregar un servicio sin exigir habitualmente actualizar el conjunto. Es una capacidad arquitectónica y operativa: contratos compatibles, migraciones deliberadas, pruebas y mecanismos de delivery deben sostenerla.

Tener un pipeline por repositorio no demuestra independencia. Si una nueva versión requiere detener todos los consumidores, el contrato conserva coordinación transversal. Tampoco un repositorio común la impide necesariamente: el código y la unidad de release son decisiones distintas.

Algunos cambios de negocio cruzarán servicios y requerirán colaboración entre equipos. La meta es limitar esa coordinación a necesidades reales, no prometer que cada cambio será local. La autonomía de evolución se verifica observando entregas y dependencias durante el tiempo. deployability investiga compatibilidad y coordinación de versiones; modifiability costo y propagación de un cambio; evolvability capacidad de continuar adaptándose. La cantidad de servicios no demuestra ninguno de esos resultados.

Decision axes

Eje	Énfasis y límite
Decomposition	Servicios alrededor de responsabilidades o capacidades delimitadas.
Dependency Structure	Contratos explícitos; evitar depender de implementación privada.
Communication	Interacciones de red y mensajes con fallos parciales posibles.
Coordination	Invariantes locales; procesos entre servicios requieren acuerdos explícitos.
Data Ownership	Cada servicio controla su información autoritativa y sus cambios.
Isolation	Separación de procesos puede ayudar; recursos comunes limitan fault isolation.
Tenancy	Diseño adicional de acceso, partición y recursos entre tenants.
Deployment	Fuerte énfasis en versiones y entregas independientes.
Execution Model	Servicios, tareas o consumidores; no exige un runtime particular.
Scaling	Crecimiento de capacidades seleccionadas, sujeto a dependencias y datos.

El perfil no prescribe Docker, Kubernetes ni un proveedor cloud. Esas herramientas pueden implementar decisiones operativas, pero no sustituyen contratos, límites ni responsabilidad sobre resultados.

Data ownership lógico y físico

Service owns its data significa autoridad sobre reglas, representación e información autoritativa. Otros servicios interactúan mediante contratos; no deberían modificar arbitrariamente tablas privadas ni depender de su forma interna.

No exige un servidor físico de base de datos por servicio. Richardson distingue tablas privadas, schemas separados y servidores separados. Database per service. Permisos y mecanismos de encapsulación deben hacer real esa separación lógica.

Compartir infraestructura puede reducir overhead y conservar riesgos comunes de capacidad, mantenimiento o disponibilidad. Separarla puede mejorar aislamiento y añadir operación. data-ownership y isolation responden preguntas distintas: autoridad sobre estado y contención de efectos. El análisis necesita ambas sin deducirlas del número de bases o procesos.

Una copia local de información ajena no convierte al consumidor en autoridad sobre ella. Hay que definir actualización, frescura, corrección y qué decisión puede basarse en una copia desactualizada. La consistencia eventual se menciona como una opción, no como una regla obligatoria para todos los datos.

Consistency boundaries y procesos

Una transacción local puede proteger invariantes dentro del recurso de un servicio. Un proceso que cambia datos de varios servicios no adquiere atomicidad global porque sus pasos compartan una solicitud HTTP.

dual-write-problem explica el riesgo de actualizar datos y publicar un mensaje mediante operaciones independientes. transactional-outbox puede preservar esa relación local; no convierte una conversación completa en una transacción atómica. saga-pattern permite razonar sobre procesos y compensaciones cuando las condiciones del dominio lo admiten.

El diseño debe decidir qué estados intermedios son aceptables, quién observa el progreso y cómo se completa una operación pendiente. Separar una invariante que necesita consistencia inmediata entre servicios puede aumentar coordinación sin aportar autonomía suficiente.

De llamadas locales a red

Transformar una llamada local en una interacción remota introduce latencia, serialización, indisponibilidad y resultados ambiguos. Un consumidor puede dejar de esperar mientras el proveedor continúa ejecutando. timeout no garantiza cancelación del efecto; retry necesita condiciones seguras para repetir.

Una entrega repetida no debe confundirse con múltiples efectos deseados. delivery-guarantees e idempotency ayudan a separar recepción de mensajes y cambios de negocio, sin prometer que un protocolo ofrece exactamente una ejecución de toda la operación.

Separar servicios tampoco garantiza que un fallo quede contenido. circuit-breaker puede restringir admisión a una dependencia fallida y bulkhead proteger recursos, pero necesitan implementación y configuración apropiadas. Recursos, datos o identidades compartidos pueden seguir vinculando la disponibilidad.

Cuando una dependencia se ralentiza, acumular trabajo o repetir sin presupuesto puede producir overload, retry-storms y cascading-failures. Estos enlaces desarrollan mecanismos específicos; el perfil solo hace explícito el costo de introducir fronteras distribuidas.

Equipos y tecnología

La alineación entre servicios y equipos puede reducir coordinación cuando cada equipo tiene autoridad para diseñar, entregar y operar su capacidad. El ownership no consiste únicamente en una carpeta asignada: incluye responder por contratos, incidentes y evolución.

La descentralización puede permitir tecnologías adecuadas al problema. La heterogeneidad añade herramientas, habilidades y obligaciones de mantenimiento; no hay un premio arquitectónico por usar un lenguaje diferente en cada servicio.

Newman documenta que los modelos de ownership abiertos también necesitan acuerdos cuando servicios o entregas están acoplados. Open Service Ownership. La autonomía organizativa debe evaluarse por decisiones disponibles y esfuerzo de coordinación, no solamente por un organigrama.

Automation, observability y testing

La operación necesita gestionar versiones simultáneas, configuración, incidentes y recuperación. Fowler señala capacidades de provisioning, monitoring y delivery rápido como requisitos importantes para sostener Microservices. Microservice Prerequisites.

La observabilidad debe relacionar eventos técnicos con resultados de negocio a través de servicios. Correlación, latencia de dependencias y saturación permiten distinguir un fallo local de una cadena de esperas. El inventario de servicios no responde por sí solo qué solicitud quedó pendiente.

Los tests de servicio verifican comportamiento local; los de contrato comprueban expectativas entre participantes; los escenarios integrados examinan recorridos críticos. Depender solamente de una suite global puede retrasar cambios y ocultar qué contrato se rompió. La estrategia debe conservar confianza sin obligar a reconstruir el conjunto para toda modificación.

operability evalúa si sus responsables pueden diagnosticar e intervenir con seguridad, además de observar señales. Servicios independientes pueden localizar mitigación y ampliar estados operacionales. interoperability permite examinar significado y compatibilidad entre sus contratos; más servicios no garantiza ninguna de esas respuestas.

Scaling y costo efectivo

Microservices puede permitir scaling independiente de capacidades seleccionadas. No significa capacidad infinita ni una mejora automática de performance. Una base común, llamadas seriales o transferencias voluminosas pueden seguir dominando el resultado.

Microsoft describe beneficios de scaling y deployment por servicio junto con desafíos de consistencia, testing y operación. Microservices architecture style. monolith también puede escalar horizontalmente; la diferencia incluye granularidad y complejidad de coordinación.

cost-efficiency evalúa el costo respecto del servicio requerido. El costo efectivo reúne infraestructura, red, entornos, diagnóstico y tiempo de equipos. Aislar una capacidad muy demandada puede ahorrar recursos; fragmentar una operación estable puede aumentar trabajo sin un beneficio comparable. La comparación necesita cargas, escenarios de cambio y capacidades operativas reales. quality-attribute-trade-offs conecta beneficios potenciales del profile con sus efectos secundarios y evidencia, sin asumir que independencia de deployment satisface todas las prioridades.

Ejemplo y composición

Supongamos que catálogo requiere muchas lecturas y cambia con un ritmo distinto al procesamiento de cobros. Separar esas capacidades podría permitir entregas y scaling específicos. Si cada consulta al catálogo necesita contactar cobros y pedidos, la ventaja debe contrastarse con esa dependencia.

architectural-quantum [ADVANCED] permite contrastar la autonomía declarada con deployment, cohesión y coupling efectivos. Un servicio separado no demuestra un quantum independiente; una colaboración síncrona puede vincular características durante un flujo sin borrar necesariamente todas sus otras capacidades.

Un servicio puede organizar su interior mediante Hexagonal, otro mediante Layered y otro mediante Vertical Slice. Esas estructuras internas no se deducen del perfil global. event-driven-architecture puede intervenir en algunas comunicaciones y coexistir con solicitudes directas. Microservices no requiere EDA, ni EDA requiere Microservices; sus paquetes de decisiones pueden componerse. serverless-architecture puede realizar una capacidad con varias funciones, datos, colas y workflow. Una función no equivale a un microservice: importa la frontera de autonomía efectiva.

SOA comparte antecedentes e ideas de contratos, capacidades y autonomía. service-oriented-architecture analiza diferencias de énfasis sin presentar Microservices como «SOA bien hecha». service-based-architecture permite comparar agrupamientos más amplios sin definir fronteras por conteos.

Elección sin maturity ladder

Una plataforma nueva también puede contener technical-debt: autorización duplicada o schemas compartidos pueden exigir cambios repetidos y coordinación. Extraer servicios de legacy-systems no demuestra modernización útil; deben preservarse semántica, datos y operación mientras se comprueba qué independencia se obtiene.

Pasar de Monolith a Microservices no es una escalera universal de madurez. modular-monolith puede ser la arquitectura final correcta. Un sistema pequeño puede empeorar si fragmenta límites todavía inciertos y añade demasiada coordinación.

Newman examina dificultades operativas y de límites en un proyecto greenfield, en lugar de asumir que toda aplicación nueva necesita Microservices. Microservices For Greenfield?.

La elección requiere architectural-drivers comprobables y examinar la architectural-significance de los compromisos que justifican el costo. architecture-profiles organiza la comparación: autonomía y distribución son medios para objetivos concretos, no indicadores automáticos de avance.