3.11 Arquitectura en la nube

Visión general y motivación

La computación en la nube consiste en alquilar la infraestructura de otros a demanda, a través de una red, pagar por lo que se utiliza y liberarlo cuando se termina. La arquitectura en la nube es la disciplina de diseñar sistemas que tratan esos recursos alquilados como su hábitat natural y no como una copia arrendada del antiguo centro de datos. Esa distinción es, en esencia, el corazón de este capítulo. Es posible trasladar una aplicación heredada a un proveedor de la nube sin cambiar nada en su diseño, y el resultado será una factura más cara y prácticamente la misma fragilidad. Pero también es posible diseñar para la nube y así obtener elasticidad, servicios gestionados que eliminan categorías enteras de trabajo de plomería, y la capacidad de resistir la caída de un edificio entero sin tener que llamar a nadie. Este capítulo se apoya directamente en los fundamentos del capítulo 3.1: la arquitectura en la nube es arquitectura, con las mismas compensaciones y los mismos atributos de calidad, aplicada a un sustrato que no es propio.

En los grandes equipos, las apuestas son más altas porque la nube reconfigura quién hace qué. Cuando un equipo puede aprovisionar una base de datos, una cola y un balanceador de cargas global en cuestión de minutos, el cuello de botella ya no es la compra, sino la gobernanza: el costo, la seguridad y la coherencia entre decenas de equipos que hacen exactamente eso al mismo tiempo. La nube entrega a cada ingeniero una tarjeta de crédito corporativa y acceso a un arsenal de herramientas profesionales: una maravilla y un peligro en igual medida. Lograr una buena arquitectura consiste en aprovechar las ganancias (velocidad, elasticidad, resiliencia) e instalar a la vez los controles que mantienen el gasto, la postura de seguridad y la residencia de los datos bajo control.

Las empresas y los gobiernos sienten ambos extremos con particular intensidad. Las empresas llegan con décadas de sistemas existentes, así que su historia con la nube suele ser una historia de migración, llena de conectividad híbrida y difíciles decisiones de comprar frente a construir. Los gobiernos cargan además con la soberanía, los regímenes de autorización y los datos de los ciudadanos que legalmente no pueden cruzar ciertas fronteras. Las decisiones que se toman aquí (qué modelo de servicio, cuántos proveedores, dónde sitúan los dominios de fallo, qué corre como servicio gestionado y qué como código propio) determinan el costo y el riesgo durante una década.

Principios fundamentales

Diseñar para la nube, no fotografiar el centro de datos. La elasticidad, los servicios gestionados y la conciencia de los dominios de fallo son las razones de estar aquí; un traslado directo sin cambios las desperdicia.
Todo se aprovisiona como código. Si una persona lo crea haciendo clic, es incatalogable, irreproducible e inauditable.
Diseñar entre dominios de fallo de forma deliberada. Las regiones, las zonas de disponibilidad y los servicios fallan; la arquitectura decide si eso es un encogimiento de hombros o una interrupción del servicio.
El modelo de responsabilidad compartida es un contrato, no un eslogan. Saber exactamente dónde termina la seguridad del proveedor y dónde empieza la propia.
Comprar lo genérico, construir lo diferenciador. Los servicios gestionados valen una inversión real por la plomería; el verdadero valor competitivo debe quedarse en manos propias.
El acoplamiento al proveedor es un costo a cuantificar, no un pecado a evitar. La portabilidad tiene su precio y la dependencia tiene su valor; decidir de forma consciente, no por reflejo.
El costo es un atributo de calidad de primera clase. En la nube, la arquitectura y la factura son la misma decisión.

Recomendaciones

Elegir el modelo de servicio de forma deliberada, con la gestión como punto de partida

Los proveedores de la nube ofrecen un espectro que se captura en los modelos como servicio: la Infraestructura como Servicio (IaaS) alquila cómputo, almacenamiento y red en bruto; la Plataforma como Servicio (PaaS) alquila un entorno de ejecución gestionado para desplegar código sin atender servidores; el Software como Servicio (SaaS) alquila aplicaciones terminadas. La computación serverless, que incluye funciones y servicios gestionados orientados a eventos, empuja el espectro más allá: se entrega código o configuración y el proveedor se encarga de todo el aprovisionamiento, escalandose hasta cero en reposo. Cada paso hacia arriba en el espectro intercambia control por palancamiento, desde el IaaS, que ofrece el máximo control y la mayor carga operativa, hasta el serverless, que reduce ambos al mínimo.

La opción por defecto debe ser subir lo más alto posible en ese espectro que lo permitan los requisitos. Una base de datos gestionada que se encarga de la parcheo, las copias de seguridad, el conmutado y la escalación casi siempre es un uso más productivo del equipo que una autoadministrada. Reservar un nivel IaaS más bajo para los casos que genuinamente lo necesiten: hardware especializado, límites de cumplimiento inusuales, restricciones de licencias o un rendimiento que la oferta gestionada no logra cubrir. Documentar la razón en un registro de decisión de arquitectura (capítulo 3.1), porque «nosotros operamos nuestro propio servidor de mensajes» es una afirmación que debería justificarse de nuevo cada año.

Diseñar entre regiones y zonas de disponibilidad como dominios de fallo explícitos

Una región en la nube es un área geográfica; dentro de ella, las zonas de disponibilidad son centros de datos físicamente separados con alimentación, refrigeración y red independientes, lo suficientemente cercanos para una replicación de baja latencia pero lo bastante alejados para que la caída de uno no afecte a los demás. Esas son las grietas por donde se quiebra la nube, y la arquitectura debe tratarlas como elementos de primera clase. El estándar mínimo para cualquier carga de trabajo seria es la multizona: distribuir cómputo y datos en al menos dos, idealmente tres, zonas de modo que la pérdida de una degrade la capacidad en lugar de provocar una interrupción. Es un seguro barato y raramente hay una buena razón para omitirlo.

La multi-región es una decisión más grave, atada a los objetivos de resiliencia y recuperación (capítulo 3.5) y al plan de recuperación ante desastres (capítulo 9.5). Desplegar en varias regiones permite sobrevivir a la caída de una región entera y acercar los datos a los usuarios, pero introduce problemas reales de costo, latencia y consistencia, porque la replicación síncrona entre regiones es lenta y la asíncrona significa aceptar la pérdida de datos en un conmutado. Decidir en función de objetivos de tiempo de recuperación y puntos de recuperación explícitos, no de un deseo vago de ser «muy disponible». La mayoría de los sistemas necesitan una sólida multi-zona y una ruta de recuperación entre regiones probada; pocos requieren realmente un activo-activo entre regiones, y quienes lo construyen sin necesidad pagan el precio de la complejidad todos los días.

Tratar el modelo de responsabilidad compartida como un límite arquitectónico

La seguridad en la nube funciona bajo un modelo de responsabilidad compartida: el proveedor protege la nube (las instalaciones físicas, el hipervisor, el interior de los servicios gestionados) y cada organización protege lo que pone en la nube (sus datos, los controles de acceso, la configuración de red y su código). Esa línea se desplaza a medida que se sube en el espectro de servicios. Con IaaS se actualiza el sistema operativo; con una base de datos gestionada no, pero sí se es responsable de quién puede conectar y de si los datos están cifrados. Los incidentes más caros provienen de malinterpretar esa línea, y el caso más célebre es el depósito de almacenamiento público que filtra millones de registros porque alguien asumió que el proveedor lo ponía privado por defecto.

Dejar explícito ese límite en los diseños y detallarlo en el capítulo 4.3, que aborda la seguridad de infraestructura y de la nube en profundidad. En términos de arquitectura, los mandatos son constantes: cifrar los datos en reposo y en tránsito por defecto, conceder el menor privilegio posible a través de la identidad en lugar de la posición en la red, mantener el alcance de daño de cualquier credencial individual al mínimo y partir del supuesto de que cualquier recurso accesible desde internet será inspeccionado en cuestión de minutos. Incorporar todo eso en la zona de aterrizaje para que cada equipo lo herede.

Aprovisionar todo como código, dentro de una zona de aterrizaje gobernada

En una práctica madura con la nube, ningún recurso de producción existe porque alguien hizo clic en una consola. Todo se declara en infraestructura como código (capítulo 8.2), se controla con un sistema de versiones, se revisa y se aplica a través de una canalización, de modo que la infraestructura sea reproducible, auditable y comparable. Es lo que hace reales en lugar de aspiracionales la multi-zona, la multi-región y la recuperación ante desastres: se puede levantar un entorno idéntico en una región nueva porque el entorno es un programa, no un recuerdo.

Envolver ese código en una zona de aterrizaje: una base preconfigurada y gobernada de cuentas (o suscripciones o proyectos), red, identidad, registro y controles que cada equipo usa como punto de partida. Usar cuentas separadas como límites de alcance de daño y de facturación, para que el error de un equipo no alcance los datos de otro y cada centavo tenga un responsable. Aplicar los controles como política como código que impida configuraciones prohibidas (una base de datos pública, un volumen sin cifrar, un recurso en una región no permitida), en lugar de depender de una revisión a posteriori. Normalmente un equipo central de plataforma es propietario de la zona de aterrizaje, conectando este capítulo con la ingeniería de plataforma (capítulo 8.4) y con los contenedores y entornos de ejecución nativos de la nube (capítulo 8.3).

Cuantificar el acoplamiento con honestidad y desconfiar del multinube

El acoplamiento al proveedor es el costo de cambiar de proveedor, y es un espectro, no un estado binario. Usar la cola gestionada de un proveedor crea algo de acoplamiento; usar su plataforma propietaria de aprendizaje automático, mucho. El miedo reflejo a ese acoplamiento empuja a los equipos a sacrificar un palancamiento real (los servicios gestionados que hacen que la nube valga la pena) por conservar una portabilidad que nunca ejercerán. Lo honesto es ponerle precio: para cada dependencia significativa, estimar cuánto costaría realmente irse y sopesarlo contra lo que el servicio ahorra en este momento. Abstraer un servicio gestionado para mantener la portabilidad suele costar más, de forma permanente, que la migración contra la que se está asegurando jamás se materializaría.

Por eso el multinube genuino (ejecutar la misma carga de trabajo en dos proveedores) suele ser un culto a la carga más que una estrategia. Obliga a bajar al denominador común más bajo, duplica la superficie operativa y multiplica las competencias que los equipos deben mantener, todo para cubrir un riesgo que rara vez ocurre. Hay razones legítimas para tocar más de un proveedor: un SaaS de referencia de un segundo fabricante, un mandato regulatorio de resiliencia o un requisito deliberado de soberanía (capítulo 10.11). La nube híbrida, que mantiene algunos sistemas en las instalaciones conectados a la nube, a menudo es inevitable durante la migración empresarial y para los datos que legalmente no pueden trasladarse. Elegir con la vista clara y una justificación escrita, no porque una diapositiva dijera «multinube».

Diseñar para el costo y adoptar el pensamiento de buena arquitectura

En la nube, una decisión arquitectónica es una decisión de gasto: sobreaprovisionar «por si acaso» aparece en la factura del mes siguiente. Tratar el costo como un atributo de calidad que se diseña y adoptar las prácticas de FinOps, la disciplina de responsabilidad financiera compartida del gasto en la nube (capítulo 9.4), para que ingeniería, finanzas y producto sean responsables de la factura juntos. Etiquetar cada recurso con un responsable, hacer visible el costo por equipo y por servicio, ajustar el tamaño continuamente, usar el escalado automático para pagar por la carga y no por el pico máximo, y aprovechar las palancas de precio que la nube ofrece (descuentos por compromiso de uso, capacidad spot para trabajo interrumpible).

Además del costo, usar un marco de buena arquitectura como lista de verificación para revisiones. Los principales proveedores publican uno, y convergen en los mismos pilares: fiabilidad, seguridad, optimización del costo, eficiencia de rendimiento, excelencia operativa y sostenibilidad. Realizar una revisión ligera en el momento del diseño y periódicamente después, puntuando el sistema frente a cada pilar y registrando las lagunas como trabajo trazado. Es una forma barata de captar la compensación que no se notó.

Compensaciones: ventajas y desventajas

Enfoque	Ventajas	Desventajas
Traslado directo (realojo)	Rápido, bajo esfuerzo inicial, saldría del centro de datos enseguida	Conserva la fragilidad anterior, pierde elasticidad y servicios gestionados, suele costar más
Rediseño nativo de la nube	Elasticidad plena, resiliencia, máximo aprovechamiento de servicios gestionados	Mayor esfuerzo y requisitos de competencias iniciales; cambio más grande que absorber
Mononube, integración profunda	Simplicidad, palancamiento máximo, menor superficie operativa	Acoplamiento concentrado y riesgo de un solo proveedor
Multinube (misma carga de trabajo, dos proveedores)	Cubertura ante la caída del proveedor, mayor poder de negociación	Diseño al denominador común más bajo, superficie y competencias dobladas
Híbrido (nube más instalaciones)	Cumple restricciones de residencia de datos y sistemas heredados, permite migración escalonada	Complejidad de red, dos modelos operativos funcionando a la vez
Serverless / alto grado de gestión	Mínima labor operativa, escala a cero, entrega rápida	Menor control, dependencia del proveedor, penalización por arranque en frío y límites de cuota

La tensión central es el control frente al palancamiento, y atraviesa cada fila. A más se le delega al proveedor, más rápido se avanza y menos se opera, a cambio de un acoplamiento más profundo. La solución no es elegir un extremo u otro, sino colocar cada carga de trabajo de forma deliberada: subir alto en el espectro de gestión para la plomería genérica, quedarse en niveles más bajos solo donde el control realmente justifica su costo, y ponerle precio al acoplamiento en ambas direcciones en lugar de tratar la portabilidad como gratuita y la dependencia como un pecado. Las grandes organizaciones se complican la vida cuando dejan que el miedo (al acoplamiento, a la nube, al costo) tome esa decisión por reflejo en lugar de por análisis.

Preguntas para discutir con el equipo

¿Cuáles de nuestras cargas de trabajo se han trasladado sin cambios, y estamos pagando precios de la nube por una arquitectura de centro de datos? Es habitual migrar bajo presión de tiempo, realojar todo tal como está y proclamar la victoria, para luego descubrir que la factura es mayor que la del centro de datos y que ninguno de los beneficios de resiliencia o elasticidad se ha materializado. La auditoría honesta consiste en listar las cargas de trabajo principales y marcar cada una como realojada, replataformada o genuinamente rediseñada, y luego mirar cuáles siguen en un footprint de tamaño fijo, siempre encendido y en una sola zona. Algo de traslado directo es un primer paso legítimo, por lo que la pregunta no es si se hizo, sino si existe un plan y un plazo para avanzar más. Traer el costo por carga de trabajo y el historial de incidentes, porque las cargas de trabajo que son a la vez caras y frágiles son donde el rediseño rinde más rápido. Si todo sigue teniendo la forma del antiguo centro de datos un año después de la migración, se compró un centro de datos más caro.
Cuando cae una zona de disponibilidad o una región entera, ¿qué ocurre realmente y lo hemos probado? Muchos equipos creen ser resilientes simplemente porque se desplegaron en la nube, sin haber diseñado sus dominios de fallo ni haber arrancado nunca el interruptor para comprobarlo. La versión concreta: para cada sistema crítico, ¿en cuántas zonas se extiende, cuál es el tiempo de recuperación documentado y cuál el punto de recuperación, y cuándo se hizo el último simulacro que forzó la caída de una zona o ensayó la recuperación de una región? La multi-zona debería ser el estándar que no llama la atención, de modo que cualquier carga de trabajo crítica en una sola zona es un hallazgo; la multi-región es una decisión más grave y costosa, ligada a objetivos de recuperación explícitos, que no se adopta por defecto. Traer el mapa de dependencias, porque la falla que duele suele ser un servicio compartido (una base de datos, un proveedor de identidad) cuyo dominio de fallo nadie cartografió. La resiliencia que nunca se ha probado es una hipótesis, no una propiedad.
Para nuestras mayores dependencias de proveedor, ¿cuánto costaría realmente irse, y vale la pena pagar esa cifra para evitarla? Los debates sobre el acoplamiento tienden a correr en el ámbito de la ideología más que en el de los números: un bando abstrae cada servicio gestionado para mantener la portabilidad y el otro ignora por completo el riesgo de concentración. Anclarlo a la realidad: elegir las tres dependencias más profundas, estimar el costo real de ingeniería y el tiempo transcurrido para reemplazar cada una, y sopesarlo contra lo que el servicio ahorra hoy y la probabilidad real de cambiar alguna vez. Sumar los riesgos que la portabilidad no resuelve, como un regulador que exija una segunda fuente o una norma de soberanía sobre dónde pueden vivir los datos, ya que esas razones pueden justificar el multinube o lo híbrido incluso cuando la pura economía no lo haría. El objetivo es una posición deliberada y escrita por cada dependencia, no una política general. Una vez se pone precio, la mayor parte del acoplamiento temido resulta más barato de aceptar que la capa de abstracción que se construyó para evitarlo.
¿Qué servicios operamos nosotros mismos que el proveedor se alegraría de gestionar por nosotros, y cuánto cuesta esa elección en horas de ingeniería? Todo el palancamiento de la nube consiste en delegar el parcheo, las copias de seguridad, el conmutado y la escalación a alguien a quien ese trabajo le paga el salario, y sin embargo los equipos mantienen habitualmente una base de datos autoadministrada, un servidor de mensajes o un clúster de búsqueda por costumbre o orgullo mal puesto. En una gran organización, el costo no es la labor de un solo equipo sino la reinventación del mismo trabajo de plomería en una docena de rincones, cada uno con su propia rotación de guardia y su propia fuente de deriva. La consideración contraria es genuina: hardware especializado, términos de licencia, un límite de cumplimiento inusual o un rendimiento que la oferta gestionada no alcanza pueden justificar quedarse en un nivel más bajo del espectro, por lo que la respuesta es por servicio, no en bloque. Traer un inventario de los servicios que se autooperan, las horas de ingeniería que cada uno consume en mantenimiento e incidentes y el precio de la alternativa gestionada, y exigir un registro de decisión de arquitectura para cada «nosotros operamos el nuestro» que se revalore cada año. En entornos empresariales y gubernamentales, añadir si la decisión de autooperar es realmente una restricción de cumplimiento o de licencia o solo inercia disfrazada de una, porque auditores y dueños de presupuesto harán la misma pregunta.
¿Podemos ver lo que cada equipo y cada servicio nos cuesta este mes, y hay una persona con nombre y apellidos que se sienta responsable de esa cifra? El gasto en la nube se infla en silencio porque el mismo autoservicio que permite a un ingeniero aprovisionar una base de datos global en minutos también le permite dejarla corriendo a tamaño de pico para siempre, y ninguna línea de la factura parece alarmante en soledad. En una gran organización sin visibilidad de costos por equipo y por servicio, finanzas descubre el problema meses tarde y la reacción es una congelación tajante que castiga a los disciplinados junto a los despilfarradores. La tensión es real: perseguir cada centavo frena la entrega, por lo que el objetivo es la responsabilidad y el ajuste de tamaño, no la austeridad, tratando el costo como un atributo de calidad que se diseña y no como un informe que se lee después del hecho. Traer un desglose de costos por equipo, la proporción del gasto sin etiqueta o sin atribuir, el uso actual frente a la capacidad aprovisionada y dónde se están dejando en la mesa los descuentos por compromiso de uso o la capacidad spot. Para empresas y organismos públicos, vincularlo con la práctica de FinOps y con el escrutinio del gasto público, porque un recurso sin etiqueta no es solo un desperdicio, sino un hallazgo de auditoría a la espera de ocurrir.
¿Puede un equipo aprovisionar ahora mismo un almacén de datos público, un volumen sin cifrar o un recurso en una región prohibida, y lo detectaríamos? La mayoría de los incidentes costosos en la nube son malconfiguraciones, no intrusiones al proveedor, y el modelo de responsabilidad compartida sitúa el depósito de almacenamiento abierto o la base de datos expuesta a internet del lado propio. Prevenirlo a escala de muchos equipos es una cuestión de zona de aterrizaje: controles aplicados como política como código que bloquean las configuraciones prohibidas antes de que existan, no una revisión a posteriori que las descubre cuando los registros ya se han filtrado. La presión contraria es la autonomía del desarrollador, porque los controles demasiado rígidos empujan a los equipos a cuentas ocultas, así que el diseño debe impedir lo verdaderamente peligroso sin dejar de dar espacio para moverse. Traer un inventario de los controles realmente aplicados, un intento honesto de aprovisionar un recurso no conforme en una cuenta real y el tiempo de detección cuando la prevención falla. En contextos regulados y gubernamentales, conectarlo con la residencia de datos y los regímenes de autorización, porque un recurso en una región no permitida no es una falta de estilo, sino una violación legal que un auditor tratará como un evento reportable.

Perspectiva sectorial

Start-up. Adoptar lo nativo de la nube en un solo proveedor desde el día uno y aceptar el acoplamiento a propósito. Correr sobre serverless y servicios gestionados que escalan a cero para que dos ingenieros manejen toda la plataforma, porque el recurso más escaso es la atención, no la portabilidad. Fijar un límite duro de gasto, mantener todo en infraestructura como código para que un momento viral no se convierta en una caída, y documentar la decisión deliberada de acoplamiento para revisarla cuando crezca, en lugar de fingir que es temporal.

Pyme. Sin ingeniero de plataforma y con un presupuesto ajustado, tratar la nube como algo que se consume y no como algo que se opera. Preferir SaaS y servicios totalmente gestionados sobre lo que se administre por cuenta propia, apoyarse en los valores seguros por defecto del proveedor y dejar que la base de datos gestionada se encargue de las copias de seguridad y el conmutado para que nadie tenga que hacerlo. Enmarcar la decisión como comprar frente a construir con el pulgar firme del lado de comprar, poner una alerta de facturación para que un recurso olvidado no drene el mes, y buscar una opción de bajo código o gestionada antes de levantar servidores que no se puede dotar de personal.

Empresa grande. La historia con la nube es una historia de migración entre muchos equipos, por lo que la arquitectura es en realidad un problema de gobernanza. Poner en marcha una zona de aterrizaje gobernada con cuentas por unidad de negocio como límites de alcance de daño y de facturación, controles de cifrado por defecto y política como código que bloquee los almacenes de datos públicos, y dejar que un equipo central de plataforma sea propietario de esa base. Ejecutar FinOps con informes de costos por unidad, someter a un marco de buena arquitectura cada diseño significativo y gestionar la conectividad híbrida con los sistemas heredados de registro que no se moverán durante años.

Gobierno. Las normas de contratación, la transparencia y la soberanía condicionan cada decisión. Desplegar en una región de nube autorizada o de nube gubernamental, documentar el límite de responsabilidad compartida línea por línea para los auditores y fijar el almacenamiento y el procesamiento en zonas nacionales mediante política como código que bloquee cualquier recurso en una región no permitida. Obtener la autorización requerida bajo el régimen correspondiente, mantener las pruebas de auditoría como un historial de git y no como una búsqueda desesperada, y preferir los servicios gestionados cuya postura de cumplimiento atestigüe el proveedor frente a infraestructura a medida que habría que certificar por cuenta propia.

Ejemplos

Start-up. Una start-up de doce personas diseña nativa de la nube desde el día uno en un solo proveedor y no siente culpa por ello. La API corre sobre funciones serverless que escalan a cero de noche, los datos viven en un Postgres gestionado con copias de seguridad automáticas y conmutado entre zonas, y los trabajos en segundo plano corren en una cola gestionada. Todo se define en infraestructura como código, y dos ingenieros se encargan de toda la plataforma porque el proveedor opera las partes difíciles. Cuando un momento viral multiplica el tráfico por cincuenta en una hora, el escalado automático lo absorbe, la factura sube en proporción al uso real y luego vuelve a bajar. Los fundadores aceptan deliberadamente el acoplamiento como el precio de avanzar rápido con un equipo diminuto, y escribieron esa decisión para revisarla al crecer.

Empresa grande. Un asegurador multinacional con trescientas aplicaciones heredadas ejecuta una migración de varios años gobernada por las «seis R» (realojar, replataformar, reponer, refactorizar, pensionar, retener). Las aplicaciones de bajo valor y carácter genérico se realojan rápidamente para salir de dos centros de datos bajo un plazo; la plataforma principal de pólizas se refactoriza para ser nativa de la nube; las herramientas propias se reponen como SaaS; y los sistemas obsoletos se pensionan. Un equipo central de plataforma es propietario de una zona de aterrizaje con cuentas por unidad de negocio, controles de cifrado por defecto y política como código que bloquea los almacenes de datos públicos, mientras la conectividad híbrida vincula la nube con los mainframes de registro que no se moverán en años. El costo se gobierna mediante una práctica de FinOps con informes de costos por unidad, y un marco de buena arquitectura evalúa el lanzamiento a producción de cada aplicación.

Gobierno. Un organismo nacional que presta un servicio de prestaciones a los ciudadanos está legalmente obligado a mantener los datos de los residentes dentro de las fronteras nacionales y a funcionar sobre infraestructura autorizada. Despliega en la región de nube gubernamental del proveedor y busca una autorización bajo un régimen como FedRAMP en Estados Unidos (con el trabajo de cumplimiento en el capítulo 4.6), documentando el límite de responsabilidad compartida línea por línea para los auditores. La residencia de datos y las preocupaciones más amplias de soberanía (capítulo 10.11) orientan una arquitectura que fija el almacenamiento y el procesamiento en zonas nacionales y bloquea, mediante política como código, cualquier recurso en una región no permitida. El sistema se extiende en tres zonas de disponibilidad con un plan de recuperación entre zonas probado y aprovisiona todo como código, de modo que las pruebas de auditoría son un historial de git y no una búsqueda desesperada.

Caso de negocio: motivaciones, retorno y costo total de propiedad

La promesa estrella de la nube es transformar el gasto de capital en gasto operativo: en lugar de comprar servidores años antes de la demanda y dejarlos a baja utilización, se paga por lo que se usa y se escala con el negocio. Eso es real, pero el retorno más profundo es la velocidad y el enfoque. Un servicio gestionado que elimina el parcheo, las copias de seguridad y el conmutado devuelve esas horas de ingeniería al trabajo de producto, y aprovisionar en minutos en vez de meses comprime el tiempo desde la idea hasta la producción. La elasticidad significa dejar de pagar capacidad de pico que se usa dos veces al año. Cuando la arquitectura es acertada, todo eso se acumula en un costo total de propiedad que supera al del centro de datos tanto en costo como en capacidad.

El costo de hacerlo mal es igualmente real, así que el caso de negocio debe ser honesto. El traslado directo sin rediseño suele encarecer sin entregar ninguno de los beneficios, y el gasto sin gobernanza puede inflar en silencio entre decenas de equipos hasta que finanzas suene la alarma. Enmarcar el caso ante la dirección en torno a tres palancas: velocidad (entrega más rápida y aprovisionamiento más corto), resiliencia (menos incidentes mayores y de menor duración) y opcionalidad (entrar a un nuevo mercado o región sin un proyecto de centro de datos). Poner números en la renovación de centro de datos evitada, la reducción de personal para infraestructura genérica y los minutos de parada evitados, y contraponerlos al costo de migración y a la inversión continua en FinOps y en plataforma. El argumento más fuerte rara vez son los ahorros directos de costo; es el valor de opción de avanzar más rápido que los competidores que siguen esperando hardware.

Antipatrones y trampas

Trasladar y llamarlo «nube». Realojar un diseño de centro de datos sobre infraestructura alquilada capta los costos y ninguno de los beneficios.
Infraestructura hecha por clic. Los recursos creados a mano son irreproducibles, sin documentación e impossibles de recuperar o auditar; tratar cualquier cambio manual en producción como un defecto.
Multinube por culto a la carga. Ejecutar la misma carga de trabajo en dos proveedores para cubrir un riesgo remoto, pagando en complejidad y diseño al denominador común más bajo todos los días.
Alta disponibilidad en una sola zona. Creer que la nube es resiliente por defecto mientras se ejecutan cargas de trabajo críticas en una zona sin un conmutado probado.
Malinterpretar la responsabilidad compartida. Asumir que el proveedor protege lo que en realidad es de uno mismo, el camino clásico al depósito público que filtra millones de registros.
El costo como una consideración última. Diseñar sin tener en cuenta el gasto y descubrir después que la factura tomó las decisiones de arquitectura.

Modelo de madurez

Nivel 1, Iniciar: El uso de la nube es ad hoc y reactivo. Los equipos crean recursos con clics en cuentas compartidas, las cargas de trabajo se trasladan sin cambios y no hay zona de aterrizaje, no hay visibilidad de costos y la resiliencia se asume en lugar de diseñarse. El primer apagón serio o el shock de la factura son una sorpresa.
Nivel 2, Desarrollar: Aparecen prácticas básicas pero varían entre equipos. Parte de la infraestructura central se aprovisiona como código y algunas cargas de trabajo son multizona, se separan algunas cuentas, pero la cobertura es desigual: las decisiones sobre modelo de servicio y acoplamiento se toman por costumbre, el costo se vigila a posteriori, los controles son inconsistentes y la recuperación entre regiones no se ha probado.
Nivel 3, Estandarizar: Una zona de aterrizaje gobernada con controles como política como código está documentada y se aplica en toda la organización. Un equipo de plataforma es propietario de la base, todo lo de producción se aprovisiona como código, un marco de buena arquitectura evalúa los diseños significativos y las decisiones de comprar frente a construir y de dominios de fallo son deliberadas y registradas de forma consistente en cada equipo.
Nivel 4, Gestionar: El parque se mide y se controla frente a líneas base. El costo por equipo y por servicio se rastrea mediante FinOps frente a objetivos, los tiempos y puntos de recuperación se verifican en lugar de afirmarse, las violaciones de controles y la deriva de configuración se exponen como métricas, el ajuste de tamaño se dirige con datos de utilización y cada decisión de avanzar o no se apoya en evidencia de paneles de costo, fiabilidad y seguridad.
Nivel 5, Orquestar: La arquitectura de la nube se mejora de forma continua y se integra con la planificación del negocio y del riesgo. Los dominios de fallo se ejercitan mediante simulacros rutinarios, el ajuste de tamaño y la estrategia de precios se automatizan, la soberanía y la residencia se ejecutan por medio de política, las posiciones de modelo de servicio y acoplamiento se revalúan en un ciclo regular y el portafolio de cargas de trabajo se reequilibra de forma adaptativa a medida que cambian el mercado, los precios y el panorama de riesgo.

Ideas para la discusión

¿En qué punto del espectro entre IaaS y serverless se ubica cada una de nuestras cargas de trabajo principales, y podría alguna subir para reducir la labor operativa sin perder el control que realmente necesita?
Si el proveedor principal subiera los precios de forma aguda o sufriera una caída regional de varios días, ¿cuál es el plan real y justifica la complejidad del multinube o lo híbrido que se mantiene?
¿Quién es propietario de la zona de aterrizaje y sus controles, y puede un equipo aprovisionar hoy un recurso no conforme (almacén de datos público, volumen sin cifrar, región no permitida)?
Para una carga de trabajo regulada o soberana, ¿se puede producir el límite de responsabilidad compartida y la configuración autorizada como evidencia sin tener que improvisar?

Conclusiones clave

Diseñar para la nube en lugar de fotografiar el centro de datos; la elasticidad, los servicios gestionados y la conciencia de los dominios de fallo son las razones de estar allí.
Subir en el espectro de servicios hacia la gestión y el serverless para el trabajo genérico, y mantener el control en niveles más bajos solo donde realmente justifique su costo.
Hacer de las regiones y las zonas de disponibilidad dominios de fallo explícitos: multi-zona como estándar, multi-región ligada a objetivos de recuperación probados.
Aprovisionar todo como código dentro de una zona de aterrizaje gobernada con controles como política como código, cuentas separadas y un equipo de plataforma que sea propietario de la base.
Cuantificar el acoplamiento al proveedor con honestidad en ambas direcciones, y desconfiar del multinube salvo que un motivo regulatorio, de soberanía o de excelencia de un segundo proveedor lo exija concretamente.
Tratar el costo como un atributo de calidad de primera clase mediante FinOps, y ejecutar revisiones de buena arquitectura para captar las compensaciones que se pasaron por alto.

Referencias y lecturas complementarias

Peter Mell y Timothy Grance, The NIST Definition of Cloud Computing (NIST Special Publication 800-145)
Amazon Web Services, AWS Well-Architected Framework
Microsoft, Azure Well-Architected Framework y Cloud Adoption Framework
Google Cloud, Google Cloud Architecture Framework
Stephen Orban, Ahead in the Cloud: Best Practices for Navigating the Future of Enterprise IT (y las estrategias de migración de las «seis R»)
J.R. Storment y Mike Fuller, Cloud FinOps: Collaborative, Real-Time Cloud Financial Management
Gregor Hohpe, Cloud Strategy: A Decision-Based Approach to Successful Cloud Migration
U.S. General Services Administration, documentación del programa FedRAMP y líneas base de seguridad
Cloud Security Alliance, Security Guidance for Critical Areas of Focus in Cloud Computing