1. INTRODUCCIÓN

La computación en la nube o cloud computing es un modelo de provisión de capacidades digitales que permite consumir recursos de cómputo, red, almacenamiento, plataformas y aplicaciones como servicios accesibles mediante una red. Su importancia no reside únicamente en que los servidores estén alojados fuera del edificio de la organización. La característica decisiva es que los recursos se presentan como un conjunto compartido, automatizable, elástico y medible, de manera que puedan aprovisionarse y liberarse con rapidez. Una infraestructura remota administrada manualmente, sin autoservicio, elasticidad ni medición, puede ser externalización o alojamiento, pero no constituye necesariamente una nube en sentido estricto.

La definición de referencia sigue siendo la publicada por el National Institute of Standards and Technology en la NIST SP 800-145. Ese documento describe un modelo compuesto por cinco características esenciales, tres modelos de servicio y cuatro modelos de despliegue. La normalización internacional ha evolucionado desde ISO/IEC 17788:2014 hacia la familia ISO/IEC 22123, cuya parte 1 establece el vocabulario y cuya parte 2 desarrolla los conceptos. Para una oposición conviene usar la taxonomía NIST porque permite responder con precisión a las preguntas clásicas sobre IaaS, PaaS, SaaS y tipos de nube, pero también conocer la terminología ISO vigente.

Cloud computing se apoya en varias tecnologías anteriores: virtualización de servidores, redes y almacenamiento; automatización mediante interfaces de programación; gestión de identidades; balanceo; monitorización; facturación o imputación del consumo; y sistemas distribuidos tolerantes a fallos. La nube no elimina los centros de proceso de datos, sino que cambia la forma de construirlos y explotarlos. Detrás de una consola de autoservicio siguen existiendo servidores, cabinas o almacenamiento distribuido, redes, energía, refrigeración, controles de seguridad y personal de operación. Lo que cambia es el grado de abstracción y el modelo operativo.

En una organización sanitaria pública, la nube debe analizarse junto con la continuidad asistencial, la protección de datos de salud, la interoperabilidad, la soberanía y localización de los datos, el Esquema Nacional de Seguridad, la contratación pública, la reversibilidad del servicio y la dependencia del proveedor. El objetivo no es trasladar indiscriminadamente todas las cargas a un proveedor externo, sino seleccionar para cada sistema el modelo que ofrezca el equilibrio adecuado entre seguridad, disponibilidad, coste, escalabilidad y capacidad de evolución.

El tema se estructura desde los fundamentos hasta la implantación. Primero se examinan las características NIST, los modelos de servicio y de despliegue. Después se estudian la virtualización y la hiperconvergencia, que proporcionan la base de muchas nubes privadas. A continuación se aborda la virtualización a nivel de sistema operativo mediante contenedores, los estándares OCI y la orquestación con Kubernetes. Finalmente se analizan la seguridad, la migración, el gobierno y la aplicación prudente de estas tecnologías en el Sistema Sanitario Público de Andalucía.

2. CARACTERÍSTICAS ESENCIALES Y MODELO OPERATIVO DE LA NUBE

2.1. Autoservicio bajo demanda

El autoservicio bajo demanda permite que un consumidor aprovisione por sí mismo capacidades como tiempo de CPU, máquinas virtuales, volúmenes, bases de datos o entornos de ejecución, sin que cada solicitud requiera una intervención manual del proveedor. El autoservicio se materializa mediante portales, catálogos y API. No significa ausencia de gobierno: el catálogo puede imponer plantillas, tamaños autorizados, cuotas, zonas de despliegue, controles de seguridad y flujos de aprobación. La diferencia respecto a la infraestructura tradicional es que, una vez definidas las políticas, la ejecución es automática y repetible.

2.2. Acceso amplio a la red

El acceso amplio a la red implica que las capacidades están disponibles mediante mecanismos normalizados y accesibles desde clientes heterogéneos. La red puede ser Internet, una red corporativa, una VPN o un enlace privado. Por tanto, no debe confundirse acceso amplio con exposición pública. En sistemas sanitarios es frecuente que los servicios se publiquen únicamente por redes privadas, pasarelas seguras o puntos de acceso controlados, manteniendo los mismos principios de consumo bajo demanda.

2.3. Agrupación de recursos y multitenencia

La agrupación de recursos permite atender a múltiples consumidores desde un conjunto común de recursos físicos y virtuales. El proveedor asigna y reasigna capacidad dinámicamente según la demanda. Esta propiedad conduce al concepto de multitenencia: diferentes organizaciones, unidades o proyectos comparten infraestructura manteniendo aislamiento lógico. El aislamiento debe existir en cómputo, red, almacenamiento, identidades, registros y claves. En una nube privada, los «tenants» pueden ser servicios centrales, hospitales, distritos, proyectos o entornos de desarrollo.

La agrupación mejora la utilización de la infraestructura, pero introduce riesgos. Un error de configuración puede romper el aislamiento; una carga ruidosa puede consumir recursos en perjuicio de otra; y una vulnerabilidad del hipervisor o del plano de control puede afectar a varios consumidores. De ahí la importancia de cuotas, límites, segmentación, políticas de calidad de servicio y monitorización.

2.4. Elasticidad rápida

La elasticidad es la capacidad de aumentar o reducir recursos con rapidez, idealmente de forma automática. La escalabilidad expresa que un sistema puede crecer; la elasticidad añade que la capacidad se ajusta dinámicamente a la demanda y puede volver a disminuir. El escalado vertical aumenta CPU o memoria de una instancia; el horizontal añade o retira instancias. El escalado horizontal suele encajar mejor con aplicaciones distribuidas y contenedores, siempre que el estado se mantenga fuera de los nodos efímeros o se gestione mediante servicios persistentes.

2.5. Servicio medido

El servicio medido registra el consumo mediante métricas apropiadas: horas de CPU, memoria reservada, almacenamiento, operaciones, transferencia, invocaciones o licencias. En una nube pública, la medición suele traducirse en facturación. En una nube privada puede utilizarse para imputación interna, planificación de capacidad o showback, aunque no exista cobro directo. El pago por uso es un modelo económico frecuente, pero la característica técnica esencial es que el uso se mida y pueda controlarse y comunicarse.

El modelo operativo cloud se completa con automatización, infraestructura como código, observabilidad y responsabilidad distribuida. Los equipos de plataforma definen servicios reutilizables y seguros; los equipos de producto los consumen mediante API; y las políticas se aplican de forma automatizada. Este enfoque reduce el tiempo de provisión, pero exige disciplina: una mala plantilla puede reproducir un error a gran escala con la misma rapidez con la que una buena plantilla reproduce una configuración segura.

3. MODELOS DE SERVICIO: IaaS, PaaS Y SaaS

Los modelos de servicio indican qué capas administra el proveedor y cuáles conserva el consumidor. No son simples nombres comerciales: representan fronteras de responsabilidad. Cuanto más se asciende desde IaaS hacia SaaS, mayor es la abstracción y menor el control directo del cliente sobre el sistema operativo, el runtime y la aplicación. A cambio, disminuye la carga operativa y aumenta la velocidad de adopción.

3.1. Infraestructura como servicio (IaaS)

En IaaS el proveedor ofrece capacidad de cómputo, red y almacenamiento virtualizados. El consumidor despliega sistemas operativos, middleware y aplicaciones, y decide cómo configurarlos. El proveedor administra el CPD, el hardware físico, la red subyacente y normalmente el hipervisor. El cliente continúa siendo responsable del parcheado del sistema operativo invitado, del endurecimiento, de las cuentas, del software instalado, de los datos y de la seguridad de sus aplicaciones.

Los recursos habituales son máquinas virtuales, discos de bloque, redes virtuales, balanceadores y cortafuegos definidos por software. IaaS es apropiado para migrar aplicaciones existentes que requieren control del sistema operativo, para entornos de recuperación o para cargas con requisitos específicos. Su principal riesgo es reproducir en la nube todos los defectos del CPD tradicional: servidores sobredimensionados, administración manual, sistemas sin parchear y dependencia de direcciones o discos locales.

3.2. Plataforma como servicio (PaaS)

En PaaS el proveedor administra además el sistema operativo, el entorno de ejecución, el middleware y gran parte de la operación de la plataforma. El consumidor aporta el código, la configuración de la aplicación y los datos. Son ejemplos conceptuales una plataforma de aplicaciones web, un servicio gestionado de base de datos, una cola de mensajes o una plataforma de integración. El desarrollador no gestiona máquinas individuales, sino capacidades de plataforma con parámetros, cuotas y niveles de servicio.

PaaS acelera el desarrollo y reduce tareas indiferenciadas como instalar parches, configurar clústeres o gestionar copias internas. Sin embargo, puede aumentar la dependencia de API y características específicas del proveedor. Para reducirla conviene separar lógica de negocio de servicios propietarios, usar formatos abiertos, automatizar la exportación de datos y documentar el procedimiento de reversibilidad.

3.3. Software como servicio (SaaS)

En SaaS el proveedor entrega una aplicación completa accesible mediante navegador, cliente ligero o API. Administra infraestructura, plataforma y aplicación. El consumidor configura usuarios, permisos, parámetros funcionales, integraciones y políticas de retención, y sigue siendo responsable del uso legítimo de los datos y de la correcta asignación de accesos. Que el proveedor opere la aplicación no exime al responsable del tratamiento ni al propietario del servicio de sus obligaciones.

SaaS reduce el tiempo de implantación y favorece actualizaciones continuas, pero limita la personalización profunda. Deben evaluarse exportación de datos, auditoría, continuidad, integración con identidad corporativa, localización, subencargados, borrado verificable y funcionamiento ante indisponibilidad de la red. En sanidad, una herramienta SaaS de colaboración no debe asumir automáticamente que puede procesar información clínica: el caso de uso, el contrato y el análisis de riesgos son determinantes.

3.4. Modelos complementarios

La práctica ha extendido el catálogo con CaaS para plataformas de contenedores, FaaS o funciones como servicio para ejecutar código activado por eventos, DBaaS para bases de datos gestionadas, DaaS para escritorios, SECaaS para controles de seguridad y otros modelos. Estas siglas son útiles, pero no sustituyen a la taxonomía principal. FaaS suele considerarse una especialización de PaaS; CaaS puede situarse entre IaaS y PaaS según cuánto administre el proveedor.

4. NUBES PRIVADAS, PÚBLICAS, HÍBRIDAS Y COMUNITARIAS

4.1. Nube privada

Una nube privada se provisiona para el uso exclusivo de una sola organización. Puede encontrarse en sus instalaciones o en las de un tercero y puede ser operada por personal propio, por un proveedor o por ambos. Su rasgo definitorio es la exclusividad organizativa, no la ubicación. Para merecer el nombre de nube debe ofrecer automatización, catálogo, elasticidad, agrupación y medición; un clúster de virtualización administrado únicamente mediante tickets manuales es virtualización, pero no necesariamente una nube privada completa.

La nube privada proporciona control sobre arquitectura, residencia de datos, segmentación, ventanas de mantenimiento y versiones. Puede ser adecuada para cargas con fuerte integración local, latencia estricta, requisitos de soberanía o inversiones ya amortizadas. Sus limitaciones son el coste de adquirir capacidad máxima, la necesidad de personal especializado y una elasticidad limitada por el hardware disponible.

4.2. Nube pública

Una nube pública se provisiona para uso abierto de múltiples consumidores y pertenece a un proveedor que explota infraestructura a gran escala. Ofrece un catálogo amplio, aprovisionamiento rápido y capacidad elástica. «Pública» describe el modelo de disponibilidad del servicio, no que los datos sean públicamente accesibles. Los recursos de un cliente deben quedar aislados mediante controles lógicos y pueden usar redes privadas, cifrado y puntos de conexión no expuestos a Internet.

La nube pública facilita experimentar y absorber picos sin comprar infraestructura, pero exige control del gasto, gobierno de identidades y conocimiento del contrato. La aparente capacidad ilimitada puede convertir un error de automatización en un coste elevado. La salida de datos, las licencias, los servicios gestionados y la continuidad durante una incidencia del proveedor deben considerarse desde el diseño.

4.3. Nube híbrida

La nube híbrida combina dos o más infraestructuras diferenciadas —privadas, comunitarias o públicas— que permanecen como entidades propias, pero están conectadas para permitir portabilidad de datos y aplicaciones. No basta con que una organización tenga sistemas internos y contrate un SaaS aislado; debe existir algún grado de integración, gobierno coordinado o movilidad entre entornos.

Un patrón híbrido puede mantener datos sensibles en una plataforma controlada y usar capacidad externa para cargas desacopladas, copias cifradas, analítica sobre datos adecuadamente protegidos o entornos temporales. El cloud bursting consiste en desbordar capacidad hacia otra nube durante picos, pero solo es viable si la aplicación puede escalar horizontalmente, los datos están disponibles con la latencia necesaria y las políticas de seguridad son coherentes.

4.4. Nube comunitaria, multicloud y edge

La nube comunitaria se comparte entre organizaciones con preocupaciones comunes, por ejemplo un sector regulado o varias administraciones. NIST la incluye como cuarto modelo. Multicloud describe el uso de servicios de más de un proveedor, pero no implica integración ni portabilidad automática. Puede reducir concentración de riesgo o permitir elegir servicios, aunque aumenta complejidad, dispersión de habilidades y dificultad de gobierno.

El edge computing desplaza procesamiento cerca de la fuente de datos. En salud puede resultar útil para dispositivos, imagen o telemonitorización cuando la latencia, el ancho de banda o la continuidad local son críticos. Edge no compite necesariamente con cloud: suele actuar como una extensión distribuida conectada a servicios centrales.

5. ARQUITECTURA CLOUD, AUTOMATIZACIÓN E INFRAESTRUCTURA COMO CÓDIGO

Una plataforma cloud separa el plano de control del plano de datos. El plano de control recibe solicitudes, autentica, aplica políticas, programa recursos y mantiene el estado deseado. El plano de datos ejecuta las cargas y transporta o almacena la información. Esta separación aparece tanto en una nube IaaS como en Kubernetes, redes definidas por software y sistemas de almacenamiento distribuidos. Proteger el plano de control es prioritario porque una cuenta con privilegios sobre él puede crear, modificar o borrar recursos a gran escala.

5.1. Regiones, zonas y dominios de fallo

Los proveedores y las nubes privadas organizan recursos en dominios de fallo. Una región agrupa ubicaciones geográficas y una zona representa un conjunto con cierta independencia de energía, red o climatización. Los nombres comerciales varían, por lo que el arquitecto debe leer la definición contractual. Distribuir instancias entre zonas reduce el impacto de fallos locales, pero no protege frente a errores lógicos, borrados, corrupción de datos o una mala actualización. La alta disponibilidad no sustituye al backup.

Un diseño resiliente evita concentrar todas las réplicas, controladores y copias en el mismo dominio. También debe considerar dependencias ocultas: DNS, identidad, repositorios, claves, red de gestión y observabilidad. Dos centros de datos no proporcionan verdadera independencia si ambos dependen de una única base de datos o de un solo proveedor de identidad sin contingencia.

5.2. API e infraestructura como código

La nube se opera mediante API. La infraestructura como código expresa redes, máquinas, políticas y servicios en ficheros versionables. Su valor no es solo evitar clics, sino hacer el despliegue reproducible, revisable y auditable. El código debe pasar controles de calidad, revisión por pares y validaciones de seguridad antes de aplicarse. Los secretos no se almacenan en el repositorio; se referencian desde un gestor de secretos.

flujo recomendado:
  cambio en repositorio
        ↓
  validación sintáctica
        ↓
  análisis de seguridad y políticas
        ↓
  plan de cambios
        ↓
  aprobación
        ↓
  aplicación automatizada
        ↓
  verificación y registro

5.3. Imágenes, plantillas y catálogo

Las máquinas virtuales y contenedores se crean a partir de imágenes. Una imagen dorada incorpora un sistema base endurecido, agentes autorizados y una configuración mínima. Debe mantenerse por una cadena de construcción automática, no por modificaciones manuales de una máquina ya desplegada. Si una vulnerabilidad afecta a la imagen, se genera una nueva versión y se reemplazan las instancias; esta práctica de infraestructura inmutable reduce la deriva de configuración.

El catálogo cloud debe limitar opciones a patrones soportados. Un catálogo excesivamente abierto genera diversidad inmanejable; uno demasiado rígido obliga a los equipos a buscar atajos. El gobierno efectivo ofrece «caminos pavimentados»: plantillas seguras que resuelven redes, registros, identidad, copias y observabilidad, pero permiten parametrizar lo necesario.

5.4. Observabilidad y SRE

La monitorización tradicional informa de que un servidor consume CPU. La observabilidad combina métricas, registros y trazas para comprender el comportamiento del servicio. En entornos dinámicos, las instancias son efímeras y no deben ser la unidad principal de gestión. El objetivo es observar transacciones y niveles de servicio: latencia, errores, saturación y tráfico. Las prácticas de Site Reliability Engineering utilizan indicadores SLI, objetivos SLO y presupuestos de error para equilibrar fiabilidad y velocidad de cambio.

6. VIRTUALIZACIÓN DE SERVIDORES

La virtualización abstrae recursos físicos para ejecutar varios entornos lógicos sobre un mismo host. En la virtualización completa, cada máquina virtual dispone de hardware virtual, sistema operativo invitado, bibliotecas y aplicaciones. El hipervisor controla el acceso a CPU, memoria, red y almacenamiento y mantiene el aislamiento entre invitados. NIST SP 800-125 analiza esta tecnología y sus implicaciones de seguridad.

6.1. Hipervisores de tipo 1 y tipo 2

Un hipervisor tipo 1 o bare metal se ejecuta directamente sobre el hardware o sobre una capa mínima especializada. Se utiliza habitualmente en servidores por su rendimiento, control y menor superficie que un sistema operativo de propósito general. Ejemplos de productos o tecnologías son VMware ESXi, Microsoft Hyper-V, KVM integrado en Linux y Nutanix AHV. Un hipervisor tipo 2 se ejecuta como aplicación sobre un sistema operativo anfitrión, como ocurre con herramientas de escritorio. La clasificación describe la arquitectura, no determina por sí sola que un producto sea seguro.

6.2. CPU, memoria y dispositivos virtuales

La CPU virtual se programa sobre procesadores físicos. La sobreasignación permite definir más vCPU que núcleos, confiando en que no todas las máquinas demanden máximo rendimiento simultáneamente. Un exceso produce espera de CPU y latencia. La memoria puede gestionarse con técnicas de compartición, ballooning o paginación, pero cuando el host carece de RAM el rendimiento se degrada de forma pronunciada. Para bases de datos y sistemas clínicos sensibles a latencia, la capacidad debe basarse en mediciones y no solo en ratios genéricos.

Los dispositivos virtuales presentan interfaces de red, controladoras y discos. Los controladores paravirtualizados mejoran rendimiento al cooperar con el hipervisor. Las herramientas del invitado habilitan apagado coordinado, sincronización y métricas. Las extensiones de virtualización de CPU y la traducción de direcciones de segundo nivel reducen el coste de ejecutar invitados sin modificar.

6.3. Redes y almacenamiento virtuales

Un conmutador virtual conecta interfaces de máquinas y las enlaza con redes físicas. VLAN, redes superpuestas y cortafuegos distribuidos permiten segmentar sin depender exclusivamente de equipos externos. La microsegmentación aplica políticas entre cargas, incluso si comparten host. El diseño debe impedir que la red de gestión, la migración y el almacenamiento queden expuestos a redes de usuario.

El almacenamiento puede presentarse como discos virtuales sobre SAN, NAS, almacenamiento definido por software o discos locales distribuidos. La independencia entre disco virtual y soporte físico facilita migración y snapshots, pero añade capas que deben monitorizarse. La latencia percibida por la máquina resulta de colas en invitado, hipervisor, red, controladora y dispositivo.

6.4. Operaciones: migración, alta disponibilidad y snapshots

La migración en vivo mueve una máquina en ejecución entre hosts copiando memoria y coordinando el cambio de ejecución. Permite mantenimiento y balanceo, pero requiere compatibilidad, red y almacenamiento adecuados. La alta disponibilidad reinicia una máquina en otro host tras un fallo; normalmente existe una interrupción, por lo que no debe confundirse con tolerancia a fallos sin pérdida de sesión.

Un snapshot conserva el estado de una máquina o disco en un momento concreto y suele depender de la cadena de almacenamiento original. Es útil antes de cambios y para recuperaciones breves, pero no sustituye una copia independiente. Mantener snapshots durante mucho tiempo puede degradar rendimiento, consumir espacio y complicar consolidación.

6.5. Seguridad del hipervisor

El hipervisor y su plano de administración son activos críticos. Deben minimizarse servicios, aplicar parches, usar autenticación fuerte, separar redes, registrar acciones y restringir consolas. Las plantillas deben evitar credenciales clonadas y agentes innecesarios. Una vulnerabilidad de escape de máquina virtual es menos frecuente que una mala configuración, pero su impacto potencial es elevado porque rompe la frontera de aislamiento.

7. VIRTUALIZACIÓN DE DATOS, ALMACENAMIENTO, ESCRITORIOS Y APLICACIONES

El enunciado del tema menciona servidores, datos y aplicaciones. La virtualización se aplica a cada ámbito con objetivos distintos. En servidores abstrae hardware; en almacenamiento agrega dispositivos y presenta volúmenes lógicos; en datos ofrece una vista integrada sin mover necesariamente toda la información; y en aplicaciones desacopla el software del puesto físico.

7.1. Virtualización de almacenamiento

La virtualización de almacenamiento reúne capacidad de varios dispositivos y la presenta como volúmenes, sistemas de ficheros u objetos. Puede implementarse en una cabina, en la red o mediante software distribuido en los servidores. Funciones como aprovisionamiento fino, deduplicación, compresión, replicación y snapshots mejoran utilización y operación, pero cada una tiene costes y límites. El aprovisionamiento fino permite asignar lógicamente más capacidad que la disponible; por ello requiere alertas para evitar agotamiento físico.

En cloud se distinguen almacenamiento de bloque, adecuado para discos de máquinas y bases de datos; de ficheros, que ofrece jerarquía y protocolos compartidos; y de objetos, que almacena datos con identificadores y metadatos mediante API. El almacenamiento de objetos facilita escalado masivo y durabilidad, pero no se comporta como un sistema de ficheros POSIX y las aplicaciones deben diseñarse para su semántica.

7.2. Virtualización de datos

La virtualización de datos crea una capa lógica que consulta fuentes heterogéneas y entrega una vista unificada sin copiar necesariamente todos los datos a un repositorio central. Es diferente de virtualizar discos. Puede acelerar integración y gobierno, aunque no elimina problemas de calidad, semántica o rendimiento. Si una consulta federada depende de varios sistemas asistenciales, su disponibilidad queda limitada por las fuentes y la red. Deben aplicarse control de acceso, trazabilidad y minimización a nivel de vista.

7.3. VDI y escritorios como servicio

La infraestructura de escritorio virtual o VDI ejecuta escritorios completos en servidores centrales y transmite al terminal la interfaz, teclado y ratón. Puede ofrecer escritorios persistentes, donde los cambios se conservan, o no persistentes, reconstruidos desde una imagen. DaaS aplica el modelo de servicio cloud al escritorio. La centralización facilita parcheado y acceso remoto, pero exige dimensionar cómputo, almacenamiento de perfiles, gráficos, impresión, periféricos y red.

7.4. Virtualización y publicación de aplicaciones

La virtualización de aplicaciones encapsula o ejecuta el programa en un entorno controlado y presenta su interfaz al usuario. Puede evitar conflictos de dependencias y simplificar actualizaciones. No debe confundirse con contenedores de servidor: aunque ambos empaquetan aplicaciones, las tecnologías de publicación de escritorio se orientan a interacción gráfica de usuario, mientras los contenedores suelen ejecutar procesos de servicio.

Para elegir una técnica hay que analizar el acoplamiento de la aplicación. Un cliente pesado que requiere dispositivos locales, controladores específicos o baja latencia puede no comportarse bien a distancia. Una aplicación web moderna puede resultar más sostenible que mantener indefinidamente una capa de publicación. La virtualización es una herramienta de transición, no una excusa para evitar la renovación arquitectónica.

8. HIPERCONVERGENCIA

La infraestructura hiperconvergente o HCI integra cómputo, almacenamiento definido por software y virtualización en un clúster de nodos gestionado de forma unificada. En una arquitectura tradicional, servidores, cabinas SAN y redes se adquieren y administran como silos. En HCI, cada nodo aporta CPU, memoria y discos; el software agrega los discos y distribuye los datos, mientras el hipervisor ejecuta las máquinas. La capacidad crece añadiendo nodos, aunque la relación entre cómputo y almacenamiento no siempre puede ajustarse de forma independiente.

8.1. Arquitectura interna

Los nodos forman un clúster. Una capa de almacenamiento distribuido replica o codifica fragmentos entre nodos para tolerar fallos. Los datos se colocan según políticas de protección, rendimiento y dominio de fallo. Si un disco o nodo cae, el sistema reconstruye la redundancia con los recursos restantes. El clúster necesita capacidad libre para reconstrucción; operar permanentemente cerca del cien por cien elimina margen y prolonga la exposición ante un segundo fallo.

8.2. Escalado y dimensionamiento

El escalado HCI es modular, pero no ilimitado ni automático. Hay que considerar número mínimo de nodos, tolerancia a fallos, ancho de banda este-oeste, latencia, compatibilidad y límites del producto. Algunas plataformas permiten nodos orientados a almacenamiento o cómputo; otras obligan a crecer ambos recursos a la vez. Para bases de datos intensivas, imagen médica o análisis, el perfil de I/O y la localidad del dato son tan importantes como la suma de terabytes.

8.3. Ventajas

• Operación unificada: reduce consolas y coordinación entre silos.
• Despliegue repetible: los nodos siguen configuraciones homogéneas.
• Escalado gradual: permite añadir capacidad por bloques.
• Automatización: integra provisión, políticas y ciclo de vida.
• Uso de hardware estándar: en muchas implementaciones evita una cabina externa especializada.

8.4. Limitaciones y riesgos

HCI concentra dependencias en una plataforma. Una actualización defectuosa, un fallo del plano de gestión o una incompatibilidad puede afectar simultáneamente a cómputo y almacenamiento. La simplificación visual no elimina la complejidad interna; la traslada al software. Deben verificarse procedimientos de actualización, soporte, sustitución de nodos, evacuación, exportación de máquinas y recuperación si la consola central no está disponible.

También existe riesgo de lock-in. Los formatos de disco, API y políticas pueden dificultar la migración. La evaluación debe incluir coste total durante varios años, licencias, crecimiento, renovación, energía, formación y salida. Una adquisición no debe basarse únicamente en el precio inicial por nodo.

9. CONTENEDORES: FUNDAMENTOS Y DIFERENCIAS CON LAS MÁQUINAS VIRTUALES

Los contenedores son una forma de virtualización a nivel de sistema operativo combinada con empaquetado de aplicaciones. En lugar de emular hardware y arrancar un sistema operativo invitado completo, aíslan procesos que comparten el kernel del host. En Linux, el aislamiento se apoya principalmente en namespaces, mientras los cgroups contabilizan y limitan CPU, memoria y otros recursos. Capacidades, perfiles de seguridad y filtros de llamadas al sistema completan el control.

9.1. Namespaces y cgroups

Un namespace proporciona a un grupo de procesos una vista propia de recursos: identificadores de proceso, red, montajes, nombre de host, usuarios o comunicación entre procesos. Los procesos de un contenedor pueden ver su árbol de PID y sus interfaces, aunque el kernel siga siendo común. Los cgroups asignan límites y prioridades. Sin límites, un contenedor puede consumir memoria o CPU y afectar al nodo; por ello la configuración de solicitudes y límites es una parte esencial del diseño.

9.2. Imagen, contenedor y runtime

Una imagen es un artefacto inmutable compuesto por capas y metadatos. Un contenedor es una instancia en ejecución de esa imagen con una capa de escritura y una configuración. El runtime crea los namespaces, cgroups, sistema de ficheros y proceso inicial. La Open Container Initiative mantiene especificaciones para imagen, runtime y distribución, lo que permite interoperabilidad entre herramientas.

Las imágenes se identifican por nombre y etiqueta, pero para reproducibilidad debe conocerse su resumen criptográfico. Una etiqueta como latest puede cambiar; un digest referencia contenido concreto. Las capas compartidas reducen transferencias y almacenamiento, aunque una imagen con demasiadas capas o ficheros innecesarios aumenta superficie de ataque.

9.3. Contenedor frente a máquina virtual

La mayor ligereza del contenedor no lo hace automáticamente más seguro ni menos seguro. La frontera de aislamiento es distinta. Para código no confiable puede ser necesario reforzar con máquinas virtuales ligeras, runtimes aislados o nodos dedicados. Una práctica frecuente es ejecutar contenedores dentro de máquinas virtuales: la VM aporta separación de infraestructura y el contenedor aporta empaquetado y velocidad.

9.4. Persistencia y efimeridad

El sistema de ficheros escribible del contenedor debe considerarse efímero. Los datos persistentes se guardan en volúmenes o servicios externos. Los registros se envían a una plataforma central; no deben depender de entrar manualmente en una instancia. Esta separación permite reemplazar contenedores sin perder estado y favorece despliegues inmutables.

10. CONSTRUCCIÓN DE IMÁGENES, REGISTROS Y CADENA DE SUMINISTRO

La implantación sobre contenedores comienza antes de ejecutar el primer Pod. Debe existir una cadena controlada que transforme código fuente en una imagen verificable. El proceso incluye compilación, pruebas, análisis de dependencias, construcción, escaneo, firma, publicación y despliegue. Cada etapa produce evidencias para saber qué código, librerías y herramientas forman parte del artefacto.

10.1. Dockerfile y construcción reproducible

Un Dockerfile describe cómo construir una imagen. Las construcciones multietapa separan compilación y ejecución, evitando que compiladores y credenciales queden en la imagen final. La imagen base debe proceder de una fuente aprobada, mantenerse actualizada y fijarse de forma reproducible. En producción es recomendable referenciar una versión y, cuando el proceso lo soporte, un digest.

FROM python:3.13-slim AS runtime
WORKDIR /app

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY src/ ./src/
RUN useradd --system --uid 10001 appuser
USER 10001

EXPOSE 8080
CMD ["python", "-m", "src.api"]

El ejemplo crea un usuario sin privilegios y evita ejecutar como root. No obstante, un Dockerfile correcto no garantiza una imagen segura. Debe comprobarse que las dependencias son necesarias, que no se copiaron secretos, que el proceso escucha solo donde corresponde y que el sistema de ficheros puede montarse como solo lectura.

10.2. Registro de imágenes

El registro almacena manifiestos y capas y controla quién puede publicar o descargar. La distribución OCI normaliza el intercambio. Un registro corporativo debe integrar identidad, cifrado, retención, análisis de vulnerabilidades, replicación y auditoría. No debe permitirse desplegar directamente desde repositorios personales o imágenes sin procedencia conocida.

Las etiquetas promueven versiones entre entornos, pero no deben reescribirse de manera que la misma etiqueta represente contenidos diferentes sin trazabilidad. La promoción adecuada conserva el digest y añade metadatos de aprobación. La eliminación debe respetar retención y permitir reconstruir una versión durante el periodo requerido.

10.3. SBOM, firma y procedencia

Una lista de materiales de software o SBOM enumera componentes y versiones. Facilita responder si una vulnerabilidad afecta a una imagen. La firma vincula el artefacto con una identidad y la procedencia documenta qué proceso lo construyó. Estas medidas no sustituyen al análisis, pero reducen el riesgo de introducir artefactos manipulados.

La cadena debe aplicar mínimo privilegio. La herramienta de integración continua no necesita permisos administrativos permanentes sobre producción. Es preferible emitir credenciales temporales, separar proyectos y exigir aprobación para entornos críticos. Los secretos se obtienen en tiempo de ejecución desde un gestor, no se incorporan a la imagen ni a variables visibles en registros.

10.4. Actualización y gestión de vulnerabilidades

Una imagen inmutable no se parchea entrando en el contenedor. Se reconstruye con una base corregida y se redepliega. Por eso importa la velocidad de reconstrucción y la capacidad de identificar todas las cargas derivadas de una base. El escaneo debe realizarse al construir, al almacenar y periódicamente, porque una vulnerabilidad puede publicarse después de la construcción.

docker build -t registro.example/salud/api:1.0.0 .
docker image inspect registro.example/salud/api:1.0.0
docker push registro.example/salud/api:1.0.0

11. KUBERNETES: ARQUITECTURA Y OBJETOS FUNDAMENTALES

Kubernetes es una plataforma abierta y extensible para gestionar cargas y servicios contenedorizados mediante configuración declarativa y automatización. Un clúster consta de un plano de control y uno o varios nodos de trabajo. El plano de control mantiene el estado deseado; los controladores comparan ese estado con la realidad y actúan para converger.

11.1. Componentes del plano de control

• kube-apiserver: expone la API y constituye el punto de entrada de operaciones.
• etcd: almacena de forma consistente el estado del clúster.
• kube-scheduler: selecciona nodos para Pods pendientes según recursos y restricciones.
• kube-controller-manager: ejecuta controladores que reconcilian objetos.
• cloud-controller-manager: integra funciones específicas de infraestructura cuando procede.

El plano de control es crítico. Una copia de etcd debe estar cifrada, protegida y probada. El acceso a la API se autentica, autoriza y audita. Kubernetes no convierte automáticamente un clúster en multitenant seguro; deben diseñarse namespaces, RBAC, políticas de red, cuotas, admisión y aislamiento de nodos.

11.2. Componentes del nodo

El kubelet asegura que los Pods asignados se ejecuten. El runtime de contenedores, normalmente a través de CRI, descarga imágenes y crea contenedores. kube-proxy o una implementación equivalente mantiene reglas de red para los Services. Un plugin CNI proporciona conectividad de Pods y un plugin CSI integra almacenamiento.

11.3. Pod

El Pod es la unidad desplegable más pequeña de Kubernetes. Puede contener uno o varios contenedores estrechamente acoplados que comparten red y volúmenes. Lo habitual es un contenedor principal y, cuando se justifica, contenedores auxiliares. Los Pods son efímeros; no se administran normalmente de forma individual, sino mediante controladores.

11.4. Controladores de carga

• Deployment: administra aplicaciones replicadas, normalmente sin estado, mediante ReplicaSets.
• StatefulSet: proporciona identidad estable y orden para cargas con estado.
• DaemonSet: ejecuta una copia en cada nodo seleccionado, útil para agentes.
• Job: ejecuta una tarea hasta completarla.
• CronJob: programa Jobs periódicos.

11.5. Service e Ingress

Un Service proporciona un punto estable para acceder a uno o varios Pods seleccionados por etiquetas. Desacopla consumidores de direcciones efímeras. Ingress describe reglas HTTP y HTTPS, pero necesita un controlador que las implemente. Para otros protocolos se utilizan Services o pasarelas adecuadas. La exposición debe incorporar TLS, autenticación y limitación conforme al riesgo.

11.6. Configuración y secretos

ConfigMap almacena configuración no sensible; Secret representa datos sensibles, aunque su codificación base64 no constituye cifrado. Debe habilitarse cifrado en reposo, restringir RBAC y preferir integración con un gestor externo. Montar un secreto como fichero puede ser más seguro que exponerlo como variable visible a procesos o volcados, pero depende del caso.

12. IMPLANTACIÓN DECLARATIVA DE APLICACIONES Y SERVICIOS

Implantar una aplicación contenedorizada exige definir imagen, recursos, configuración, red, almacenamiento, identidad, observabilidad y estrategia de actualización. Kubernetes expresa estos elementos en objetos YAML enviados a la API. La configuración declarativa indica el estado deseado, y los controladores lo mantienen. El fichero debe versionarse y pasar por la misma revisión que el código.

12.1. Deployment y Service de ejemplo

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-citas
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-citas
  template:
    metadata:
      labels:
        app: api-citas
    spec:
      containers:
        - name: api
          image: registro.example/salud/api-citas:1.0.0
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "512Mi"
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
          livenessProbe:
            httpGet:
              path: /live
              port: 8080
          securityContext:
            runAsNonRoot: true
            readOnlyRootFilesystem: true
            allowPrivilegeEscalation: false
            capabilities:
              drop: ["ALL"]
---
apiVersion: v1
kind: Service
metadata:
  name: api-citas
spec:
  selector:
    app: api-citas
  ports:
    - port: 80
      targetPort: 8080

requests influyen en la planificación y reservan capacidad lógica; limits fijan máximos. La sonda de preparación impide enviar tráfico a una instancia que aún no está lista; la de vida permite reiniciar procesos bloqueados. No deben usarse sondas agresivas que reinicien una aplicación durante una sobrecarga temporal. Una sonda de arranque puede proteger aplicaciones lentas.

12.2. Aplicación y verificación

kubectl apply -f api-citas.yaml
kubectl rollout status deployment/api-citas
kubectl get pods -l app=api-citas
kubectl describe deployment api-citas

El uso interactivo de kubectl es útil para diagnóstico, pero producción debe desplegarse mediante canalización o GitOps, conservando aprobación y trazabilidad. Un cambio manual puede ser sobrescrito por el reconciliador o quedar fuera de auditoría.

12.3. Estrategias de actualización

El rolling update reemplaza réplicas gradualmente. Su seguridad depende de sondas, compatibilidad y capacidad adicional. Blue-green mantiene dos entornos y cambia el tráfico. Canary expone una versión a una fracción de usuarios y observa métricas. Ninguna estrategia resuelve por sí sola cambios incompatibles de base de datos; deben diseñarse migraciones expandir-contratar que permitan coexistencia temporal.

12.4. Estado y almacenamiento

Las aplicaciones sin estado son fáciles de reemplazar. Las cargas con estado requieren PersistentVolumes, clases de almacenamiento, copias y procedimientos de restauración. Un StatefulSet proporciona identidad estable, pero no convierte una base de datos en altamente disponible. La consistencia, replicación y recuperación siguen dependiendo del motor y de su operador.

12.5. Disponibilidad y autoscaling

El Horizontal Pod Autoscaler ajusta réplicas según métricas; el autoscaler de clúster ajusta nodos si la infraestructura lo permite. Escalar por CPU no siempre refleja la carga real. Una cola puede requerir una métrica de longitud; un servicio puede escalar por latencia. El escalado debe probarse para evitar oscilaciones y comprobar que las dependencias, como la base de datos, soportan el aumento de conexiones.

13. ARQUITECTURAS CLOUD-NATIVE: MICROSERVICIOS, SERVERLESS Y OPERADORES

Cloud-native describe prácticas orientadas a explotar automatización, elasticidad, resiliencia y entrega continua. No significa simplemente ejecutar una aplicación monolítica dentro de un contenedor. Un monolito bien estructurado puede ser más adecuado que una red de microservicios mal gobernada. La arquitectura debe responder al dominio, al tamaño del equipo y a los requisitos de cambio.

13.1. Microservicios

Los microservicios dividen una capacidad de negocio en servicios desplegables de forma independiente. Cada servicio debe poseer límites claros y evitar compartir directamente su base de datos. La comunicación síncrona mediante API es simple de entender, pero encadena disponibilidad y latencia; la comunicación asíncrona desacopla, aunque exige tratar duplicados, orden, reintentos y consistencia eventual.

La descomposición aumenta el número de despliegues, certificados, registros y fallos posibles. Requiere observabilidad distribuida, trazas, contratos de API, automatización y equipos con responsabilidad de extremo a extremo. El patrón circuit breaker evita insistir sobre una dependencia fallida; los tiempos de espera y reintentos deben coordinarse para no amplificar una incidencia.

13.2. API gateway y service mesh

Una API gateway concentra exposición externa, autenticación, limitación y enrutamiento. Un service mesh añade funciones de comunicación entre servicios mediante proxies o mecanismos equivalentes: identidad de carga, cifrado mutuo, telemetría y políticas. Estas capas aportan control, pero también consumo y complejidad. No deben introducirse sin un problema concreto.

13.3. Serverless y FaaS

En FaaS el desarrollador entrega funciones activadas por eventos y el proveedor administra ejecución y escalado. «Serverless» no significa que no existan servidores, sino que el consumidor no los administra. Es adecuado para tareas breves, integración y cargas variables. Deben considerarse límites de ejecución, arranque en frío, observabilidad, idempotencia y dependencia de eventos o API propietarias.

13.4. Operadores de Kubernetes

Un operador extiende Kubernetes con recursos y controladores que codifican conocimiento operativo de una aplicación. Puede automatizar despliegue, copia, actualización o conmutación de una base de datos. Un operador no debe aceptarse como caja negra: sus permisos, madurez, recuperación y compatibilidad deben evaluarse. Los CustomResourceDefinitions amplían la API y pueden convertirse en dependencia de plataforma.

13.5. Doce factores e inmutabilidad

Las aplicaciones cloud-native externalizan configuración, tratan procesos como desechables, escriben registros como flujos y separan construcción, publicación y ejecución. La configuración se inyecta por entorno; los artefactos son inmutables; y los servicios de apoyo se consumen mediante credenciales y endpoints. La aplicación debe apagarse de forma ordenada al recibir una señal y no depender de memoria local para mantener sesiones críticas.

13.6. Portabilidad real

Empaquetar en contenedores mejora portabilidad del proceso, pero no de todo el sistema. La aplicación puede depender de balanceadores, identidades, almacenamiento, colas, bases de datos y observabilidad. La portabilidad se diseña mediante estándares, capas de abstracción razonables, exportación de datos y pruebas periódicas de restauración en otro entorno. Intentar evitar cualquier servicio gestionado puede sacrificar demasiado valor; la decisión debe ser consciente y documentada.

14. SEGURIDAD, PRIVACIDAD Y CUMPLIMIENTO EN CLOUD Y CONTENEDORES

La seguridad en cloud se basa en el modelo de responsabilidad compartida. El proveedor protege determinadas capas y el cliente otras, según el servicio. En IaaS el cliente conserva más obligaciones técnicas; en SaaS delega más operación, pero mantiene identidad, configuración, uso legítimo, clasificación y supervisión contractual. La frontera debe documentarse control por control.

14.1. Identidad y mínimo privilegio

La identidad es el nuevo perímetro. Deben centralizarse autenticación, MFA, federación y ciclo de vida de cuentas. Las identidades de máquinas y cargas necesitan el mismo rigor que las humanas. Las credenciales permanentes se sustituyen por tokens temporales y roles. El acceso privilegiado debe ser justificado, temporal y auditado. En Kubernetes, RBAC se diseña por namespace y función; conceder cluster-admin a una canalización contradice el mínimo privilegio.

14.2. Red y exposición

Las redes virtuales se segmentan por función y sensibilidad. Los servicios gestionados se consumen, cuando sea posible, mediante endpoints privados. Las políticas de red restringen tráfico este-oeste; por defecto, un clúster sin políticas puede permitir comunicación amplia entre Pods. La salida a Internet también debe controlarse para impedir exfiltración y descargas no autorizadas.

14.3. Cifrado y gestión de claves

Los datos se cifran en tránsito y reposo, pero el control efectivo depende de las claves. Debe decidirse si las claves son del proveedor, gestionadas por el cliente o externas; quién puede usarlas; cómo se rotan; y qué ocurre al revocar. Cifrar un disco no protege frente a una aplicación comprometida que accede legítimamente a datos descifrados. Por eso se combina con identidad, segmentación, minimización y detección.

14.4. Seguridad de contenedores

NIST SP 800-190 agrupa riesgos en imágenes, registros, orquestadores, contenedores y sistema operativo host. Las medidas incluyen usar imágenes mínimas, escanear, firmar, limitar privilegios, separar cargas por sensibilidad, proteger el runtime y mantener el host. Los contenedores no deben ejecutarse como privilegiados salvo necesidad excepcional. Deben eliminarse capacidades, impedir escalada y montar sistemas de ficheros como solo lectura cuando sea posible.

14.5. Datos de salud y RGPD

Los datos relativos a la salud son una categoría especial conforme al artículo 9 del RGPD. Su tratamiento requiere base jurídica, finalidad, minimización, medidas apropiadas y evaluación de riesgos. El uso de cloud no cambia la condición de responsable y encargado. El contrato debe regular instrucciones, confidencialidad, subencargados, asistencia, notificación de brechas, devolución y supresión. Las transferencias internacionales deben evaluarse conforme al marco vigente.

14.6. Esquema Nacional de Seguridad

Los sistemas del sector público incluidos en el ámbito del Real Decreto 311/2022 deben aplicar el ENS. La contratación de un servicio cloud no desplaza esta obligación. Debe categorizarse el sistema por impacto en confidencialidad, integridad, trazabilidad, autenticidad y disponibilidad, aplicar medidas y obtener las evidencias correspondientes. La certificación del proveedor puede apoyar, pero no sustituye el análisis del sistema completo ni la correcta configuración del cliente.

Las guías ISO/IEC 27017 y ISO/IEC 27018:2025 aportan controles para servicios cloud y protección de información personal cuando el proveedor actúa como encargado. Son complementarias a las obligaciones legales y al ENS, no alternativas.

14.7. Copias, ransomware y recuperación

La alta disponibilidad protege frente a fallos de componentes; las copias protegen frente a borrado, corrupción y ransomware. Deben existir copias independientes, protegidas contra modificación por las mismas credenciales, con retención y restauraciones probadas. En contenedores se respaldan datos persistentes, configuración declarativa, secretos de forma segura y estado de servicios críticos; no tiene sentido copiar contenedores efímeros como si fueran servidores artesanales.

15. DISPONIBILIDAD, CONTINUIDAD, OBSERVABILIDAD Y OPERACIÓN

La nube ofrece mecanismos de resiliencia, pero la disponibilidad de una aplicación depende de su arquitectura. Un SLA del proveedor mide un componente bajo condiciones contractuales; no garantiza el proceso asistencial completo. Deben identificarse dependencias y definir RTO, tiempo máximo para recuperar, y RPO, pérdida máxima de datos admisible. Ambos objetivos condicionan replicación, copias, diseño y coste.

15.1. Diseñar para el fallo

Las instancias deben considerarse reemplazables. Los servicios críticos distribuyen réplicas entre dominios de fallo y evitan estado local. Los clientes usan tiempos de espera, reintentos con retroceso y circuit breakers. Los reintentos deben ser seguros: una operación no idempotente puede duplicar una prescripción, una cita o un cargo si se repite sin identificador.

15.2. Plan de recuperación

El plan define responsables, comunicaciones, secuencia y criterios de declaración. La recuperación de una aplicación no termina al arrancar máquinas; hay que validar datos, integraciones, colas y accesos. Un procedimiento no probado es una hipótesis. Los ejercicios deben incluir pérdida de región, indisponibilidad de identidad, corrupción lógica y compromiso de credenciales, no solo fallo de un servidor.

15.3. Métricas, registros y trazas

Las métricas permiten alertar por síntomas: errores, latencia, saturación y tráfico. Los registros explican eventos; las trazas conectan una solicitud entre servicios. Todos deben incluir tiempo sincronizado, identificadores de correlación y contexto suficiente, evitando registrar datos de salud innecesarios. La retención se define por necesidad operativa, normativa y coste.

15.4. Gestión de cambios

La infraestructura como código y GitOps permiten revisar cambios y revertir manifiestos. Sin embargo, revertir código no siempre revierte datos. Las migraciones de esquema requieren compatibilidad hacia adelante y atrás. Las ventanas deben coordinarse con criticidad asistencial y disponer de criterios de abortar. La entrega continua no implica desplegar sin control; significa automatizar evidencias y reducir el tamaño del cambio.

15.5. Operación de Kubernetes

Operar Kubernetes incluye actualizar plano de control y nodos, renovar certificados, mantener plugins, validar compatibilidad, gestionar capacidad y recuperar etcd. Un servicio gestionado delega parte de estas tareas, pero no la configuración de cargas. Deben existir versiones soportadas, política de deprecaciones y pruebas previas. Las API retiradas pueden bloquear una actualización si los manifiestos no se modernizan.

15.6. Caos y pruebas

La ingeniería de caos introduce fallos controlados para verificar hipótesis: pérdida de Pod, nodo, red o dependencia. En sanidad se realiza con alcance y seguridad estrictos, preferentemente en preproducción y con mecanismos de parada. Su propósito no es provocar incidentes, sino descubrir dependencias antes de que un fallo real afecte al servicio.

16. GOBIERNO, FINOPS, CONTRATACIÓN Y ESTRATEGIA DE MIGRACIÓN

La facilidad de crear recursos exige un gobierno más fuerte, no más débil. El gobierno cloud define quién puede desplegar, dónde, con qué patrones, etiquetas, redes, claves y límites. Una landing zone establece cuentas o suscripciones, identidad, conectividad, registro, seguridad y políticas antes de alojar cargas. Sin esta base, cada proyecto construye su propia nube y aumenta el riesgo.

16.1. FinOps y control económico

FinOps combina responsabilidad técnica y financiera. El coste se observa por servicio, producto y entorno. Las etiquetas permiten atribución; los presupuestos y alertas detectan desviaciones; y el dimensionamiento elimina recursos ociosos. Ahorrar no significa apagar indiscriminadamente: la capacidad de reserva, recuperación y pruebas forma parte del servicio. Deben analizarse costes de salida de datos, almacenamiento de copias, observabilidad, soporte y licencias.

En nube privada también existe coste marginal aunque no llegue una factura por cada hora. La medición revela consumo y evita que proyectos reserven capacidad sin usar. Showback informa; chargeback imputa. Ambos requieren métricas fiables y reglas comprensibles.

16.2. Lock-in y reversibilidad

La dependencia del proveedor puede surgir en API, formatos, bases de datos, identidad, herramientas y conocimiento. No todo lock-in es negativo: un servicio gestionado puede aportar valor superior al coste de salida. La decisión debe documentar el nivel de dependencia, la criticidad, la exportación y el plan de reversibilidad. La portabilidad debe probarse; una cláusula contractual sin prueba técnica puede resultar insuficiente.

16.3. Contratación cloud

El pliego debe especificar niveles de servicio, soporte, localización, subcontratación, auditoría, notificación de incidentes, continuidad, copias, devolución, borrado, interoperabilidad y salida. Debe evitar ambigüedades entre disponibilidad de infraestructura y disponibilidad de aplicación. La estructura de precios necesita escenarios de crecimiento y mecanismos para evitar consumo no autorizado.

16.4. Estrategias de migración

Las denominadas «R» de migración ayudan a decidir por carga:

• Rehost: mover casi sin cambios a IaaS.
• Replatform: introducir cambios limitados, por ejemplo una base gestionada.
• Refactor: rediseñar para servicios cloud-native.
• Repurchase: sustituir por SaaS.
• Retain: mantener temporalmente donde está.
• Retire: retirar lo que ya no aporta valor.

Rehost es rápido, pero puede trasladar deuda técnica y no aprovechar elasticidad. Refactor ofrece beneficios, pero aumenta coste y riesgo. Una cartera sanitaria requiere secuenciar por criticidad, obsolescencia, dependencia, datos y capacidad de los equipos. Antes de migrar se descubre la aplicación: interfaces, ventanas, volúmenes, latencia, licencias, responsables y procedimientos.

16.5. Evaluación previa

Para cada carga deben responderse al menos estas cuestiones: qué información trata; qué categoría ENS tiene el sistema; cuál es el RTO/RPO; qué integraciones usa; qué latencia tolera; qué licencias la limitan; cómo se exportan datos; quién opera 24×7; cómo se prueba la recuperación; y cuál es el coste a varios años. El resultado puede ser nube pública, privada, híbrida o permanencia temporal.

17. APLICACIÓN EN EL SERVICIO ANDALUZ DE SALUD Y EL SSPA

La I Estrategia de Salud Digital de Andalucía 2024-2028 sitúa la transformación digital, el gobierno del dato, la interoperabilidad, la ciberseguridad y la modernización de sistemas entre los elementos del cambio sanitario. La estrategia menciona expresamente los servicios en la nube como tecnología que permite implementar capacidad con rapidez, adaptar recursos a necesidades variables y disponer de mayor cómputo y almacenamiento. Esta referencia institucional justifica que el personal TFA-STI conozca los modelos cloud, pero no acredita por sí misma que un sistema concreto del SAS utilice un proveedor o producto determinado.

17.1. Criterios sanitarios de selección

Los sistemas asistenciales pueden afectar directamente a la continuidad de la atención. La selección de nube debe partir del proceso, no de la moda tecnológica. Un servicio de cita, una plataforma analítica y un sistema que soporta medicación tienen impactos distintos. Deben valorarse disponibilidad, latencia, modo degradado, integridad, trazabilidad, confidencialidad y capacidad de recuperación. La dependencia de comunicaciones externas es relevante para centros con conectividad variable.

17.2. Datos clínicos y analítica

La nube puede aportar capacidad para analítica, integración y procesamiento temporal, pero los datos de salud exigen gobierno. Antes de moverlos se define finalidad, minimización, seudonimización cuando proceda, control de acceso, localización, retención y borrado. La anonimización no consiste en eliminar un identificador directo; debe impedir razonablemente la reidentificación considerando el conjunto de datos y fuentes auxiliares.

17.3. Desarrollo y pruebas

Los entornos temporales son un caso favorable para automatización cloud: se crean desde código, ejecutan pruebas y se destruyen. No deben usar copias de producción sin protección. Los datos sintéticos o adecuadamente seudonimizados reducen riesgo. La canalización debe impedir desplegar una imagen no aprobada y registrar qué versión llegó a cada entorno.

17.4. Contenedores para nuevas aplicaciones

Los contenedores pueden facilitar una plataforma común para API y servicios, siempre que exista un equipo de plataforma, registro, observabilidad, seguridad y operación. Kubernetes no debe implantarse como un conjunto de clústeres independientes por centro sin gobierno. La estandarización de plantillas, namespaces, identidad y red reduce variabilidad y permite aplicar políticas corporativas.

17.5. Hiperconvergencia y CPD

HCI puede simplificar renovación de infraestructura y consolidar virtualización, especialmente donde una arquitectura tradicional de servidores y cabinas sea compleja de mantener. Su conveniencia depende de perfil de cargas, crecimiento y recuperación. Debe integrarse con la planificación de CPD del tema anterior: energía, refrigeración, red, soporte y continuidad siguen siendo necesarios.

17.6. Contexto de la Junta de Andalucía

La Agencia Digital de Andalucía impulsa instrumentos de transformación, ciberseguridad e infraestructuras digitales. En el ámbito autonómico se ha trabajado en la formulación de una Estrategia Cloud de Andalucía 2030. Para el opositor es importante distinguir la iniciativa estratégica de una versión final o de una arquitectura concreta del SAS. Las decisiones operativas deben basarse en documentos vigentes, contratos y estándares corporativos.

17.7. Modelo de decisión recomendado

1. Clasificar proceso, datos y criticidad.
2. Definir requisitos de servicio, RTO, RPO y modo degradado.
3. Determinar obligaciones ENS, RGPD, interoperabilidad y archivo.
4. Comparar IaaS, PaaS, SaaS y permanencia on-premise.
5. Evaluar privada, pública, híbrida o comunitaria.
6. Diseñar identidad, red, claves, logs, copias y reversibilidad.
7. Realizar piloto con datos controlados y criterios medibles.
8. Validar operación, soporte y recuperación antes de producción.

18. CONCLUSIONES, IDEAS CLAVE Y MAPA CONCEPTUAL

Cloud computing es un modelo de consumo y operación, no una ubicación. Las cinco características NIST permiten separar nube de alojamiento tradicional. IaaS entrega infraestructura y deja al cliente sistema operativo y aplicación; PaaS entrega plataforma y deja código y datos; SaaS entrega la aplicación completa, aunque el cliente conserva responsabilidad sobre identidades, configuración y uso de la información.

Las nubes privadas son exclusivas de una organización; las públicas sirven a múltiples consumidores; las híbridas conectan entornos diferenciados; y las comunitarias comparten requisitos. Multicloud describe varios proveedores, pero aumenta complejidad. La elección debe basarse en datos, criticidad, integración, coste y reversibilidad.

La virtualización de servidores abstrae hardware mediante un hipervisor. La migración en vivo, HA y snapshots resuelven problemas diferentes. La hiperconvergencia integra cómputo, almacenamiento definido por software y gestión en nodos escalables. Simplifica operación, pero no elimina dimensionamiento, dominios de fallo ni lock-in.

Los contenedores aíslan procesos y comparten kernel. Una imagen es un artefacto; un contenedor es su instancia. OCI normaliza imagen, runtime y distribución. Kubernetes administra el estado deseado mediante API, controladores, Pods, Deployments, Services y otros objetos. Para cargas con estado, un StatefulSet ofrece identidad, no la disponibilidad de la base de datos por sí mismo.

La seguridad debe cubrir identidad, red, claves, imágenes, registro, runtime, orquestador y host. Los datos de salud requieren protección reforzada; el ENS y el RGPD se aplican al sistema completo. Alta disponibilidad, réplica y backup no son equivalentes. RTO es tiempo de recuperación y RPO es pérdida de datos.

En el SSPA, cloud aparece como tecnología habilitadora de la Estrategia de Salud Digital, pero no deben memorizarse arquitecturas o proveedores concretos sin fuente oficial vigente. El TFA-STI debe saber diseñar criterios, gobernar, contratar, medir y asegurar servicios, además de conocer los productos.

18.1. Mapa conceptual de síntesis