Cloud Computing
Resumen
Esta guía de estudio independiente presenta los fundamentos de la computación en la nube para la certificación LFCA.
No está afiliada ni avalada por la Linux Foundation ni por ningún proveedor.
El objetivo es construir un modelo mental sólido: qué es la nube, qué la define, cómo se reparten las responsabilidades y cómo elegir un modelo de servicio o de despliegue. AWS, Microsoft Azure y Google Cloud se citan solo como ejemplos; el examen evalúa conceptos.
La nube no es "servidores conectados a Internet". Es un modelo en el que cómputo, almacenamiento y red se aprovisionan mediante interfaces programables, se pagan según consumo y se gestionan con automatización.
Objetivos de aprendizaje
- Enunciar las características esenciales del modelo NIST y explicar por qué importan.
- Distinguir IaaS, PaaS y SaaS por nivel de control y responsabilidad operativa.
- Comparar nube pública, privada, híbrida y multicloud con criterios técnicos y de negocio.
- Aplicar el modelo de responsabilidad compartida a un servicio concreto.
- Detectar afirmaciones incorrectas sobre elasticidad, multitenencia y seguridad.
Prerrequisitos y conexiones
Se apoya en los fundamentos de Linux y administración de sistemas de los dominios anteriores. Conecta con performance-availability (cómo se mide el servicio), budgeting (cómo se paga el consumo), cloud-best-practices (gobernanza) y cloud-networking (aislamiento y conectividad).
Definición y características esenciales
NIST SP 800-145 describe la nube como un modelo para habilitar acceso de red ubicuo, conveniente y bajo demanda a un conjunto compartido de recursos configurables que se aprovisionan y liberan con esfuerzo mínimo. Enumera cinco características:
- Autoservicio bajo demanda. El consumidor aprovisiona capacidad sin intervención humana del proveedor.
- Acceso amplio por red. Los recursos están disponibles mediante mecanismos estándar desde distintos dispositivos.
- Agrupación de recursos. El proveedor comparte capacidad entre consumidores mediante multitenencia, con aislamiento lógico.
- Elasticidad rápida. La capacidad se ajusta hacia arriba y hacia abajo según la demanda.
- Servicio medido. El uso se mide y se factura, lo que permite transparencia y control.
Conviene separar escalabilidad y elasticidad. La primera es la capacidad de crecer; la segunda es hacerlo de forma automática y reversible, ajustando también hacia abajo para no pagar capacidad ociosa. Un sistema puede ser escalable de forma manual y no ser elástico. La multitenencia tampoco implica falta de aislamiento: se separa con redes virtuales, identidades, cifrado y controles de acceso.
Los proveedores implementan esto con regiones y zonas de disponibilidad o dominios de fallo. Una región es una ubicación geográfica; una zona agrupa infraestructura de energía y red relativamente independiente.
Criterios para reconocer la nube
Se puede comprobar si un entorno cumple el modelo con preguntas concretas: ¿el usuario final aprovisiona capacidad por sí mismo y en minutos? ¿La capacidad se libera o se amplía sin pedir presupuesto a una persona? ¿El consumo queda registrado con una métrica facturable por unidad de tiempo o de operación? ¿Los recursos se comparten entre inquilinos con aislamiento lógico? Un entorno que responde "no" a las dos primeras es un centro de datos automatizado, no una nube en el sentido de NIST.
Un centro de datos virtualizado puede ofrecer plantillas y catálogos internos, pero sin autoservicio ni medición carece de dos de las cinco características esenciales. Por el contrario, una infraestructura operada en las instalaciones de la organización puede cumplirlas todas si se amplía y se factura con el mismo flujo que una nube pública. La distinción depende del modo de operar, no de la ubicación del hardware.
Abstracción: virtualización, contenedores y funciones
La agrupación de recursos se apoya en la virtualización: un hipervisor reparte CPU, memoria y red entre máquinas virtuales con su propio sistema operativo. Cada VM lleva una copia completa del sistema invitado, lo que aísla bien y permite versiones distintas por máquina, a cambio de consumir memoria y de arrancar más despacio que un contenedor.
Los contenedores empaquetan la aplicación con sus dependencias y comparten el kernel del sistema anfitrión. Arrancan casi de inmediato y aprovechan mejor la densidad de las máquinas, pero el aislamiento es lógico y depende de primitivas del kernel, de modo que la homogeneidad de la base importa. En la práctica conviven: las máquinas virtuales sostienen los nodos y los contenedores empaquetan el software que se despliega sobre ellos.
Las funciones gestionadas por eventos llevan la abstracción más lejos: el equipo publica código, el proveedor asigna recursos durante la invocación y devuelve el resultado. Desaparece la administración de servidores, pero aparecen límites de ejecución, tiempos máximos y una facturación por invocación que conviene modelar antes de adoptar el patrón.
| Aspecto | Máquina virtual | Contenedor | Función por evento |
|---|---|---|---|
| Unidad de despliegue | Imagen con sistema operativo | Imagen con aplicación y dependencias | Código versionado |
| Tiempo de puesta en marcha | Segundos o minutos | Milisegundos a segundos | Asignación durante la invocación |
| Aislamiento | Fuerte, por separación de máquina | Lógico, compartiendo el kernel | Gestionado por el proveedor |
| Operación de la base | El cliente parchea el sistema invitado | El cliente mantiene la imagen base | Invisible para el cliente |
Modelos de servicio
| Modelo | El proveedor gestiona | El cliente gestiona | Ejemplo |
|---|---|---|---|
| IaaS | Virtualización, cómputo, almacenamiento y red | Sistema operativo, runtime, aplicación y datos | Máquinas virtuales |
| PaaS | También sistema operativo y runtime | Código, configuración y datos | Plataforma gestionada |
| SaaS | Toda la pila hasta la aplicación | Uso, identidades, datos y configuración | Correo o CRM |
En IaaS el cliente alquila infraestructura y conserva control alto, incluido el parcheo del sistema operativo. Sirve para cargas que necesitan personalización, software heredado o control del kernel. En PaaS el cliente se concentra en código y datos; el proveedor gestiona runtime y escalado. Reduce carga operativa, pero puede limitar el control de versiones y aumentar la dependencia. En SaaS se consume una aplicación completa; la responsabilidad se desplaza a configuración, identidad y protección de datos.
La frontera no siempre es nítida. Los contenedores gestionados y las funciones serverless combinan rasgos de PaaS con ejecución por evento. Lo importante es razonar sobre la frontera de responsabilidad, no memorizar un catálogo.
Selección por escenario
La elección se puede ordenar según la operación que el equipo quiera asumir. Un sitio corporativo con tráfico predecible vive bien en SaaS o PaaS; una herramienta estándar de negocio se consume como SaaS, donde la configuración y la integración son la palanca principal.
IaaS frente a PaaS se decide por el coste de mantener la base: quien opera el sistema asume inventario de vulnerabilidades, ventanas de parcheo y capacidad reservada; quien lo delega compra tiempo de equipo a cambio de menos control. PaaS frente a SaaS traslada también la lógica de negocio al proveedor, de modo que el trabajo se reduce a configurar, integrar y vigilar el consumo.
| Pregunta de decisión | IaaS | PaaS | SaaS |
|---|---|---|---|
| Cuándo elegirlo | Requisitos especiales de la máquina | Publicar código sin operar la plataforma | Proceso estándar cubierto por un producto |
| Qué se renuncia | Comodidad de la plataforma | Control de versiones del runtime | Personalización del producto |
| Riesgo dominante | Base desactualizada | Dependencia del runtime ofrecido | Salida difícil de los datos |
| Quién opera el día a día | El equipo cliente | El proveedor, con supervisión del cliente | El proveedor, con configuración del cliente |
Modelos de despliegue
La nube pública ofrece recursos compartidos a través de Internet bajo un modelo de proveedor. La nube privada se dedica a una organización y puede estar en sus instalaciones o ser operada por un tercero; por tanto, "privada" no equivale siempre a "on-premises". La híbrida combina entornos y los conecta con redes, identidad y herramientas comunes. Multicloud describe el uso de más de un proveedor, con o sin integración profunda.
La decisión no es ideológica. Una empresa regulada puede mantener datos sensibles en un entorno privado y usar la nube pública para análisis. Una startup puede empezar en pública y adoptar híbrida tras adquirir un centro de datos. Los criterios reales son cumplimiento, latencia, portabilidad, coste total, competencias y dependencia del proveedor.
| Dimensión | Pública | Privada | Híbrida |
|---|---|---|---|
| Tenencia del hardware | Proveedor | Organización o tercero | Mixta |
| Capacidad adicional | Inmediata y elástica | Limitada a lo instalado | Amplia fuera del núcleo privado |
| Tipo de coste | Variable por consumo | Predominantemente fijo | Fijo y variable a la vez |
| Consecuencia de una previsión errónea | Se paga lo consumido | Se paga lo comprado | Ambas a la vez |
| Operación diaria | Modelo compartido con el proveedor | Equipo propio o contratado | Dos operaciones que deben coordinarse |
La combinación híbrida aparece cuando dos restricciones conviven: información que debe quedarse en un lugar concreto y servicios que solo existen en la nube pública. El diseño separa qué se ejecuta dónde y define qué se cruza entre ambos lados, normalmente identidad, red privada y copias periódicas; cada cruce añade una operación que alguien tiene que mantener.
Responsabilidad compartida
El proveedor es responsable de la seguridad de la nube: instalaciones, hardware, red física y la capa que gestiona. El cliente es responsable de la seguridad en la nube: datos, identidades, configuraciones y, según el servicio, sistema operativo y runtime.
La frontera se mueve con el modelo. En IaaS el cliente parchea el sistema operativo invitado; en PaaS el proveedor suele gestionar el runtime, pero el cliente sigue siendo responsable del código, los permisos y los datos; en SaaS no se administra la aplicación, pero sí se decide quién accede y cómo se clasifica la información. AWS, Azure y Google Cloud publican variantes de este modelo. "Gestionado" no significa "sin responsabilidades de seguridad".
La frontera se puede comprobar capa a capa:
| Capa | IaaS | PaaS | SaaS |
|---|---|---|---|
| Datos, cifrado y copias | Cliente | Cliente | Cliente |
| Identidades, permisos y configuración | Cliente | Cliente | Cliente |
| Sistema operativo y parches | Cliente | Proveedor | Proveedor |
| Runtime y middleware | Cliente | Proveedor | Proveedor |
| Lógica de la aplicación | Cliente | Depende del servicio | Proveedor |
| Hipervisor, red física y edificio | Proveedor | Proveedor | Proveedor |
Un caso típico es la base de datos gestionada: desaparece el parcheo del motor, pero siguen siendo del cliente la revisión de grupos de acceso, la política de cifrado, la retención de copias y el dimensionamiento. En el extremo de IaaS, la lista de tareas propias va más allá del parcheo: registro de eventos, capacidad de almacenamiento, permisos locales y respaldo del sistema invitado quedan pendientes desde el primer arranque.
Portabilidad y dependencia del proveedor
La dependencia aparece cuando cambiar de proveedor cuesta más de lo previsto. No procede solo de la infraestructura: las APIs administrativas, las identidades con sus políticas, las colas y bases gestionadas, las plantillas de imagen y los datos ya almacenados generan inercia. La información es el ancla más pesada, porque moverla exige tiempo de transferencia, validación y una ventana en la que conviven los dos orígenes.
La respuesta combina técnica y organización. Empaquetar la aplicación en contenedores, describir la infraestructura con scripts versionados y evitar diseñar en torno a funcionalidades exclusivas de un proveedor reducen el coste de salida; a cambio, se renuncia a servicios gestionados que ahorran operación. La decisión correcta no es eliminar la dependencia, sino estimar cuánto costaría el cambio y quién lo asumiría.
Conviene distinguir la dependencia de inversión de la dependencia de datos: reemplazar instancias es viable en días, reescribir una aplicación que consume cinco APIs propietarias no lo es en el corto plazo. Un inventario de los servicios usados, con una alternativa anotada por cada uno, convierte la discusión en una comparación y no en una preferencia.
Aprovisionamiento automatizado
La nube se gobierna mediante APIs y el aprovisionamiento manual no escala ni deja rastro. La infraestructura como código describe los recursos en archivos versionados que se revisan y se aplican de forma repetible, de modo que un entorno se reconstruye tras un error y se replica entre regiones sin depender de la memoria de una persona.
La adopción exige aprender un modelo declarativo y mantenerlo al día, pero a cambio la configuración deja de vivir en capturas de pantalla y correos. Es el mecanismo que materializa el autoservicio de NIST: quien dispone de un catálogo y de credenciales aprovisiona sin intervención humana del proveedor.
Ejemplos prácticos
Startup que publica una API web. Con IaaS administraría sistema operativo, parches y escalado. Con PaaS despliega el código y delega gran parte de la operación, a cambio de menos control del runtime. La decisión depende de las competencias del equipo y de la portabilidad deseada.
Hospital con requisitos de residencia de datos. Puede usar un entorno privado o una región de nube pública con controles de residencia, y conectar ambos mundos con una red híbrida. El requisito legal manda sobre la preferencia tecnológica.
Empresa que usa correo SaaS. El proveedor protege la infraestructura y la aplicación, pero la empresa sigue siendo responsable de las cuentas, la autenticación multifactor, el uso compartido y la clasificación de la información.
Laboratorio de datos que necesita aceleración puntual. El equipo no quiere comprar hardware dedicado, así que lanza instancias especializadas solo durante los experimentos y las libera al terminar; el pago por consumo convierte una inversión mayor en un gasto ajustado al calendario de pruebas.
Departamento que compra una herramienta sin pasar por TI. La aplicación SaaS funciona, pero las cuentas se crearon con tarjetas personales y sin protocolo de salida. Cuando el equipo responsable cambia de puesto, el activo sigue ahí con datos de la empresa y sin dueño definido; el problema no es técnico, sino de identidad y gobernanza.
Errores frecuentes
- Confundir elasticidad con escalabilidad. La elasticidad implica automatización y ajuste en ambos sentidos.
- Creer que la nube elimina el parcheo. En IaaS el sistema operativo invitado sigue siendo del cliente.
- Asumir que la nube siempre es más barata. Depende del patrón de uso y de la disciplina operativa.
- Identificar nube privada con centro de datos propio. Puede ser operada por un tercero.
- Elegir IaaS por reflejo. Sin necesidad de control del sistema operativo, PaaS o SaaS reducen riesgo.
- Tratar los servicios homónimos como intercambiables. Dos productos con el mismo nombre en proveedores distintos difieren en cuotas, modelos de red y configuración por defecto.
- Decidir el modelo antes de medir el trabajo. Sin datos de uso, de residencia de datos y de competencias del equipo, la elección es una preferencia.
Puntos clave para el examen
- NIST SP 800-145 define cinco características esenciales.
- IaaS, PaaS y SaaS se distinguen por la frontera de gestión, no por la ubicación de los servidores.
- La responsabilidad compartida cambia según el servicio; el cliente nunca deja de responder de sus datos y accesos.
- Pública, privada, híbrida y multicloud son modelos de despliegue, no sinónimos de ubicación.
- La elasticidad es una capacidad operativa y económica, no solo técnica.
- Las cinco características de NIST distinguen la nube de un centro de datos con virtualización.
- La virtualización, los contenedores y las funciones son capas de abstracción con distinto grado de operación delegada.
- Elegir IaaS, PaaS o SaaS es decidir qué capa opera el equipo y con qué grado de independencia se queda.
- La portabilidad depende de datos, identidades y APIs propietarias, no de la ubicación del hardware.
- La infraestructura como código convierte el aprovisionamiento manual en un proceso repetible y revisable.
Recursos externos
- NIST SP 800-145: https://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-145.pdf
- AWS, Shared Responsibility Model: https://aws.amazon.com/compliance/shared-responsibility-model/
- Microsoft Azure, Shared responsibility: https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
- Google Cloud, Shared responsibility and security: https://cloud.google.com/security/shared-responsibility
Autoevaluación
1. ¿Cuál es una característica esencial del modelo NIST?
Respuesta: El autoservicio bajo demanda.
Justificación: NIST incluye autoservicio, acceso amplio por red, agrupación de recursos, elasticidad rápida y servicio medido. El pago fijo anual contradice el modelo.
2. Un equipo quiere controlar sistema operativo y runtime, pero delegar virtualización y red física. ¿Qué modelo encaja?
Respuesta: IaaS.
Justificación: El proveedor gestiona la infraestructura virtualizada y el cliente conserva el sistema operativo y la aplicación. PaaS delegaría también el runtime.
3. En SaaS, ¿qué sigue siendo responsabilidad del cliente?
Respuesta: Identidades, accesos y datos.
Justificación: El proveedor protege la aplicación, pero el cliente decide quién entra, con qué permisos y cómo comparte su información.
4. ¿Qué diferencia a híbrida de multicloud?
Respuesta: La híbrida integra entornos públicos y privados con controles comunes; multicloud usa varios proveedores, con o sin integración.
Justificación: El criterio de la híbrida es la conexión y operación coherente. Multicloud describe pluralidad de proveedores, no necesariamente integración.
5. Un servicio crece automáticamente y se reduce de noche. ¿Qué característica describe?
Respuesta: Elasticidad.
Justificación: Ajusta la capacidad de forma automática y reversible. La escalabilidad solo indica que el sistema puede crecer, aunque sea manualmente.
6. Un centro de datos con plantillas y virtualización, pero con aprovisionamiento por ticket. ¿Cumple el modelo NIST?
Respuesta: No, porque carece de autoservicio bajo demanda.
Justificación: Las plantillas agilizan el trabajo, pero si una persona aprovisiona y aprueba cada recurso, desaparece una de las cinco características esenciales, aunque la virtualización esté presente.
7. Un servicio pasa de máquinas virtuales a contenedores. ¿Qué cambia en la operación?
Respuesta: El equipo deja de parchear un sistema invitado por máquina y pasa a mantener la imagen base y el kernel compartido.
Justificación: El contenedor comparte el kernel del anfitrión, así que el aislamiento depende de la configuración del nodo; a cambio, el arranque es más rápido y la densidad de las máquinas aumenta.
8. ¿Dónde está realmente la dependencia de un proveedor?
Respuesta: En los datos, las identidades con sus políticas y las APIs administrativas que consume la aplicación.
Justificación: Cambiar instancias es rápido; exportar información, recrear permisos y sustituir servicios propietarios consumen meses de trabajo que rara vez se presupuestan.
9. ¿Qué aporta describir la infraestructura en archivos versionados?
Respuesta: Permite reconstruir y replicar entornos de forma repetible, con revisión de cambios incluida.
Justificación: La configuración deja de depender de pasos manuales y queda bajo control de versiones; es el puente entre el autoservicio y la trazabilidad de lo desplegado.
10. Un equipo elige PaaS pero necesita fijar versiones del runtime. ¿Qué debe comprobar?
Respuesta: Qué versiones ofrece la plataforma y con qué ritmo las actualiza el proveedor.
Justificación: PaaS delega el runtime, y con ello el control de versiones; si la aplicación exige una versión concreta, ese es precisamente el punto que la plataforma gestionada no garantiza.