Deployment

Unidades y fronteras del ciclo de instalación

Deployment examina qué unidades de software, configuración y artifacts se empaquetan, instalan, actualizan o revierten juntas o por separado, y cómo se ubican en un entorno. Su foco arquitectónico son las unidades desplegables y sus fronteras operacionales.

Una deployment unit es un conjunto gestionado como unidad de instalación o actualización. Puede ser una aplicación, servicio, workload de contenedores, función, worker, job, plugin o imagen de firmware. El artifact transporta software; el proceso es una realización en ejecución; el entorno proporciona condiciones de ejecución. No son términos intercambiables.

La literatura de Views and Beyond separa estructuras de módulos, ejecución y asignación al entorno. El metamodelo Deployment de SEI relaciona unidades de ejecución con computadores y redes. Esa vista permite examinar placement; el eje editorial del Atlas incorpora además las fronteras de actualización. SEI, System-of-Systems Viewpoint, sección 6.5 y tabla 14.

Es una dimensión de architecture-decision-axes, no un producto de infraestructura ni una tecnología de packaging. Un container puede realizar una decisión sin definir por sí solo toda la arquitectura de deployment.

Deployment frente a Deployability y release

deployability evalúa facilidad, seguridad y autonomía para llevar cambios a ejecución. Deployment describe qué unidades existen y cómo se instalan o actualizan. «Un artifact común» describe una frontera; «se instala en treinta segundos con riesgo aceptable» afirma una quality que requiere evidencia.

Más unidades no prueban mejor deployability. Una entrega común puede ser rápida y previsible; diez artifacts pueden necesitar una operación coordinada compleja. SEI examina granularidad, control y eficiencia como preocupaciones de deployability, mostrando que la estructura condiciona resultados sin garantizarlos. Software Architecture in Practice: patrones de deployability.

Release habilita comportamiento para usuarios; deployment instala o coloca software donde puede ejecutarse. A veces coinciden y otras se separan mediante configuración. El canonical de Deployability desarrolla esa distinción y sus mecanismos; este eje no prescribe una estrategia de release.

Module no equivale a deployment unit

decomposition identifica unidades de responsabilidad y sus fronteras. granularity aclara el alcance relativo de esas unidades: la granularidad lógica puede diferir de la granularidad de instalación:

Variante ilustrativa	Decomposition	Deployment
Commerce modular	Diez módulos lógicos.	Una aplicación común.
Commerce distribuido	Diez capacidades lógicas.	Diez servicios desplegables.
Capacidad con API y worker	Una capacidad amplia.	Dos unidades gestionadas.

No hay una correspondencia obligatoria uno a uno. Orders puede tener API y worker separados; varios módulos pueden instalarse en un solo artifact. Una carpeta, repository o package no demuestra cuál es la unidad operacional.

En un modular-monolith, un cambio localizado en Payments puede exigir instalar la aplicación que también contiene Orders e Inventory. Eso no borra la encapsulación lograda ni demuestra mala calidad. modifiability y Deployability evalúan consecuencias diferentes de esa combinación.

Artefactos separados e independencia efectiva

Independent deployment significa poder cambiar y desplegar una unidad sin exigir simultáneamente cambios en unidades no relacionadas. Separar artifacts o procesos habilita algunas acciones operacionales; la independencia requiere contratos y datos compatibles.

Si Orders v2 exige Payments v2 y Payments exige Shipping v2 al mismo tiempo, existe lockstep deployment. Entre las causas posibles están contratos incompatibles, schema compartido, dependencias de bibliotecas, limitaciones del tooling y secuencias de negocio.

Una biblioteca compartida no obliga universalmente a instalar todos sus consumidores juntos: pueden usar versiones compatibles distintas. La obligación aparece cuando el cambio altera condiciones que deben mantenerse conjuntamente. dependency-structure permite identificar esa necesidad, en lugar de inferirla del número de pipelines.

Lockstep no es siempre incorrecto. Un producto puede elegir una entrega coordinada por simplicidad o por restricciones reales. Debe reconocer alcance, orden y respuesta ante fallo. Repositorios separados o el nombre microservice no convierten esa operación en independiente.

micro-frontends lleva esta pregunta a una experiencia compuesta: publicar aplicaciones frontend separadas no prueba que puedan cambiar sin actualizar shell o vecinos. backend-for-frontend agrega otra frontera posible para adaptación cliente. No exige un BFF por aplicación frontend ni una unidad de deployment por servicio de dominio; hay que comprobar qué contratos y versiones permiten evolucionar cada parte.

mobile-architecture distingue publicación de un paquete y actualización de la población instalada. Un backend nuevo puede coexistir con varias versiones cliente: rollout y reversión del servidor no sustituyen comprobar sus contratos ni los datos locales que esas versiones interpretan. La distribución y política de soporte condicionan la independencia efectiva de cada cambio.

Continuous Delivery relaciona independencia con encapsulación y contratos compatibles; esa fuente motiva evaluar obligaciones reales antes de prometer autonomía. No demuestra que cualquier separación física las elimine. Architecture for Continuous Delivery.

Versiones que coexisten y schemas

Una arquitectura que instala Orders v2 sin actualizar Payments puede necesitar que Orders v2 y Payments v1 interpreten sus contratos correctamente. interoperability examina intercambio y uso de información; aceptar el mismo formato no prueba acuerdo semántico.

Durante el rollout también pueden coexistir instancias viejas y nuevas de una unidad. Su interacción con estado y consumidores debe seguir siendo legal. No basta probar solo la versión más reciente de todo el sistema.

Sato describe expand, migrate y contract para cambiar interfaces evitando sustituir todos los consumidores a la vez. parallel-change desarrolla esa ventana de compatibilidad y sus obligaciones de retirada. Fuente primaria de Sato. strangler-fig puede mover responsabilidad y branch-by-abstraction sustituir implementación sin exigir que cada paso sea una deployment unit nueva; ninguno convierte rollback de tráfico en reversión de datos.

Un schema compartido puede conectar ciclos de deployment: aplicación v2 exige un campo o significado que v1 no entiende. Cambios aditivos, migración gradual y sequencing pueden ayudar, según el contrato. Agregar un campo tampoco prueba compatibilidad si un consumidor rechaza información desconocida.

data-ownership puede localizar autoridad y cambios de representación. Separar bases aumenta superficie operacional y no corrige automáticamente un contrato incompatible. El problema requiere mirar acceso y evolución, sin imponer database per service.

Revertir software y recuperar estado

Deployment define qué unidad puede reinstalarse o actualizarse hacia adelante. deployability desarrolla cómo evaluar esas operaciones con seguridad. Volver a un binary anterior no revierte necesariamente una transformación de datos, un evento publicado o un cobro externo.

Para Commerce, Payments v2 puede haber producido información que Payments v1 no interpreta. Una reversión del artifact puede agravar el problema. La respuesta podría ser una corrección hacia adelante o una transición compatible, con evidencia y autoridad explícitas.

Fowler y Sadalage examinan evolución coordinada de aplicación y datos. Su tratamiento ayuda a recordar que instalar versiones y modificar representaciones son acciones relacionadas; no constituye una receta universal de migración. Evolutionary Database Design.

No se detallan aquí blue/green, canary ni procedimientos de rollback. Son mecanismos y estrategias que deben evaluarse contra los compromisos de las unidades escogidas.

Communication y coordinación de cambios

communication define cómo intercambian información las unidades. Comunicación remota no demuestra deployment independiente: dos servicios pueden necesitar instalarse juntos. Comunicación local tampoco obliga siempre a un artifact común, por ejemplo un plugin compatible instalado separadamente y cargado dentro del proceso anfitrión.

Ese ejemplo requiere declarar contrato, activación y posibles reinicios; no promete que todo plugin sea independiente. La frontera de proceso y la de instalación son distintas preguntas.

coordination define acuerdos para resultados conjuntos. Si Orders v2 conduce Place Order con Payments v1, las transiciones, resultados y recuperación deben seguir siendo compatibles. La independencia de instalación no autoriza suponer que todos los participantes cambian simultáneamente.

Placement, réplicas e Isolation

Una unidad Orders Service puede tener tres réplicas. La existencia y frontera de la unidad son decisiones distintas de cuántas copias ejecutan y dónde están. Placement asigna instancias a recursos o entornos; cambiar la cantidad no necesariamente crea nuevas unidades lógicas de deployment.

Separar instalación puede permitir restart o rollout particular y mantener un nodo, broker, database o red comunes. isolation examina qué efectos quedan contenidos. Dos despliegues distintos no garantizan fault isolation; una aplicación común puede contener pools o límites internos.

También pueden existir unidades colaboradoras cercanas, como un proceso auxiliar y la aplicación. Que sean dos procesos no determina si sus versiones deben actualizarse juntas. Hay que declarar qué lifecycle operacional se gestiona, no deducirlo de la forma del diagrama.

scaling pregunta qué capacidad puede crecer o reducirse. Una unidad desplegable puede alojar pools cuya concurrencia cambia internamente; varias réplicas también pueden compartir un límite de datos. Unidad de instalación y unidad ampliable no son necesariamente la misma frontera.

architectural-quantum [ADVANCED] exige examinar también cohesión y dependencias estructurales o dinámicas. Una imagen instalable por separado no demuestra ese alcance; datos y contratos pueden exigir coordinación fuera del artifact.

Commerce: variantes del mismo reparto

Orders, Payments, Inventory y Shipping pueden vivir en una aplicación con handlers, worker y job programado. Allí el cambio de código instala el conjunto, aunque cada actividad tenga otro execution-model.

Otra variante instala Payments y Shipping por separado, con Orders e Inventory en una aplicación común. La revisión pregunta si cambiar Payments requiere actualizar consumidores, si los schemas admiten coexistencia y qué unidad responde por trabajo pendiente durante el cambio.

tenancy añade otra decisión: Tenant A y Tenant B pueden compartir la actualización, mientras Tenant C dispone de una ventana dedicada. Un deployment por tenant implementa una frontera de sharing; no es la definición del eje Tenancy ni garantiza independencia frente a servicios comunes.

Estos son ejemplos de decisión, no una recomendación para distribuir Commerce ni una afirmación sobre el deployment real del Atlas.

Profiles y evidencia

Si se pretendía deployment independiente y cada cambio pasa a exigir releases simultáneos, architecture-erosion invita a revisar qué contrato se debilitó. fitness-functions puede evaluar compatibilidad entre versiones soportadas; no prueba independencia por la existencia de artifacts separados ni convierte toda coordinación temporal en erosión.

serverless-architecture puede ofrecer funciones y recursos gestionados como unidades pequeñas de entrega. Artifacts separados pueden seguir ligados por triggers, IAM, configuración, contratos o schemas. La delegación del host no elimina coordinación de versiones ni convierte rollback de código en reversión de efectos.

monolith y Modular Monolith suelen mantener fronteras de instalación amplias. service-based-architecture suele usar varios servicios amplios. microservices enfatiza unidades con evolución y deployment independientes. service-oriented-architecture exige precisar ciclos de proveedores y acuerdos. Son tendencias que deben comprobarse en la realización.

Un artifact único no es mala arquitectura por definición; más unidades agregan versiones, compatibilidad y operación. operability necesita relacionar versión instalada, estado y efectos observados. portability examina adaptación a otro entorno; una instalación automatizada en un destino no demuestra esa transferencia.

Para revisar la decisión, elegir un cambio de Payments y enumerar qué unidades, datos y contratos deben cambiar, qué versiones pueden coexistir y cómo se detecta un resultado inaceptable. Esa evidencia separa fronteras reales de una colección de artifacts nominalmente independientes.