Hola a tod@s,
En los últimos artículos he hablado de cómo escalar Azure Local:
- Multi‑Rack
- Arquitecturas desagregadas
Pero hoy vamos a ir un paso más allá.
Porque hay una pregunta que no solemos hacernos… hasta que es demasiado tarde:
¿Qué pasa cuando no podemos conectarnos a Azure?
No es que no queramos…
Es que directamente no podemos.
Y aquí es donde entra uno de los conceptos más potentes (y menos entendidos) de Azure Local:
Operaciones Desconectadas Cuando el cloud no puede depender del cloud
El problema real: no todo el mundo puede usar la nube
Estamos acostumbrados a pensar que toda gira en torno a la conectividad.
Pero en muchos entornos eso no aplica:
- Entornos regulados (banca, gobierno, defensa)
- Infraestructuras críticas
- Localizaciones remotas (fábricas, barcos, minería…)
- Redes aisladas (air‑gapped)
En estos escenarios:
- No hay conexión a Internet.
- No se permite enviar datos fuera.
- No hay dependencia de servicios externos
Y aun así…Necesitamos operar como si estuviéremos en Azure
¿Qué son realmente las operaciones desconectadas?
Azure Local nos permite ejecutar infraestructura sin conexión al cloud público de Azure, manteniendo capacidades cloud dentro de nuestro datacenter.
Dicho de otra forma:
Azure Local crea un plano de control local completo
Con esto podemos:
- Desplegar máquinas virtuales
- Ejecutar contenedores
- Gestionar recursos (ARM, RBAC, etc.)
- Mantener experiencia tipo Azure Portal / CLI
Todo sin salir de nuestro entorno.
Importante:
El control, los datos y las operaciones se quedan dentro de nuestra organización
Esto cambia completamente el concepto de “Hybrid Cloud”
Hasta ahora, el modelo era:
¿Y qué pasa cuando vuelve la conexión?
Esto es clave.
Azure Local no deja de ser híbrido — solo que es autónomo cuando lo necesita.
Cuando hay conectividad:
- Se sincronizan datos y métricas
- Se reporta uso (billing)
- Se alinean configuraciones
Pero durante la desconexión:
- Todo sigue funcionando.
- Sin degradación.
- Sin dependencia externa
Casos reales donde esto tiene sentido
Aquí es donde deja de ser teoría:
1. Entornos soberanos.
- Gobierno.
- Defensa.
- Infraestructuras críticas.
Los datos no pueden salir
2. Industria y Edge.
- Fábricas.
- Plantas industriales.
- Retail distribuido.
La conectividad es limitada o inestable
3. Entornos aislados
- Barcos.
- Plataformas petrolíferas.
- Instalaciones offshore.
Internet no es fiable (o no existe)
4. Seguridad extrema
- Redes aisladas (air‑gapped)
Menor superficie de ataque al no exponer sistemas.
Lo que nadie nos cuenta (la parte importante)
Esto no es “activar un checkbox”.
Tiene impacto real en diseño:
1. Necesitamos más infraestructura
- El plano de control vive en local
- Más capacidad = más recursos
2. Identity pasa a ser local
- Active Directory obligatorio
- ADFS en algunos escenarios
3. PKI es crítica
- Certificados internos
- CRL accesible
4. Networking bien diseñado
- DNS interno
- NTP
- Segmentación
En resumen:
Estamos construyendo nuestro propio “mini Azure” dentro de nuestro datacenter
Mi punto de vista (experiencia real)
Aquí va la parte que marca la diferencia.
Operaciones desconectadas no es para todos.
Pero cuando encaja…
Es probablemente uno de los modelos más potentes de Azure Local
Porque combina:
- Control total (Onpremise).
- Experiencia cloud.
- Independencia real.
Y esto resuelve uno de los mayores problemas actuales:
Cómo llevar el modelo cloud… donde el cloud no puede llegar
Conclusión
Azure Local sigue evolucionando… pero este feature en concreto es un salto enorme.
Ya no estamos hablando de híbrido.
Estamos hablando de:
- Cloud soberano.
- Cloud autónomo.
- Cloud sin cloud.
Y eso cambia completamente las reglas del juego.
Ya sabemos que es Azure Local operaciones desconectadas o en modo desconectado, cada dia que pasa cada dia me está gustando más Azure Local, nos vemos en el proximo articulo
Saludos.