Arquitectura DevOps y de microservicios

Los microservicios son una opción arquitectónica, no una medalla de madurez. Un monolito modular bien organizado puede resultar más sencillo de probar, desplegar y comprender cuando un solo equipo dirige el producto, la demanda es moderada y los límites del dominio aún se mueven. Los servicios distribuidos cobran sentido cuando distintas capacidades necesitan de verdad responsables, cadencias de entrega, escalado, tratamiento de seguridad o aislamiento de fallos diferentes. NobleJackal documenta ese caso antes de recomendar una separación. Si el coste operativo supera el beneficio previsto, puede ser más sensato sanear el monolito y su cadena de entrega.

El diagnóstico representa lo que funciona en realidad: aplicaciones, módulos, tareas programadas, colas, bases de datos, proveedores externos, repositorios, sistemas de compilación, entornos, rutas de red, secretos, pasos manuales y personas que aprueban cambios o atienden incidencias. Seguimos cambios representativos desde la petición hasta producción e incidentes desde la detección hasta la recuperación. Los diagramas se contrastan con código, configuración, telemetría y práctica del equipo; una fecha reciente no basta para darlos por vigentes. Las dependencias desconocidas y las excepciones no documentadas permanecen visibles.

Los atributos de calidad convierten un deseo genérico de modernización en una decisión concreta. Para los recorridos relevantes se priorizan disponibilidad, latencia, capacidad, integridad de datos, recuperación, seguridad, privacidad, auditabilidad, independencia de despliegue, mantenibilidad, portabilidad y coste. Cuando existen datos, se registran la línea de base y la calidad de la evidencia. Un objetivo como «desplegar con más frecuencia» no es aceptable sin indicar tipo de cambio, equipo, entorno, periodo de medición y condiciones tolerables de fallo o recuperación.

La unidad comercial queda cerrada por escrito: aplicaciones, dominios, equipos, entornos, candidatos a servicio, interfaces, flujos de datos, pipelines, infraestructura, oleadas de migración, talleres, tareas de ejecución, revisiones y periodo de soporte. Precio a consultar no equivale a disponer de un equipo de plataforma sin límite. Desarrollo de producto, software a medida, operación cloud gestionada, arquitectura de ciberseguridad, copia y recuperación, hosting, consumo de terceros y guardia continua siguen siendo encargos separados salvo inclusión expresa.

Los candidatos se modelan alrededor de capacidades de negocio y contextos delimitados; después se comprueba si la organización puede hacerse cargo de ellos. Funciones que cambian juntas, dependen de una sola transacción o exigen despliegues coordinados pueden pertenecer al mismo conjunto aunque el diagrama permita separarlas. Una capacidad con equipo, ciclo de vida del dato, perfil de carga o frontera de seguridad propios sí puede justificar un despliegue independiente. El registro conserva los límites descartados y sus contrapartidas para que el razonamiento no se pierda con el siguiente equipo.

Todo límite necesita un contrato. APIs síncronas, eventos asíncronos, intercambios por lotes y transferencias de archivos se documentan con productor, consumidor, responsable, esquema, autenticación, autorización, disponibilidad esperada, timeout, reintento, idempotencia, versión y retirada. Un documento OpenAPI puede describir una interfaz HTTP, pero el contrato de entrega también abarca comportamiento, errores y reglas de cambio. Las pruebas de consumidor y compatibilidad protegen relaciones importantes; no sustituyen la comprobación integral de un recorrido real.

La propiedad de los datos se resuelve antes de extraer un servicio. Se identifican sistema de registro, lectores y escritores permitidos, claves de identidad, clasificación de privacidad, conservación, migración y responsable de conciliación. Una base compartida no se disfraza de autonomía. Cuando una operación de negocio cruza límites, se diseñan expresamente consistencia, orden, entregas duplicadas, compensación, repetición y recuperación. Patrones como outbox, saga o event sourcing se adoptan solo si su complejidad adicional está justificada y el equipo puede mantenerla.

El mapa de dependencias incluye llamadas, eventos, identidad, DNS, certificados, configuración, colas, cachés, bases de datos y servicios externos. En cada trayecto importante se decide qué ocurre si una dependencia responde despacio, no está disponible, repite una acción o devuelve un resultado ambiguo. Timeouts, reintentos acotados, espera progresiva, circuit breakers, compartimentos, descarte de carga y degradación controlada se aplican donde aportan valor y se prueban. Añadir todos los patrones por defecto puede generar tanta incertidumbre como no gobernar los fallos.

Un servicio solo es desplegable de forma independiente cuando su código, compilación, artefacto, configuración, cambio de datos y autoridad de publicación pueden avanzar sin coordinación oculta. El diseño registra propiedad del repositorio, normas de rama y revisión, entradas reproducibles, política de dependencias, identidad del artefacto y promoción entre entornos. Una imagen de contenedor es un objeto de versión; no demuestra por sí sola que el sistema sea cloud native. Procedencia, SBOM o firma se incorporan en la profundidad necesaria y sostenible, sin presentarlas como seguridad automática de la cadena de suministro.

La integración continua ejecuta los controles que protegen al servicio y a quienes lo consumen. Pruebas unitarias, de integración, contrato, migración, seguridad, políticas, rendimiento y smoke se distribuyen en etapas con un comportamiento de fallo claro. Los controles costosos pueden organizarse por capas en lugar de bloquear cada commit, pero una puerta crítica no queda opcional en silencio. Datos de prueba, servicios externos y diferencias de entorno se controlan lo suficiente para interpretar el resultado. Un pipeline verde solo acredita que sus comprobaciones nombradas pasaron sobre una revisión concreta.

Infraestructura, configuración y políticas reciben la misma disciplina de versión y revisión que el código. Infrastructure as Code define los recursos incluidos; no convierte automáticamente en estado gobernado cada ajuste manual ni los valores predeterminados del proveedor. Los secretos quedan fuera del repositorio, el acceso sigue el mínimo privilegio y las credenciales de producción tienen titular, rotación y revocación. Planes, drift, estado, versiones de proveedor y cambios de emergencia quedan registrados para que la automatización no oculte un camino operativo paralelo.

La forma de publicar se adapta al riesgo y a la plataforma. Rolling, canary, blue-green, feature flags o entregas por fases requieren señales de salud, responsable de decisión, condiciones de parada y vía de recuperación. Los cambios de base de datos y eventos mantienen compatibilidad durante la convivencia; no se promete rollback después de una mutación irreversible. En ese caso se documentan reparación hacia delante, restauración o compensación. Que la orden de despliegue termine bien no demuestra que el usuario haya recibido el comportamiento previsto.

La fiabilidad parte del recorrido del usuario y del negocio, no únicamente del uptime del servidor. Se definen indicadores para los comportamientos relevantes y, cuando hay evidencia suficiente, objetivos con ventana, exclusiones y responsable. Los presupuestos de error pueden ayudar a equilibrar cambio y fiabilidad, pero exigen medidas fiables y un proceso real de decisión. Un SLO recién escrito no prueba el rendimiento histórico; el SLA de un proveedor tampoco describe todo el trayecto que vive el cliente.

Métricas, logs y trazas se diseñan como un conjunto. Los identificadores de correlación acompañan la petición entre servicios; los eventos aportan contexto sin recoger datos personales o secretos innecesarios; los paneles conectan síntomas con dependencias y versiones. OpenTelemetry puede dar una estructura neutral, pero la calidad de instrumentación, muestreo, convenciones, conservación y alertas sigue requiriendo decisiones. El objetivo es responder preguntas durante una incidencia real, no llenar una pantalla de gráficos vistosos.

La seguridad entra en identidades, interfaces y cadena de entrega. Se separan personas y cargas de trabajo, se reducen permisos, la confianza entre servicios queda explícita, los secretos rotan, las rutas de red se controlan y la autorización de API se prueba por objeto y función. El modelo de amenazas cubre administración, compilación, registros, dependencias, APIs expuestas, colas, datos y terceros. NIST SSDF y OWASP pueden orientar controles; ninguno certifica una implantación ni elimina la necesidad de revisión y pruebas específicas.

Cada servicio productivo necesita responsable, ruta de escalado y evidencias de operación. Las alertas responden a condiciones accionables, los runbooks describen diagnóstico y recuperación seguros, y las incidencias conservan cronología y decisiones para aprender. Capacidad, cuotas, límites, crecimiento de colas, certificados, copias, dependencias de restauración y consumo cloud se revisan antes de convertirse en urgencias. Monitorización 24/7, respuesta activa, operación cloud gestionada y compromisos de recuperación solo existen si cuentan con equipo, precio y alcance escritos por separado.

Una migración brownfield se planifica como una secuencia de convivencias controladas. Strangler, branch by abstraction, modularización o sustitución selectiva permiten mover una capacidad mientras el sistema actual continúa atendiendo. Enrutamiento, identidad, sincronización de datos, conciliación y propiedad se diseñan para la transición, no solo para el dibujo final. La sustitución de golpe se reserva para casos con un corte defendible, recuperación probada y una autoridad dispuesta a aceptar la concentración de riesgo.

La primera porción se elige por su valor de aprendizaje y consecuencia manejable, no porque sea fácil de representar. Debe recorrer la fuente, el contrato, el pipeline, la infraestructura, la observabilidad, la seguridad y el soporte previstos. La aceptación cubre función, compatibilidad, rendimiento, fallos, conciliación, despliegue y recuperación. La evidencia del piloto puede ampliar, rediseñar, pausar o reintegrar la extracción en una aplicación modular. Cambiar la decisión con pruebas no es falta de ambición.

El rendimiento de entrega se mide sin convertir las métricas en cuotas. Frecuencia de despliegue, tiempo de cambio, recuperación tras despliegue fallido, tasa de fallos y retrabajo muestran restricciones si la definición y la población permanecen estables. Se leen junto con fiabilidad, seguridad, impacto en clientes, carga del equipo y coste. No se premia partir entregas, ocultar incidencias o cambiar el denominador. La línea de base precede a la afirmación; un lanzamiento arquitectónico no se atribuye mejoras ocurridas antes.

La entrega conecta los diagramas con el sistema vivo. Enumera repositorios, servicios, contratos, datos, pipelines, código de infraestructura, entornos, cuentas, responsables de secretos, paneles, alertas, runbooks, dependencias de recuperación, centros de coste, proveedores, riesgos, excepciones y retiradas. Los accesos pasan por canales aprobados y el equipo receptor demuestra las operaciones acordadas. Nuevas oleadas, operación de plataforma, consumo cloud, monitorización, guardia, seguridad y producto continúan únicamente bajo un alcance escrito nuevo o vigente.