Fundamentos del cloud: modelos de servicio, de despliegue y responsabilidad compartida

La palabra «cloud» se le cuelga a todo, desde un servicio de copias de seguridad para portátiles hasta una red global de distribución de contenidos, así que conviene partir de una definición que los ingenieros puedan poner a prueba. La que casi todo el mundo toma como referencia procede del National Institute of Standards and Technology (NIST) de Estados Unidos, en la Special Publication 800-145, publicada en 2011 y que sigue siendo la referencia. Esta guía recorre esa definición, explica después los modelos de servicio, los modelos de despliegue y la infraestructura global que comparten todos los proveedores, y termina con el modelo de responsabilidad compartida: la parte que determina qué será culpa tuya cuando algo falle.

Las cinco características que convierten algo en «cloud»

El NIST define el cloud computing como un modelo que permite el acceso por red, bajo demanda, a un pool compartido de recursos informáticos configurables que se pueden aprovisionar y liberar rápidamente con un esfuerzo de gestión mínimo. Cinco características esenciales desgranan esa frase:

1. Autoservicio bajo demanda. Creas tú mismo una máquina virtual, una cola o una base de datos, desde una consola, una herramienta de línea de comandos o una API, sin abrir un ticket a un operador humano.
2. Amplio acceso por red. Los recursos son accesibles mediante protocolos de red estándar desde cualquier tipo de cliente.
3. Agrupación de recursos. El proveedor da servicio a muchos clientes desde el mismo pool físico —esto es el multi-tenancy— y, en general, no sabes ni controlas en qué máquina física acabas, más allá de una ubicación aproximada como una región.
4. Elasticidad rápida. La capacidad puede crecer y reducirse rápidamente, a veces de forma automática, y desde tu punto de vista parece ilimitada.
5. Servicio medido. El uso se mide (segundos de CPU, gigabytes-mes, peticiones, bytes transferidos) y ese contador es el que determina la factura.

El test también sirve al revés. Si tu propio equipo de operaciones gestiona una plataforma de virtualización detrás de un proceso de solicitud de cambios, hay agrupación de recursos, pero no autoservicio ni elasticidad; el NIST la llamaría infraestructura virtualizada, no cloud privado. La distinción importa porque la mayoría de los beneficios que se esperan de «migrar al cloud» —rapidez, pago por uso, escalado automático— vienen del modelo operativo, no de que el hardware esté en otro sitio.

Elasticidad no es lo mismo que escalabilidad

La escalabilidad es la capacidad de un sistema para soportar más carga cuando le das más recursos. La elasticidad es la capacidad de obtener y liberar esos recursos automáticamente a medida que cambia la carga. Un monolito que solo se ejecuta en una máquina grande puede ser escalable (compras una máquina más grande), pero no es elástico. Las plataformas cloud abaratan mucho la implementación de la elasticidad, pero solo para sistemas diseñados de forma que añadir una tercera instancia idéntica realmente sirva de algo: gestión de peticiones sin estado, almacenamiento de sesión compartido, colas para absorber los picos. Ese trabajo de diseño es tuyo; la plataforma solo pone los mandos.

Modelos de servicio: lo que dejas de gestionar

La taxonomía clásica tiene tres capas, y desde que se escribió el documento del NIST se han vuelto habituales otras dos. La forma más clara de compararlas es preguntarse, en cada nivel, qué sigues gestionando tú.

De aquí salen dos reglas prácticas. Primera: cuanto más a la derecha te mueves, menos trabajo operativo cargas y menos libertad tienes; en PaaS no puedes instalar un módulo del kernel, y en FaaS tu código tiene un tiempo máximo de ejecución y ningún disco local persistente. Segunda: los servicios de datos gestionados (un PostgreSQL alojado, un broker de mensajería gestionado) se comportan como PaaS para ese componente aunque el resto del sistema esté en IaaS. Las arquitecturas reales mezclan las capas con total libertad; la etiqueta se aplica por componente, no por empresa.

Modelos de despliegue: quién comparte el pool

Los cuatro modelos de despliegue del NIST describen para quién se opera la infraestructura, y en la práctica el multi-cloud se ha convertido en un quinto.

Cloud público. El proveedor es dueño de la infraestructura y da servicio al público en general. Los clientes comparten hardware, aislados mediante virtualización y controles de red. Es lo que significa «el cloud» en la mayoría de las conversaciones y el modelo que da por supuesto el resto de esta materia.

Cloud privado. La infraestructura se opera en exclusiva para una organización, en sus instalaciones o alojada por un tercero. Puede ser un cloud de verdad (autoservicio, elástico, medido) cuando se construye sobre una plataforma como OpenStack o VMware con una automatización en condiciones, pero con frecuencia no es más que virtualización con un portal. Los sectores regulados lo eligen por motivos de residencia de datos o de latencia; la contrapartida es que la organización paga por adelantado la capacidad pico y tiene que dotar de personal al equipo de plataforma.

Cloud híbrido. Dos o más clouds distintos —normalmente un centro de datos privado y un proveedor público— unidos por una tecnología que permite mover cargas de trabajo y datos entre ellos: un enlace de red privado, un proveedor de identidad común, una capa de orquestación compartida. Los motivos habituales son una migración gradual, mantener en las propias instalaciones un mainframe o un sistema sensible a la latencia, o hacer «bursting» de trabajos batch hacia el cloud público cuando se agota la capacidad local. La mayoría de las grandes empresas viven realmente en un modelo híbrido, y la mayor parte de la dificultad está en la fontanería de red e identidad entre ambos lados.

Cloud comunitario. Lo comparten varias organizaciones con intereses comunes: un consorcio de hospitales, un grupo de organismos públicos. Es raro en la práctica, pero el modelo existe.

Multi-cloud. Usar más de un proveedor público. A veces es deliberado (evitar el lock-in, satisfacer a un regulador que exige planes de salida, aprovechar el punto fuerte de un proveedor en analítica y el de otro en identidad) y a menudo accidental (un equipo eligió AWS, una empresa adquirida funciona sobre Azure). La portabilidad real entre proveedores sale cara, porque los servicios gestionados difieren en su comportamiento, no solo en su API; la mayoría de las estrategias multi-cloud se conforman con una capa de identidad común, observabilidad común y ubicación decidida carga por carga, en lugar de ejecutar la misma carga de trabajo en todas partes.

Regiones, zonas y edge

Todos los grandes proveedores organizan su presencia en los mismos tres niveles, aunque los nombres varíen.

Una región es un área geográfica —un área metropolitana o un país— que contiene un conjunto de centros de datos. Las regiones están aisladas entre sí: un fallo del control plane en una no se propaga a otra, y los datos no salen de una región a menos que tú los muevas. Una región se elige por tres motivos: cercanía a los usuarios (latencia), restricciones legales sobre dónde pueden residir los datos (soberanía) y disponibilidad de servicios, porque los servicios y tipos de instancia nuevos llegan primero a las regiones más grandes.

Una zona de disponibilidad (AZ) es uno o varios centros de datos físicamente separados dentro de una región, cada uno con su propia alimentación, refrigeración y red, conectados a las demás zonas mediante enlaces privados de gran ancho de banda y baja latencia. Las regiones de AWS suelen tener tres o más zonas; Azure ha ido incorporando zonas a sus regiones y ya las ofrece en la mayoría de las principales. El contrato de diseño es que un fallo que afecte a una zona debe dejar las demás en funcionamiento. Toda la disciplina de la alta disponibilidad se apoya en ese contrato: coloca una instancia en cada una de dos o tres zonas detrás de un balanceador de carga y la pérdida de un centro de datos pasa a ser algo que lees en un informe, no una caída del servicio.

Las edge locations son pequeños puntos de presencia, muchísimo más numerosos que las regiones, que alojan cachés de CDN, resolvedores DNS y, cada vez más, pequeños runtimes de cómputo. Existen para acortar el viaje de ida y vuelta hasta el usuario; no ejecutan tus bases de datos.

Region eu-west-1 (Ireland)
├── Availability Zone a  ── data centre(s), own power/cooling/network
├── Availability Zone b  ── data centre(s), own power/cooling/network
└── Availability Zone c  ── data centre(s), own power/cooling/network
        ▲ private low-latency links between zones (synchronous replication feasible)

Region eu-central-1 (Frankfurt)   ── a second region for disaster recovery;
                                     replication is asynchronous over the backbone

Edge locations (hundreds)          ── CDN caches and DNS close to users

Hay una consecuencia que pilla a los recién llegados: los nombres de zona son por cuenta. La zona que tu cuenta llama a puede ser un edificio físico distinto del que otra cuenta llama a; los proveedores barajan la correspondencia para repartir la carga. Usa el identificador de zona que expone el proveedor cuando necesites coordinarte entre cuentas.

El modelo de responsabilidad compartida

El diagrama más importante de la seguridad en el cloud tiene dos filas. El proveedor es responsable de la seguridad del cloud: los edificios, el hardware, el hipervisor, el software de los servicios gestionados. Tú eres responsable de la seguridad en el cloud: todo lo que configuras o despliegas. La línea entre ambas filas se desplaza según el modelo de servicio.

Hay tres filas que nunca pasan al proveedor: la identidad, los datos y los dispositivos desde los que inician sesión tus usuarios. Por eso las grandes filtraciones en el cloud público de la última década fueron casi todas errores de configuración —un bucket de almacenamiento legible por cualquiera, una clave de acceso subida a un repositorio público, una base de datos sin autenticación accesible desde internet— y no fallos de la plataforma subyacente. El proveedor te da discos cifrados y políticas de acceso granulares; usarlos o no depende de ti.

De este modelo se derivan dos hábitos prácticos. Lee la matriz de responsabilidades de cada servicio gestionado que adoptes, porque «gestionado» no siempre significa lo mismo: un control plane de Kubernetes gestionado no parchea tus nodos worker salvo que actives la actualización automática de nodos, y una base de datos gestionada solo aplica los parches del motor dentro de la ventana de mantenimiento que tú definas. Y da por hecho que las certificaciones de cumplimiento del proveedor cubren solo su mitad: un certificado ISO 27001 de la plataforma no dice nada sobre si tu aplicación trata los datos personales conforme a la ley.

Pagar por uso: CapEx, OpEx y la economía real

La infraestructura on-premises es un gasto de capital (CapEx): compras servidores dimensionados para el pico que esperas dentro de tres años, los amortizas y los mantienes funcionando con una utilización media baja. El cloud es un gasto operativo (OpEx): pagas cada mes lo que has usado. El cambio no sale automáticamente más barato. Lo es cuando la carga es variable, cuando de otro modo sobredimensionarías mucho, cuando puedes apagar recursos fuera del horario laboral o cuando la alternativa era un equipo de personas montando hardware en racks. Sale más caro cuando la carga es estable y predecible y la organización ya tiene el centro de datos y el personal, y puede salir muchísimo más caro cuando nadie apaga los recursos que no se usan.

La medición que hace flexible al cloud también convierte el coste en una cuestión de ingeniería y no de compras. Cada decisión de arquitectura —cuántos datos cruzan las fronteras entre regiones, si los logs se conservan para siempre, si un trabajo batch se ejecuta sobre la capacidad interrumpible más barata— aparece ahora en una factura en cuestión de días. La guía de gestión de costes trata la disciplina a fondo; la idea fundamental aquí es que, en el cloud, los ingenieros gastan dinero escribiendo código.

Errores comunes

Tratar un lift-and-shift como «estar en el cloud». Copiar una máquina virtual a un proveedor y ejecutarla exactamente igual que antes te aporta una factura nueva y nada de elasticidad. Mientras la carga de trabajo no pueda escalar horizontalmente ni recrearse mediante automatización, se ha mudado, no se ha transformado.

Dar por hecho que el proveedor parchea tus VM. En IaaS, el sistema operativo es tuyo. Las imágenes sin parchear y las máquinas de pruebas olvidadas son un hallazgo habitual en las auditorías de seguridad cloud. Automatiza los parches o, mejor aún, reconstruye periódicamente las instancias a partir de imágenes nuevas.

Confundir alta disponibilidad con recuperación ante desastres. Repartir instancias entre zonas cubre la caída de un centro de datos; no sirve de nada ante un despliegue defectuoso que corrompe la base de datos ni ante una caída regional. Las copias de seguridad y, cuando esté justificado, una segunda región son decisiones aparte, que se tratan en alta disponibilidad y recuperación ante desastres.

Usar la cuenta root o de propietario para el trabajo diario. Todos los proveedores ofrecen una identidad de cuenta única y todopoderosa. Protégela con autenticación multifactor por hardware, guarda sus credenciales fuera de línea y crea identidades con permisos acotados para las personas y las cargas de trabajo.

Ignorar las fronteras de transferencia de datos. El tráfico dentro de una zona suele ser gratuito, entre zonas cuesta un poco y entre regiones o hacia internet cuesta bastante más. Las arquitecturas que mueven grandes conjuntos de datos entre regiones «porque el equipo de analítica está allí» dan una sorpresa a sus responsables a final de mes.

Conclusiones clave

• El cloud computing se define por un modelo operativo —autoservicio, elasticidad, agrupación de recursos, medición, acceso por red—, no por el edificio en el que están los servidores.
• Los modelos de servicio forman un espectro que va de IaaS a SaaS; cada paso a la derecha quita tareas operativas y control a partes iguales, y la etiqueta se aplica por componente.
• Público, privado, híbrido y multi-cloud describen quién comparte el pool; la mayoría de las grandes organizaciones están en un modelo híbrido, cuyas partes difíciles son la identidad y la red.
• Las regiones aíslan los fallos y cumplen las normas de residencia de datos; las zonas de disponibilidad dentro de una región son la unidad de la alta disponibilidad; el edge acerca las cachés a los usuarios.
• Con la responsabilidad compartida, el proveedor protege la plataforma, mientras que la identidad, los datos, el código de la aplicación y la configuración siempre siguen siendo tuyos.
• El pago por uso convierte las decisiones de arquitectura en decisiones de coste, así que tener en cuenta el coste forma parte de la ingeniería, no es un asunto financiero para después.