Una conversación sobre mover una carga a la nube suele comenzar por una solución y no por el problema. Se habla de infraestructura, servicios administrados o centros de datos antes de aclarar qué necesita ejecutar el sistema, qué límites impone su contexto y quién atenderá cada responsabilidad. Sin esa distinción, la decisión queda apoyada en supuestos generales que no describen la carga concreta.
Precisar qué significa nube en la decisión
NIST define la computación en nube como un modelo de acceso de red bajo demanda a un conjunto compartido de recursos configurables, que pueden aprovisionarse y liberarse con rapidez y poco esfuerzo de gestión (SP 800-145). La definición distingue características esenciales, modelos de servicio y modelos de despliegue. Sirve para fijar vocabulario, pero no determina si una carga particular debe migrarse ni cuál alternativa satisface mejor sus condiciones.
Como criterio de trabajo, describa la unidad que se está evaluando: una aplicación, un componente, una base de datos o un entorno completo. Anote sus dependencias, datos tratados, usuarios, integraciones y necesidades de operación. “Ir a la nube” puede referirse a arquitecturas distintas; nombrar el modelo de servicio y el alcance evita comparar una máquina virtual con una plataforma administrada como si fueran opciones idénticas.
Separar requisitos de preferencias
Una ficha de decisión puede organizar los requisitos en preguntas observables. ¿Qué comportamiento debe conservarse? ¿Qué datos y flujos deben protegerse? ¿Qué integraciones dependen de redes o sistemas existentes? ¿Qué capacidades de administración y recuperación son necesarias? ¿Qué restricciones regulatorias o contractuales aplican y quién puede confirmarlas?
Distinga cada respuesta según su origen: requisito aprobado, restricción externa, observación técnica o hipótesis pendiente. No convierta una preferencia —por ejemplo, reducir tareas de infraestructura— en una conclusión de costo o seguridad. Los gastos y los riesgos dependen del diseño, consumo, contratos, operación y capacidades del equipo; deben analizarse para el caso propio con datos vigentes y fuentes adecuadas.
Ejemplo hipotético: un equipo evalúa alojar una aplicación interna fuera de su entorno actual. Antes de proponer una plataforma, registra qué sistemas deben intercambiar datos, quién necesita administrar accesos, cómo se prueba una restauración y qué reglas de residencia de datos deben confirmar sus responsables. Este ejemplo ilustra un proceso de preguntas; no describe una organización ni resuelve una evaluación legal.
Aclarar la responsabilidad compartida
El modelo de responsabilidad compartida indica que parte de las tareas corresponde al proveedor del servicio y parte a quien lo configura y utiliza. Las páginas oficiales de AWS y Microsoft explican que la distribución varía según el servicio o modelo consumido; no se deriva de una etiqueta general de “nube” (AWS, Microsoft). La matriz específica debe contrastarse con documentación, contratos y controles aplicables a la carga.
Como criterio de trabajo, convierta esa matriz en una tabla operativa: control o tarea, responsable, evidencia esperada, proceso de escalamiento y dependencia. Separe la infraestructura que administra un proveedor de las decisiones que conserva el equipo, como la clasificación de sus datos, las identidades, los permisos y la configuración de componentes bajo su control. El detalle puede cambiar entre servicios, incluso dentro de un mismo entorno.
Esta revisión no traslada la responsabilidad integral de una organización a una plataforma. Tampoco demuestra que una arquitectura sea segura por el solo hecho de utilizar recursos administrados. Es necesario verificar qué control se ofrece, cuál debe configurarse, quién lo prueba y qué evidencia queda disponible.
Incluir configuración y operación
La metodología Twelve-Factor propone mantener la configuración que varía entre despliegues fuera del código, por ejemplo en variables de entorno (Config). Esta separación permite revisar cómo se suministran valores por entorno sin incorporar credenciales al repositorio. No basta con elegir una tecnología: hay que definir quién entrega, rota y protege cada valor, y cómo se evita exponerlo en registros, diagnósticos o copias.
Documente además observabilidad, respuesta a fallos, copias de seguridad, restauración, actualizaciones, administración de identidades y salida o cambio de servicio. Estas tareas pueden involucrar equipos distintos. Ponga a prueba los supuestos con una carga representativa y un plan de reversión o transición, de acuerdo con las capacidades disponibles. La prueba no sustituye un análisis de riesgos, pero ayuda a encontrar dependencias omitidas antes de comprometer la operación.
Registrar una decisión revisable
Una decisión breve debería señalar alcance, alternativas consideradas, requisitos que las comparan, responsables, evidencias, incertidumbres y condiciones para reevaluar. Evite declarar que una opción es más económica o más segura sin una comparación medible, definida y pertinente. Si un requisito crítico continúa sin validar, regístrelo como pendiente y determine quién puede resolverlo antes de ampliar el cambio.
El criterio no es adoptar una forma de infraestructura por tendencia. Se trata de hacer coincidir necesidades de la carga, restricciones confirmadas y responsabilidades que el equipo puede sostener. La respuesta depende del contexto técnico y organizativo, del modelo de servicio y de las obligaciones concretas.
| Dimensión | Pregunta | Evidencia | Dueño | Límite |
|---|---|---|---|---|
| Datos | Qué se almacena | Inventario | Equipo | Reglas por validar |
| Acceso | Quién administra permisos | Registro | Responsable | Excepciones |
| Config | Qué varía | Mapa | Desarrollo | Dependencias |
| Continuidad | Cómo se restaura | Prueba | Operación | Casos no ensayados |
Ejemplo hipotético de nombres de configuración, no valores ejecutables:
APP_ENDPOINT=<valor-proporcionado-por-entorno>
APP_REGION=<region-validada-por-el-equipo>
APP_LOG_LEVEL=<nivel-aprobado-para-el-entorno>
APP_FEATURE_MODE=<modo-explicito-de-ejecucion>
Qué no cubre este artículo
Esta nota no recomienda un proveedor, no compara precios y no constituye asesoría legal ni una evaluación de seguridad. La definición general y los modelos de responsabilidad deben contrastarse con el servicio, contrato, región y requisitos aplicables al caso.
