Documentada
Baseline, evaluación de nube, red, seguridad, migración y 18 diagramas.
FRÍOANDES CLOUDOPS.
Modernización de una cadena de frío en Azure
Caso técnico de arquitectura CloudOps para migrar una operación logística ficticia desde VMware on-premises hacia una plataforma Azure híbrida, segura y trazable.
01 / CONTEXTO
La operación académica modela 8 centros regionales, 32 cuartos fríos, una flota de 120 a 180 camiones y 1,2 PB de evidencia histórica sobre infraestructura con componentes fuera de soporte.
02 / EL RETO
Diseñar una transición sin interrumpir el despacho de 04:00 a 22:00, con alertas de temperatura en menos de un minuto, un cutover máximo de dos horas y una base preparada para crecimiento multicloud.
03 / LA SOLUCIÓN
Se evaluaron Azure, AWS y GCP; Azure obtuvo la mayor puntuación preliminar por su integración con Entra ID, ADLS Gen2 y Microsoft Fabric. La arquitectura propone hub-and-spoke, red privada, telemetría por eventos y migración por coexistencia.
04 / MI TRABAJO
El material sustenta trabajo en baseline técnico, evaluación de proveedores, arquitectura de red y acceso, estrategia FinOps, diagramas y módulos Terraform reutilizables para red, seguridad y telemetría en DEV.
05 / PUNTOS CLAVE
- Plan DEV: 53 altas, 0 cambios, 0 destrucciones
- 8 subredes, 8 NSG y Event Hubs por Private Link
- 18 diagramas técnicos con fuentes editables y exportaciones verificadas
TRANSPARENCIA
Caso académico para una empresa ficticia. Hay diseño aprobado, código IaC y evidencia de plan; no hubo terraform apply ni despliegue productivo. La autoría individual completa no se infiere de los repositorios.
LECTURA HONESTA DEL ESTADO
De la propuesta al código, sin confundir etapas.
La documentación describe una modernización completa; el repositorio IaC implementa un alcance DEV menor y verificable. Esta página mantiene esa diferencia visible.
Implementada
Módulos Terraform para red, NSG y Event Hubs privado.
Plan-only
Formato, validate, plan y análisis Checkov registrados en el repositorio.
No desplegada
El README declara explícitamente que no se ejecutó terraform apply.
01 / BASELINE OPERATIVO
Una cadena de frío que no puede detenerse.
El caso parte de una operación nacional dependiente de un datacenter VMware en Cali, enlaces compartidos y procesamiento horario de telemetría. La arquitectura debía proteger el despacho mientras modernizaba datos, aplicaciones y operación.
02 / DECISIONES DE ARQUITECTURA
Azure como núcleo; portabilidad como restricción.
La elección no fue nominal: se ponderaron siete criterios entre Azure, AWS y GCP. Azure alcanzó 4,39/5 en la evaluación preliminar, principalmente por identidad unificada y afinidad de datos con Fabric.
Cloud principal
Azure obtuvo el mayor puntaje preliminar. GCP quedó como horizonte para cargas batch o stateless; la decisión final quedó condicionada a pruebas de latencia, licenciamiento y egress.
Red
Hub-and-spoke con ambientes segregados, tránsito híbrido central, inspección común y zonas funcionales para ingress, aplicación, datos, almacenamiento, telemetría y gestión.
Datos y telemetría
Event Hubs y Private Link como primer bloque implementado en IaC; IoT Hub, consumidores, captura histórica y alertamiento completo permanecen fuera del alcance actual.
Migración
Coexistencia propuesta de 90 días, limpieza previa del archivo, pre-seeding dedicado y cutover dominical con rollback. Es una estrategia, no una migración ejecutada.
03 / DIAGRAMAS AUTÉNTICOS
La arquitectura, a escala legible.
Exportaciones reales del repositorio de diagramas. Las copias públicas redactan rangos IP privados; pulsa cualquier lámina para ampliarla.
Baseline on-premises
Datacenter VMware, aplicaciones, datos, archivo y conectividad antes de la modernización.
Conectividad y seeding
Limpieza in situ, staging resiliente, canal dedicado y aterrizaje privado en Azure.
Telemetría en tiempo real
Ingesta desacoplada y enrutamiento de alertas diurnas y nocturnas en menos de un minuto como objetivo.
Arquitectura Azure objetivo
Vista integral del estado futuro: hub, spoke, datos, aplicaciones, telemetría y Fabric.
Flujo operativo futuro
Secuencia propuesta desde sensores y evidencia hasta alertamiento, almacenamiento y analítica.
04 / INFRAESTRUCTURA COMO CÓDIGO
Un spoke DEV reproducible y con límites explícitos.
El módulo environment compone network, security y telemetry. El código crea límites de red y un canal privado de ingesta; deliberadamente no crea hub, firewall, cómputo, base de datos, almacenamiento, Fabric ni IP pública.
infra/terraform
01environment/ — composición reutilizable02network/ — resource group, VNet y 8 subredes03security/ — 8 NSG, asociaciones y reglas deny-by-default04telemetry/ — Event Hubs, Private Endpoint y Private DNS05environments/dev/ — composición y valores de validación
Evidencia registrada
- Terraform 1.14.6 / AzureRM 4.81.0
- 53 altas · 0 cambios · 0 destrucciones
- 8 subredes · 8 NSG · 22 reglas explícitas
- Checkov: 115 aprobadas · 8 hallazgos documentados
- Sin estado, planes, credenciales ni outputs sensibles versionados
Los ocho hallazgos CKV2_AZURE_31 se documentaron como falsos positivos de análisis entre módulos y deben revisarse contra el grafo del plan; no se ocultaron con suppressions.
05 / SEGURIDAD, OPERACIÓN Y ENTREGA
Controles diseñados alrededor del riesgo operativo.
Red privada por defecto
Sin IP públicas en el IaC DEV; salida implícita deshabilitada, egress directo a Internet denegado y Event Hubs expuesto por Private Endpoint.
Identidad antes que secretos
Autenticación local/SAS deshabilitada para Event Hubs. El diseño propone Entra ID, RBAC, MFA, PIM, JIT y Bastion; esas capas aún no están desplegadas por este módulo.
Ventanas protegidas
El modelo bloquea cambios de producción de 04:00 a 22:00 y durante campañas. El cutover final se limita a una ventana dominical de dos horas.
Observabilidad por completar
El baseline identifica límites de Zabbix y plantea trazas, APM, métricas y alertas. La arquitectura de observabilidad dedicada figura como trabajo planificado.
CI / CD
Estrategia de entrega documentada
El roadmap define CI/CD, runners privados, plan sanitizado e Infracost como flujo objetivo. No se encontró un workflow ejecutable que pruebe despliegue automatizado del entorno.
- 01Formato + validate
- 02Plan sin apply
- 03Checkov + revisión
- 04Promoción con aprobación
06 / RESULTADO Y APRENDIZAJES
El resultado comprobable es una base revisable, no una nube en producción.
El caso produjo una baseline trazable, una evaluación de proveedores, documentación de red y seguridad, una estrategia de migración y FinOps, fuentes editables de diagramas y un módulo Terraform capaz de generar un plan DEV create-only.
Arquitectura
Separar el target completo del incremento que realmente puede validarse evita que el diagrama se convierta en una promesa falsa.
FinOps
Mover datos no empieza por elegir un tier: empieza por retención, limpieza, ancho de banda y evidencia de costos todavía provisional.
DevSecOps
Una validación segura debe producir evidencia reproducible sin exponer planes, IDs de suscripción o secretos.
Mi contribución, acotada por la evidencia
Presento como trabajo sustentado el análisis del caso, la organización de decisiones, la documentación técnica, los diagramas y la construcción/revisión del IaC. Los repositorios no permiten atribuir a una sola persona todo el programa ni demostrar operación en producción, por lo que no hago esas afirmaciones.
Pendiente antes de un despliegue real
- Aprobar región, naming, tags y backend remoto
- Resolver hub, peering, UDR y DNS híbrido
- Seleccionar cómputo e ingress
- Completar RBAC, diagnósticos y observabilidad
- Validar Fabric, costos e Infracost
- Ejecutar revisión humana y aplicar bajo cambio aprobado
05 / CONTACTO
DISPONIBLE PARA CONVERSAR
TU IDEA.
NUESTRO SIGUIENTE
PROYECTO.
¿Tienes un producto por construir o buscas a alguien para tu equipo? Conversemos.