Para los administradores y operadores de TI, la decisión suele surgir de una presión medible: cargas de trabajo en estado estable que generan un gasto mensual desproporcionado, requisitos de cumplimiento cada vez más estrictos sobre la ubicación de los datos o limitaciones arquitectónicas causadas por servicios gestionados propietarios. Este manual recorre la migración en el orden en que suele desarrollarse en entornos de producción reales.
Todo empieza con los números
Antes de dibujar diagramas de arquitectura o planificar oleadas de migración, hay que validar los aspectos económicos. Una factura de nube pública debe desglosarse más allá del total principal. Los patrones de utilización de cómputo, el crecimiento del almacenamiento, el tráfico de salida y las primas por servicios gestionados deben analizarse a lo largo del tiempo.
El cambio de OpEx a CapEx requiere un modelado granular. Comparar una factura mensual de la nube con una compra única de hardware es engañoso. Un análisis adecuado incluye la depreciación del hardware, los contratos de soporte, las licencias, el consumo de energía, el espacio en rack, la refrigeración (PUE) y el personal. La infraestructura privada solo resulta económicamente viable cuando la automatización y la disciplina operativa evitan que los gastos operativos erosionen el ahorro.
Varios factores de coste suelen revelar dónde se encuentran las verdaderas oportunidades:
Auditoría de costes de salida. Los cargos por transferencia de datos de salida (DTO) pueden afectar significativamente al gasto total. Las aplicaciones de alto rendimiento, los sistemas distribuidos
o los servicios con fuertes dependencias de API externas suelen lograr un ROI más rápido cuando el tráfico se traslada al tránsito privado.La prima por servicio gestionado. Servicios como las bases de datos gestionadas
o las plataformas de Kubernetes agrupan la automatización, el mantenimiento y la comodidad en el precio. No se paga solo por el cómputo, se paga por la capa de abstracción operativa. La viabilidad de la nube privada depende de sustituir esa capa por automatización interna mediante herramientas como Ansible, Terraform o plataformas de orquestación dedicadas.
Amortización y densidad de infraestructura. Modele el coste por núcleo y por GB a lo largo de un ciclo de vida de hardware de tres a cinco años. Incluya la energía, la refrigeración y la densidad de rack (recuento de U). Compare esto cuidadosamente con los precios de vCPU de la nube pública, recordando que una vCPU a menudo representa un único hilo de ejecución (hyperthread) en lugar de un núcleo físico completo. Las cargas de trabajo estables y predecibles suelen favorecer la infraestructura privada porque la capacidad puede diseñarse una vez y amortizarse durante varios años.
Entender qué es lo que realmente ejecuta
Con el tiempo, los entornos de nube pública acumulan dependencias ocultas. En la superficie, la arquitectura puede parecer limpia. Por debajo, hay un estado operativo que rara vez aparece en los diagramas. Los grupos de seguridad evolucionan a través de cambios incrementales. Las cuentas de servicio permanecen vinculadas a scripts de automatización olvidados hace tiempo. Las instantáneas persisten mucho después de que se haya olvidado su propósito. Las instancias de bases de datos gestionadas conllevan políticas integradas para copias de seguridad, replicación, parches y conmutación por error.
Antes de que comience cualquier migración, esta capa oculta debe documentarse por completo. Los servicios gestionados son especialmente importantes de analizar. Una instancia de base de datos como servicio, por ejemplo, es mucho más que un simple punto final. Incluye comportamiento de conmutación por error automatizado, ciclos de parches programados, integraciones de monitorización, políticas de retención de copias de seguridad, topología de replicación y, a veces, reglas de escalado dinámico.
Si esas responsabilidades operativas no se reasignan y reconstruyen explícitamente en el nuevo entorno, la brecha suele aparecer durante un incidente, cuando los sistemas ya están bajo estrés. Muchos problemas de migración provienen de lo que puede llamarse dependencias fantasma: relaciones entre sistemas que existen pero no están claramente documentadas. Para descubrirlas, varias áreas requieren una investigación cuidadosa:
Mapeo de dependencias de aplicaciones. Analice los patrones de tráfico reales entre servicios utilizando herramientas como los registros de flujo (por ejemplo, VPC Flow Logs o NetFlow). Estos revelan rutas de comunicación que los diagramas de aplicaciones suelen omitir.
Sistemas de metadatos e identidad. Cada rol de IAM, cuenta de servicio y secreto debe catalogarse. Los modelos de IAM de la nube pública suelen estar vinculados a servicios de metadatos propietarios, como los puntos finales de metadatos de instancia utilizados para la inyección de credenciales. Estos mecanismos deben sustituirse, emularse o rediseñarse en un entorno privado.
Cargas de trabajo con estado frente a cargas de trabajo sin estado. Las dependencias de almacenamiento también necesitan un análisis cuidadoso. Algunas cargas de trabajo dependen de sistemas de instantáneas propietarios o de niveles específicos de IOPS aprovisionados. Durante la migración, estas capacidades deben mapearse a plataformas de almacenamiento equivalentes como NVMe-over-Fabrics o sistemas distribuidos como Ceph.
Redefinir qué significa “nube privada”
Un clúster virtualizado por sí solo no constituye una nube privada. Sin aprovisionamiento impulsado por API, redes definidas por software, automatización del ciclo de vida y observabilidad centralizada, el resultado es simplemente una pila de infraestructura tradicional con una complejidad adicional.
El objetivo real es preservar los principios operativos de la nube —autoservicio, automatización, repetibilidad y control programático— mientras se ejecuta en una infraestructura que usted posee y controla.
Aquí es donde las plataformas de orquestación adquieren importancia estratégica. Reconstruir la lógica de aprovisionamiento desde cero es costoso y lento. En su lugar, las organizaciones despliegan cada vez más capas de gestión de la nube que proporcionan un plano de control unificado para el cómputo, el almacenamiento y las redes. Plataformas como FishOS de Sardina Systems están diseñadas para este propósito, permitiendo a los operadores gestionar entornos privados con los mismos flujos de trabajo, automatización y coherencia operativa propios de la nube que esperan de las plataformas públicas.
Por lo tanto, una nube privada funcional requiere algo más que un clúster de hipervisores como KVM o ESXi. Para mantener la velocidad operativa, la infraestructura debe exponer una capa de infraestructura programática. Varias capacidades definen este modelo:
Un plano de control centralizado. Una capa de orquestación proporciona gestión del ciclo de vida impulsada por API para el cómputo, las redes y el almacenamiento. Las plataformas basadas en tecnologías como OpenStack y Kubernetes permiten a los operadores gestionar la infraestructura como un sistema cohesivo en lugar de como
una colección de hosts.Aprovisionamiento de autoservicio. La infraestructura debe poder consumirse a través de API, herramientas de CLI o flujos de trabajo automatizados. Si los ingenieros deben abrir tickets para aprovisionar una VM o configurar una red, el entorno se comporta como la TI tradicional en lugar de como una nube privada.
Paridad de abstracción con los flujos de trabajo de la nube pública. La plataforma privada debe admitir las mismas herramientas de infraestructura como código utilizadas en entornos nativos de la nube. La compatibilidad con herramientas como los proveedores de Terraform permite a los equipos reutilizar los canales de CI/CD y los flujos de trabajo de automatización sin necesidad de una refactorización exhaustiva.
Re-arquitectura de redes definidas por software (SDN)
La red suele ser la parte más subestimada de una migración a la nube. Las plataformas de nube pública abstraen muchas complejidades de red subyacentes, ocultando al usuario detalles como el enrutamiento BGP, la segmentación de VLAN y las redes superpuestas (overlay). Cuando las cargas de trabajo se trasladan a una infraestructura privada, esas abstracciones deben reconstruirse y diseñarse explícitamente.
Los constructos de la nube, como los grupos de seguridad, los equilibradores de carga gestionados y las IP elásticas, no pueden simplemente copiarse a un nuevo entorno. Deben traducirse en componentes de red físicos y definidos por software. Los planes de direccionamiento IP a menudo necesitan una reestructuración, las reglas de firewall requieren auditoría y racionalización, y los flujos de tráfico deben rediseñarse para la nueva topología.
Arquitectura de red y límites de enrutamiento. Las redes de nube pública suelen funcionar como entornos VPC relativamente planos. En un centro de datos privado, los equipos deben diseñar ellos mismos la arquitectura subyacente. Esto incluye con frecuencia la creación de una topología leaf-spine, la implementación de BGP EVPN para la movilidad de la carga de trabajo y la gestión de configuraciones de MTU como tramas jumbo para evitar problemas de fragmentación y rendimiento.
Equilibrio de carga. Los equilibradores de carga gestionados en las nubes públicas (como los equivalentes de ALB o ELB) deben sustituirse por dispositivos de hardware o alternativas definidas por software. Dependiendo de la arquitectura, esto podría incluir plataformas como F5, NetScaler, HAProxy, MetalLB u OpenStack Octavia.
Traducción del modelo de seguridad. Los grupos de seguridad en la nube proporcionan un filtrado de tráfico flexible a nivel de instancia. En entornos privados, estas políticas deben traducirse en modelos de firewall distribuidos o mecanismos de aplicación basados en el host. Tecnologías como los firewalls distribuidos o las políticas basadas en eBPF pueden preservar un enfoque de confianza cero (zero-trust) sin depender totalmente de los firewalls perimetrales tradicionales.
Automatización operativa. La complejidad de la red disminuye significativamente cuando se automatiza la configuración. Los marcos de infraestructura como código permiten que el aprovisionamiento de red, las reglas de firewall y las políticas de enrutamiento tengan control de versiones en lugar de gestionarse mediante tickets manuales. Este enfoque mejora la coherencia y reduce la fricción de la migración.
Durante las transiciones de migración, servicios como la terminación TLS, la propagación de DNS y el enrutamiento de entrada suelen convertirse en cuellos de botella críticos. Lo que antes se gestionaba tras las abstracciones del proveedor ahora requiere una planificación e ingeniería cuidadosas.
En la práctica, las migraciones exitosas no tratan la red como un componente de apoyo, sino como un rediseño arquitectónico central.
Diseñar el almacenamiento en lugar de seleccionarlo
En la nube pública, el rendimiento del almacenamiento suele elegirse entre niveles predefinidos. En una nube privada, debe diseñarse. Lo que antes era una opción de configuración se convierte en una responsabilidad arquitectónica.
Por lo tanto, la evaluación comparativa de la carga de trabajo es esencial. Las bases de datos, las plataformas de análisis y otros sistemas con un uso intensivo de E/S deben probarse en condiciones realistas de concurrencia y rendimiento. Las mediciones de referencia ayudan a determinar si la infraestructura subyacente puede sostener las cargas de trabajo de producción a lo largo del tiempo. Varios factores técnicos desempeñan un papel central en el diseño de una capa de almacenamiento fiable.
Evaluación comparativa del rendimiento. Antes de desplegar las cargas de trabajo, los equipos deben establecer métricas de referencia claras para la latencia y el rendimiento. Se pueden utilizar herramientas como fio o vdbench para validar las capacidades de las matrices físicas, los dispositivos NVMe o los clústeres de almacenamiento distribuido en condiciones de carga realistas.
Compatibilidad con almacenamiento de objetos. Las aplicaciones diseñadas en torno a API compatibles con S3 requieren una capa de almacenamiento de objetos local que replique esta interfaz. Sistemas como Ceph RGW o MinIO pueden proporcionar compatibilidad con S3, pero también debe considerarse el modelo de coherencia. Algunas aplicaciones dependen de garantías de coherencia fuerte, mientras que otras están diseñadas para modelos de coherencia eventual.
Localización de datos y diseño de arquitectura. La arquitectura de almacenamiento debe alinearse con las características de la carga de trabajo. Los sistemas con gran carga de cómputo pueden beneficiarse de una infraestructura hiperconvergente donde los recursos de almacenamiento y cómputo escalan juntos. Por otro lado, las cargas de trabajo con uso intensivo de E/S pueden funcionar mejor con sistemas SAN o NAS dedicados diseñados para un rendimiento sostenido.
Las estrategias de instantáneas y replicación también deben alinearse con los objetivos de recuperación operativa. Las ventanas de copia de seguridad, los objetivos de punto de recuperación (RPO) y los objetivos de tiempo de recuperación (RTO) deben validarse en condiciones de fallo simuladas.
Uno de los retos de las migraciones de almacenamiento es que los problemas rara vez aparecen de inmediato. Los sistemas pueden funcionar con normalidad durante la transición inicial, pero empezar a degradarse semanas después bajo una carga de producción sostenida. Por este motivo, la validación del almacenamiento no puede ser superficial.
Observabilidad: De cuadros de mando gestionados a telemetría de pila completa
Los entornos de nube pública proporcionan canales de monitorización y observabilidad profundamente integrados. Las métricas, los registros, las alertas y las señales de estado del proveedor están disponibles por defecto. Cuando las cargas de trabajo se trasladan a una infraestructura privada, estas capacidades deben diseñarse e implementarse deliberadamente. Por esta razón, las organizaciones que migran desde la nube pública suelen buscar plataformas que ofrezcan algo más que máquinas virtuales. La monitorización integrada y la visibilidad del estado, como la monitorización del estado de la infraestructura en plataformas como FishOS, ayudan a mantener la transparencia operativa sin tener que reconstruir toda la pila de observabilidad desde cero.
La observabilidad debe extenderse mucho más allá de la capa de aplicación. En una nube privada, la visibilidad operativa incluye el estado de los hipervisores, la latencia de almacenamiento, el rendimiento de la red e incluso los componentes físicos del hardware. Las señales que antes gestionaba el proveedor pasan a formar parte de la responsabilidad operativa. Construir esta visibilidad requiere una arquitectura de telemetría integral.
La pila de telemetría. Los entornos modernos suelen implementar un canal de observabilidad basado en estándares abiertos. OpenTelemetry puede servir de base para recopilar y exportar datos de telemetría, mientras que plataformas como Prometheus y Grafana proporcionan monitorización y visualización de series temporales. La agregación de registros puede gestionarse a través de pilas centralizadas como ELK o EFK.
Señales a nivel de hardware. En los entornos de nube pública, los fallos de hardware son invisibles para el cliente. En un entorno privado, estas señales deben monitorizarse directamente. La integración de alertas IPMI o SNMP permite a los operadores detectar problemas como fallos en los ventiladores, fallos en la fuente de alimentación o errores de memoria ECC antes de que afecten a las cargas de trabajo.
Previsión de capacidad. La planificación de la capacidad también cambia fundamentalmente. En los entornos de nube pública, quedarse sin recursos suele traducirse en mayores costes de uso. En la infraestructura privada, se convierte en un reto de adquisición y planificación. La monitorización predictiva de la capacidad puede identificar tendencias en la utilización de cómputo, almacenamiento y red, y activar flujos de trabajo de adquisición de hardware meses antes de que se alcancen los límites de capacidad.
Aunque las plataformas de automatización pueden centralizar la telemetría y simplificar la monitorización, las herramientas por sí solas no garantizan la resiliencia operativa. La fatiga por alertas, los umbrales mal definidos y los procedimientos de escalado poco claros pueden socavar incluso los sistemas bien diseñados.
Mover cargas de trabajo sin crear ondas de choque
Las migraciones más seguras se realizan de forma incremental. En lugar de moverlo todo a la vez, las organizaciones empiezan con cargas de trabajo no críticas. Estas migraciones tempranas permiten a los equipos validar el rendimiento, la monitorización, los procedimientos de copia de seguridad y los procesos operativos en el nuevo entorno antes de introducir sistemas más complejos.
Una vez que la plataforma demuestra ser estable, los servicios con estado y las cargas de trabajo de misión crítica pueden transicionar con un riesgo significativamente menor. Este enfoque por fases reduce las sorpresas operativas y da tiempo para corregir problemas antes de que afecten a los sistemas empresariales centrales.
No todas las aplicaciones requieren la misma estrategia de migración. Algunas cargas de trabajo heredadas pueden trasladarse rápidamente con cambios mínimos, mientras que otras se benefician de ajustes arquitectónicos más profundos. La clave es categorizar las cargas de trabajo en función de sus dependencias, complejidad y valor a largo plazo.
Un marco común para estructurar las migraciones es la estrategia de migración de las “6 R”, que ayuda a determinar la ruta más adecuada para cada sistema.
Rehost (reubicación o “lift and shift”). Las máquinas virtuales heredadas a menudo pueden migrarse con modificaciones mínimas. Herramientas como virt-v2v ayudan a convertir y transferir máquinas virtuales a una nueva plataforma de virtualización o nube, lo que permite a las organizaciones mover cargas de trabajo rápidamente preservando su arquitectura existente.
Replatform (cambio de plataforma). Las aplicaciones que ya están contenedorizadas pueden beneficiarse del traslado a una plataforma Kubernetes estandarizada en el entorno privado. Las plataformas gestionadas a través de capas de orquestación como FishOS permiten a los equipos mantener flujos de trabajo de despliegue coherentes mientras operan en una infraestructura propia.
Refactor (refactorización). En algunos casos, las aplicaciones dependen en gran medida de servicios propietarios como bases de datos gestionadas, colas o plataformas sin servidor. La refactorización de estas aplicaciones puede eliminar las dependencias a largo plazo de servicios específicos de un proveedor y proporcionar una mayor flexibilidad arquitectónica.
Repurchase (recompra), a veces llamado “drop and shop”, consiste en sustituir una aplicación existente por un nuevo producto o servicio. Por ejemplo, las organizaciones que utilizan servidores de correo electrónico heredados o sistemas CRM obsoletos en la nube pueden encontrar más práctico adoptar una solución SaaS moderna en lugar de recrear el servicio en un entorno privado. Esto permite a los equipos de ingeniería centrar el esfuerzo operativo en la infraestructura que soporta directamente las cargas de trabajo principales.
Retire (retirada) se refiere a identificar y desmantelar sistemas que ya no están en uso. Los proyectos de migración suelen revelar cargas de trabajo olvidadas o inactivas que consumen recursos sin aportar valor. Eliminar estos sistemas “zombis” puede reducir significativamente el alcance de un proyecto de migración —a veces entre un 10 y un 20 %— a la vez que libera espacio en rack, energía y capacidad de refrigeración en el entorno de destino.
Retain (retención) describe las cargas de trabajo que permanecen intencionadamente en su entorno actual. En muchos casos, un modelo híbrido tiene sentido práctico. Las aplicaciones con una demanda muy impredecible o estacional —como los servicios que experimentan picos extremos de tráfico una vez al año— pueden seguir siendo más rentables en plataformas de nube pública en lugar de obligar a las organizaciones a construir una infraestructura que permanece inactiva la mayor parte del tiempo.
El principio rector durante todo el proceso de migración sigue siendo el mismo: reducir las incógnitas antes de aumentar el alcance. Al validar cada etapa de la migración antes de ampliarla, las organizaciones pueden mover las cargas de trabajo sin crear ondas de choque operativas.
Aceptar el retorno de la responsabilidad
Quizás el cambio más significativo al pasar de la nube pública a la privada es el retorno de la propiedad operativa. En los entornos públicos, gran parte de la carga operativa se abstrae tras los servicios gestionados y los SLA del proveedor. En la nube privada, los calendarios de parches, la planificación del ciclo de vida del hardware, la validación de las copias de seguridad, la previsión de la capacidad y los procedimientos de respuesta ante fallos deben definirse y asignarse explícitamente. La ambigüedad en la responsabilidad se convierte en un riesgo de producción medible. Este es el momento en que se pone a prueba la madurez de la organización. Los modelos de propiedad claros, los manuales de procedimientos documentados y las rutas de escalado probadas ya no son opcionales.
Para facilitar esta transición, las organizaciones suelen confiar en plataformas unificadas de gestión de la nube que consolidan la automatización del ciclo de vida, el gobierno y el aprovisionamiento en un marco operativo coherente. Soluciones como FishOS de Sardina Systems están diseñadas específicamente para ayudar a los equipos a operar infraestructuras privadas con un control similar al de la nube, aplicación de políticas y flujos de trabajo de automatización. En lugar de reconstruir la lógica operativa desde cero, los equipos pueden adoptar capas de orquestación estructuradas que reducen la fragmentación y refuerzan la repetibilidad en los dominios de cómputo, almacenamiento y redes.
Validar la recuperación ante desastres
La configuración de las copias de seguridad no es recuperación ante desastres. Los objetivos de recuperación deben ser medibles y estar probados. Los simulacros de restauración deben simular escenarios de fallo realistas. La replicación fuera del sitio debe validarse bajo restricciones de ancho de banda. Los plazos de conmutación por error deben observarse, no suponerse.
Una migración no puede considerarse completa hasta que los procedimientos de recuperación tengan éxito bajo pruebas controladas.
La nube pública optimiza la elasticidad, la abstracción y la experimentación rápida. La nube privada optimiza el control, la previsibilidad y la alineación de costes a largo plazo para cargas de trabajo estables.
La migración tiene éxito cuando la madurez de la automatización compensa la pérdida de los servicios gestionados por el proveedor. Fracasa cuando los equipos tratan la infraestructura privada como hardware estático en lugar de como un entorno programable.
Para los administradores y operadores de TI, el patrón es coherente en todas las organizaciones: inventariar rigurosamente, diseñar deliberadamente, automatizar pronto, migrar de forma incremental y validar continuamente. Cuando se ejecuta con una orquestación estructurada y disciplina operativa, una nube privada no es un retroceso respecto a la infraestructura moderna. Es una infraestructura de nube operada bajo sus propios términos.
La transición tiene éxito cuando la API es la fuente de verdad. Al utilizar una plataforma de orquestación como FishOS de Sardina Systems, los equipos de TI pueden automatizar el trabajo pesado del despliegue de OpenStack y Kubernetes, garantizando que la «nube privada» se sienta como una mejora funcional en lugar de una carga de mantenimiento.