Modelos de servicio y de despliegue en la nube

De una definición a muchos modelos

El Capítulo 0 presentó servidores y la nube: la definición del NIST (Special Publication 800-145, 2011), con sus cinco características esenciales de autoservicio bajo demanda, amplio acceso a la red, agrupación de recursos, elasticidad rápida y servicio medido, y la idea de que los modelos de servicio delegan en un proveedor una parte mayor o menor de la pila. Esta sección lleva esas ideas a la profundidad que necesita un arquitecto para elegir dónde se ejecuta un sistema y defender esa elección.

El NIST define tres modelos de servicio (infraestructura, plataforma y software como servicio) y cuatro modelos de despliegue: público (abierto a cualquiera, propiedad de un proveedor), privado (para una sola organización, esté donde esté y lo opere quien lo opere), comunitario (compartido por organizaciones con inquietudes comunes, como los organismos públicos) e híbrido (dos o más de los anteriores, unidos de forma que los datos y las aplicaciones puedan moverse entre ellos). Desde entonces, el sector ha añadido las funciones y los contenedores como servicio a los modelos de servicio, y la multinube al vocabulario del despliegue.

Dónde se ejecuta el software forma parte de lo que el Capítulo 1 llamó la estructura de asignación de una arquitectura (definir la arquitectura): la correspondencia entre el software y el hardware, las redes y las organizaciones. Es significativo en el sentido del Capítulo 1 porque es costoso de revertir, y porque fija buena parte del costo de un sistema, su disponibilidad, su frontera de seguridad y la rapidez con la que sus equipos pueden lanzar cambios.

Modelos de servicio: quién gestiona qué

Los modelos de servicio forman un espectro. En un extremo alquilas capacidad desnuda y haces tú todo lo que hay por encima; en el otro alquilas una aplicación terminada y solo la configuras. Cada paso hacia la derecha elimina trabajo operativo y elimina opciones. La tabla añade los dos modelos que son posteriores al documento del NIST: los contenedores como servicio y las funciones como servicio.

En la práctica, las fronteras se difuminan. Las plataformas de contenedores serverless, como Google Cloud Run y Azure Container Apps, ejecutan una imagen de contenedor igual que un PaaS ejecuta código, y escalan hasta cero como una función. Kubernetes gestionado puede ser cualquier cosa, desde un plano de control alojado, en el que tú sigues aplicando parches y actualizando las máquinas de trabajo, hasta un modo totalmente gestionado en el que el proveedor también opera los nodos. La pregunta útil nunca es qué etiqueta se aplica, sino qué tareas concretas siguen siendo tuyas: los parches, las decisiones de escalado, la planificación de capacidad, las copias de seguridad, el failover, las actualizaciones y la respuesta de guardia.

Una segunda distinción útil es la unidad de despliegue y de facturación. IaaS factura las máquinas por segundo o por hora, estén ocupadas o no; FaaS factura las invocaciones y el tiempo de ejecución y no cuesta nada cuando está inactivo; PaaS y los contenedores serverless se sitúan en medio. El Capítulo 6 explica por qué el precio por solicitud es más barato que la capacidad siempre encendida por debajo de un volumen de cruce, y más caro por encima de él (arquitecturas serverless). Es la forma de la carga de una carga de trabajo, no su tamaño, lo que decide en qué lado del punto de cruce se encuentra.

El modelo de responsabilidad compartida

Todos los grandes proveedores publican un modelo de responsabilidad compartida. AWS lo resume diciendo que el proveedor es responsable de la seguridad de la nube y el cliente de la seguridad en la nube. El proveedor protege los edificios, el hardware, la red, el hipervisor y los servicios que opera; el cliente protege lo que construye y configura por encima. Dónde cae la línea depende del modelo de servicio, como muestra el diagrama.

Hay tres cosas que nunca se transfieren. El cliente siempre es dueño de sus datos (qué se almacena, dónde, durante cuánto tiempo, quién puede leerlo), de sus identidades y permisos, y de la configuración de los servicios que usa. Muchas brechas en la nube han sido fallos de configuración del cliente y no fallos del proveedor: almacenamiento de objetos que cualquiera podía leer, claves de administrador incluidas en repositorios públicos, permisos demasiado amplios. En 2019, por ejemplo, un atacante aprovechó un firewall de aplicaciones web mal configurado en Capital One para obtener credenciales de la nube y copiar datos relativos a más de 100 millones de personas en Estados Unidos y Canadá; la infraestructura del proveedor se comportó tal como estaba diseñada.

Para un arquitecto, el modelo es una lista de comprobación de trabajo que hay que asignar a alguien. Si un equipo traslada la base de datos de pedidos de la plataforma de reparto de comida de una máquina virtual a un servicio de base de datos gestionada, la aplicación de parches al motor de base de datos pasa al proveedor, pero no así elegir una ventana de mantenimiento, probar las actualizaciones de versión mayor, conceder accesos con mínimo privilegio, activar el cifrado y comprobar que las copias de seguridad se pueden restaurar. El Capítulo 8 trata en profundidad los principios de seguridad que hay detrás de estas obligaciones (principios de seguridad para arquitectos).

Los modelos de despliegue y las razones reales que hay detrás

Las organizaciones rara vez eligen un modelo de despliegue por una sola razón, y la razón declarada no siempre es la real. Ayuda separar los motivos que resisten un examen atento de los que no.

El error habitual es adoptar la multinube como una cobertura abstracta. Hacer que una carga de trabajo se ejecute de forma idéntica en dos proveedores significa usar solo los servicios que ofrecen ambos, construir y probar dos conjuntos de código de infraestructura, contar con personal con conocimientos de ambos y, a menudo, pagar cargos de transferencia de datos entre ellos. Esa es la trampa del mínimo común denominador: pagas cada día el costo de la portabilidad a cambio de una salida que quizá nunca uses. La sección 10.8 trata la dependencia del proveedor como un compromiso al que hay que poner precio, no como un pecado que haya que evitar a toda costa (FinOps, arquitectura de costos y dependencia del proveedor).

Las regiones y las zonas de disponibilidad como datos de entrada del diseño

Una región es un área geográfica con su propio conjunto independiente de centros de datos; una zona de disponibilidad es uno o varios centros de datos dentro de una región con alimentación eléctrica, refrigeración y red independientes, situados lo bastante lejos de los demás como para que un incendio, una inundación o un corte de luz local afecte solo a uno, y lo bastante cerca como para que los viajes de ida y vuelta duren como mucho unos pocos milisegundos. El Capítulo 0 explicó la idea. Para el diseño, importan tres puntos más.

Primero, cada servicio gestionado tiene un ámbito de fallo: los recursos zonales (una sola máquina virtual, un disco) mueren con su zona; los servicios regionales (la mayoría de las bases de datos gestionadas en modo multizona, el almacenamiento de objetos, las colas) los replica el proveedor entre zonas; unos pocos servicios globales (DNS, identidad, algunos servicios de distribución de contenidos y de balanceo de carga) abarcan varias regiones, lo que hace que sus raras caídas tengan un gran alcance. Saber qué ámbito tiene cada dependencia es el primer paso de cualquier análisis de disponibilidad (consulta disponibilidad y fiabilidad).

Segundo, distribuirse entre zonas es la opción por defecto barata y de gran valor. Ejecutar los servicios sin estado de la plataforma de reparto de comida en tres zonas detrás de un balanceador de carga, con una base de datos que mantiene una réplica de reserva síncrona en una segunda zona, sobrevive a la pérdida de un centro de datos con failover automático y un pequeño costo en latencia. Tres zonas en lugar de dos importan para todo lo que use quórums, como etcd en Kubernetes o una base de datos basada en consenso, porque debe sobrevivir una mayoría. Sin embargo, el tráfico entre zonas no siempre es gratuito: la mayoría de los grandes proveedores cobran por los datos que se mueven entre zonas, así que los servicios muy conversadores repartidos entre zonas añaden una línea visible a la factura.

Tercero, las regiones no son idénticas. Las regiones más nuevas o más pequeñas pueden carecer de algunos servicios, algunas tienen menos zonas, los precios varían según la región y la jurisdicción legal sigue a la región. La sección 10.6 trata las múltiples regiones, la recuperación ante desastres y la residencia de datos (multirregión, recuperación ante desastres y edge computing).

Servicios gestionados frente a autogestionados

Un servicio gestionado es un componente (una base de datos, una cola, una caché, un motor de búsqueda, un plano de control de Kubernetes) que el proveedor instala, opera, actualiza con parches, respalda con copias de seguridad y escala por ti. La alternativa es ejecutar tú mismo el mismo software de código abierto en máquinas virtuales o en contenedores. El compromiso es trabajo y riesgo frente a control, costo y portabilidad.

Los servicios gestionados ganan cuando el componente no es diferenciador: toda empresa de reparto de comida necesita una base de datos PostgreSQL fiable, pero ninguna gana clientes por cómo aplica los parches a su base de datos. En términos de diseño guiado por el dominio, son subdominios genéricos, los que conviene comprar en lugar de construir. Una base de datos gestionada ofrece failover multizona, recuperación a un momento dado y parches de versiones menores que, de otro modo, necesitarían un equipo cualificado de guardia. La autogestión gana cuando necesitas una versión, una extensión o un parámetro de ajuste que el proveedor no ofrece, cuando los límites o cuotas del proveedor no encajan, cuando el sobreprecio de lo gestionado se vuelve grande a escala, o cuando la portabilidad entre entornos importa más que la comodidad.

Gestionado no significa libre de mantenimiento. El proveedor impondrá actualizaciones de versión mayor según su propio calendario cuando las versiones antiguas lleguen al fin del soporte, cambiará valores por defecto, impondrá cuotas que descubrirás en el peor momento y tendrá caídas que no puedes arreglar, solo esperar a que pasen. Tú sigues siendo responsable del diseño del esquema, del rendimiento de las consultas, de las decisiones de capacidad, del costo y de la prueba periódica que demuestra que una restauración funciona. Trata cada servicio gestionado como una dependencia con sus propios modos de fallo y su propio costo de salida.

Qué significa nativo de la nube

La Cloud Native Computing Foundation (CNCF), que forma parte de la Linux Foundation y es la casa de Kubernetes, publica la definición más citada de nativo de la nube. La versión 1.0 (2018) describía tecnologías que permiten a las organizaciones construir y ejecutar aplicaciones escalables en entornos dinámicos como las nubes públicas, privadas e híbridas, y citaba como ejemplos típicos los contenedores, las service meshes, los microservicios, la infraestructura inmutable y las API declarativas. La versión 1.1, aprobada en 2024, desplaza el énfasis de las tecnologías a las prácticas: desarrollar, construir y desplegar cargas de trabajo de forma programática y repetible a escala, caracterizadas por sistemas poco acoplados que interoperan de una manera segura, resiliente, gestionable, sostenible y observable.

De ahí se siguen dos consecuencias. Nativo de la nube describe cómo se construye y se opera un sistema, no dónde: un clúster de Kubernetes en un centro de datos privado, aprovisionado a partir de código y desplegado muchas veces al día, es nativo de la nube; una máquina virtual configurada a mano y copiada sin cambios en una nube pública no lo es. Y nativo de la nube es un medio, no un fin. Sus prácticas (automatización, componentes desechables, configuración declarativa, elasticidad, observabilidad) compensan cuando un sistema necesita cambios frecuentes, escala variable y alta disponibilidad; añaden costo y complejidad a una herramienta interna estable que usan veinte personas.

Las migraciones se describen a menudo con las seis R, que vale la pena conocer porque marcan las expectativas: rehost (realojar, lift and shift, sin cambios), replatform (cambios pequeños, como pasar a una base de datos gestionada), refactor o rediseñar la arquitectura (rediseño para operar de forma nativa en la nube), repurchase (sustituir por SaaS), retain (dejarlo donde está) y retire (apagarlo). Realojar es rápido, pero suele aportar pocos de los beneficios de la nube y, ejecutado en máquinas siempre encendidas dimensionadas para el pico, puede costar más que el centro de datos que se dejó.

Cuando la nube no es más barata

El contraejemplo más conocido es 37signals, la empresa que está detrás de Basecamp y HEY. En octubre de 2022, su director de tecnología, David Heinemeier Hansson, anunció que dejaba la nube, alegando una factura anual de AWS de más de 3 millones de USD para cargas de trabajo con una carga estable y predecible. Compró servidores Dell por unos 700 000 USD, los instaló en un espacio de colocation alquilado y sacó sus aplicaciones de la computación de AWS durante 2023; informó de que esto redujo su factura de nube en unos 2 millones de USD al año. En 2025 anunció la segunda etapa: trasladar unos 18 petabytes de archivos de Amazon S3 a cabinas de almacenamiento por valor de unos 1.5 millones de USD para sustituir una factura de S3 de unos 1.5 millones de USD al año, con el objetivo declarado de cerrar su cuenta de AWS. La empresa ha proyectado un ahorro de unos 10 millones de USD en cinco años. Sacar así cargas de trabajo de la nube se llama repatriación desde la nube.

Ambos lados del argumento merecen ser escuchados. A favor del razonamiento de 37signals: su carga es estable, así que ganaba poco con la elasticidad; ya contaba con ingenieros de operaciones experimentados e informó de que no necesitó personal adicional; los proveedores de colocation se ocupan de la alimentación eléctrica, la refrigeración y la seguridad física; y los servidores pueden usarse durante cinco años o más, así que su costo por año de computación queda muy por debajo del alquiler bajo demanda. En el otro lado: 37signals es un negocio maduro con una demanda predecible, cosa que la mayoría de los productos nuevos no son; la comparación depende mucho de cuál habría sido la factura de la nube con descuentos por compromiso de uso y ajuste de tamaño; poseer hardware implica gasto de capital, plazos de entrega de semanas o meses y capacidad comprada por adelantado; y un equipo más pequeño sin conocimientos profundos de operaciones tendría que contratarlos, lo que puede borrar el ahorro. Los críticos también señalan que las cifras de ahorro proceden de la propia empresa.