Inicio/Glosario/Infraestructura cloud
Infraestructura técnicaInfraestructura cloud
La infraestructura cloud es el conjunto de cómputo, almacenamiento, red y virtualización que un proveedor opera en sus centros de datos y entrega bajo demanda por internet, de modo que se consume sin comprar ni mantener hardware propio. Sobre ella se construyen los modelos de servicio IaaS, PaaS y SaaS, que se diferencian por dónde cae la línea de responsabilidad entre proveedor y cliente.
Qué es
La infraestructura cloud es la capa de recursos físicos y virtuales —servidores, almacenamiento, red y virtualización— que un proveedor (Google Cloud, AWS, Azure) opera en sus centros de datos y sirve por internet. La organización los consume bajo demanda, sin invertir en hardware ni mantenerlo. El modelo de coste cambia: pago por uso o suscripción en lugar de inversión fija.
Sobre esa base se ordenan tres modelos de servicio según cuánto gestiona el proveedor, lo que se conoce como responsabilidad compartida. En IaaS (infraestructura como servicio) el proveedor aporta servidores, almacenamiento, red y virtualización; el cliente gestiona sistema operativo, runtime y aplicación —por ejemplo AWS EC2, Google Compute Engine o Azure VMs—. En PaaS (plataforma como servicio) el proveedor sube un escalón y gestiona también SO, runtime y middleware; el cliente solo aporta código y datos —App Engine, Heroku, Elastic Beanstalk—. En SaaS (software como servicio) el proveedor gestiona todo.
Un despliegue gestionado en cloud consiste en apoyarse en estos servicios para llevar una aplicación a producción —a menudo empaquetada en contenedores Docker sobre un servidor o VPS, expuesta por túneles o proxy inverso— delegando buena parte de la operación (escalado, actualizaciones, seguridad) al proveedor o a una capa de gestión. Los contenedores aportan portabilidad: el mismo artefacto corre igual en local o en cualquier servidor. La observabilidad —métricas, logs y trazas— es la pieza que permite ver el consumo y decidir cuándo escalar.
Por qué importa
La infraestructura cloud es la capa sobre la que se despliega y opera el resto del stack: la web (incluida la que sirve el Software a medida (build vs buy) cuando se decide construir en lugar de comprar), las tuberías de datos —ETL / pipelines de datos y su Data warehouse (BigQuery)— y los Agente de IA y mesh de agentes que necesitan recursos de cómputo para correr. Entender dónde cae la línea de responsabilidad compartida define qué tareas operativas asume el proveedor y cuáles quedan del lado de quien construye. Esa frontera condiciona el esfuerzo de mantenimiento, el control sobre el sistema —parte del cual recae en el Hardening y seguridad de servidores cuando el cliente gestiona el SO— y el modelo de coste. El pago por uso ayuda a mantener el gasto acotado, pero no lo hace solo: sin observabilidad del consumo, un servicio mal dimensionado puede escalar coste o saturarse sin aviso. No hay un modelo mejor en abstracto; cada uno mueve el equilibrio entre control y delegación, y la elección depende del caso concreto.
En profundidad
Modelos de servicio y responsabilidad compartida
Los tres modelos se ordenan por cuánto gestiona el proveedor. IaaS entrega la infraestructura (servidores, almacenamiento, red, virtualización) y deja al cliente el SO, el runtime y la aplicación. PaaS añade la gestión de SO, runtime y middleware, de modo que el cliente solo aporta código y datos. SaaS gestiona todo y el cliente solo usa el software. La responsabilidad compartida es el principio que recorre los tres: la línea de qué gestiona cada parte se desplaza, y con ella el equilibrio entre control y mantenimiento delegado. Cuanto más baja la línea hacia el cliente (IaaS), más tareas como el Hardening y seguridad de servidores —parches del SO, firewall, accesos— quedan de su lado.
| Modelo | Gestiona el proveedor | Aporta el cliente |
|---|---|---|
| IaaS | Servidores, almacenamiento, red, virtualización | SO, runtime y aplicación |
| PaaS | Infraestructura + SO, runtime y middleware | Código y datos |
| SaaS | Toda la pila, incluido el software | Solo el uso del software |
Contenedores y portabilidad: Docker frente a máquinas virtuales
Un contenedor empaqueta la aplicación con sus dependencias para que el mismo artefacto se ejecute igual en local o en cualquier servidor o cloud (Railway, Heroku, un VPS). Esa portabilidad facilita reproducir y mover un despliegue sin reconfigurar el entorno. Frente a una máquina virtual, que virtualiza un sistema operativo completo, el contenedor comparte el núcleo del host y resulta más ligero. La elección entre uno y otro depende del grado de aislamiento y control que requiera el caso. Es el patrón habitual para empaquetar servicios como una API REST, que expone la aplicación por HTTP para que otros sistemas la consuman.
| Criterio | Contenedor (Docker) | Máquina virtual |
|---|---|---|
| Qué virtualiza | La app y sus dependencias | Un sistema operativo completo |
| Núcleo (kernel) | Compartido con el host | Propio por cada VM |
| Peso y arranque | Ligero | Más pesado |
| Portabilidad | El mismo artefacto corre igual en local, VPS o cloud | Atado a su imagen de SO |
| Aislamiento | A nivel de proceso | Aislamiento más fuerte |
Despliegue gestionado: VPS, túneles o proxy y operación delegada
Un despliegue gestionado lleva la aplicación a producción apoyándose en servicios cloud y delegando parte de la operación —escalado, actualizaciones, seguridad— al proveedor o a una capa de gestión. Un patrón habitual es ejecutar la app en contenedores sobre un servidor o VPS y exponerla mediante un túnel o proxy inverso (por ejemplo Cloudflare Tunnel), que publica el servicio de forma segura sin abrir puertos directamente. Es la base sobre la que se opera, por ejemplo, la Automatización con n8n o la Integración de APIs y ERP, que necesitan un servicio siempre disponible. El objetivo es operar con coste acotado y operación previsible, no eliminar la operación por completo.
Observabilidad y escalado
La observabilidad reúne métricas, logs y trazas para ver cómo se comporta el sistema: consumo de CPU, RAM y disco, errores, latencia. Herramientas como Grafana permiten visualizar esas señales, que a menudo son Series temporales —medidas indexadas en el tiempo— sobre las que se detectan tendencias y picos. Sobre esa base se decide el escalado: vertical (más CPU o RAM en la misma máquina) u horizontal (más instancias). En IaaS el escalado suele ser más manual; en PaaS y SaaS, más automático y transparente. Sin observabilidad, las decisiones de escalado y coste se toman a ciegas.
Qué observar
Las señales que importan.
La línea de responsabilidad compartida define el modelo
Qué gestiona el proveedor frente al cliente distingue IaaS, PaaS y SaaS. Importa porque marca el reparto real de trabajo operativo y el grado de control sobre el sistema.
Ejemplos canónicos por modelo
EC2, Compute Engine o Azure VMs para IaaS; App Engine, Heroku o Elastic Beanstalk para PaaS. Sitúan cada servicio en su capa y evitan confundir niveles de abstracción.
Portabilidad del contenedor
Un artefacto Docker corre igual en local y en cualquier servidor o cloud. Reduce la dependencia de un proveedor concreto y simplifica mover o reproducir un despliegue.
Observabilidad antes de escalar
Métricas, logs y trazas muestran el consumo de CPU, RAM y disco. Sin esa señal no hay base para decidir si conviene escalar en vertical u horizontal, ni para detectar saturación a tiempo.
Coste por uso frente a inversión fija
El pago por uso o suscripción sustituye la compra de hardware. Mantiene el gasto ligado al consumo real, pero exige vigilarlo para que no se descontrole.
Conceptos clave
El vocabulario del término.
- IaaS (infraestructura como servicio)
- Modelo en el que el proveedor gestiona servidores, almacenamiento, red y virtualización, y el cliente se encarga del sistema operativo, el runtime y la aplicación. Ejemplos: AWS EC2, Google Compute Engine, Azure VMs.
- PaaS (plataforma como servicio)
- Modelo en el que el proveedor gestiona además el sistema operativo, el runtime y el middleware, de modo que el cliente solo aporta código y datos. Ejemplos: Google App Engine, Heroku, AWS Elastic Beanstalk.
- SaaS (software como servicio)
- Modelo en el que el proveedor gestiona toda la pila y entrega el software listo para usar; el cliente solo lo consume. Ejemplos: Google Workspace, Microsoft 365, Salesforce.
- Responsabilidad compartida
- Principio que define qué gestiona el proveedor y qué gestiona el cliente. La línea se desplaza según el modelo (IaaS, PaaS, SaaS) y determina el reparto de operación, control y seguridad.
- Contenedor (Docker)
- Unidad que empaqueta una aplicación con sus dependencias para que el mismo artefacto se ejecute igual en local o en cualquier servidor o cloud. Comparte el núcleo del host, a diferencia de la máquina virtual, que virtualiza un sistema operativo completo.
- Túnel o proxy inverso
- Capa que expone de forma segura un servicio que corre en un servidor o VPS sin abrir puertos directamente al exterior. Cloudflare Tunnel es un ejemplo.
- Observabilidad
- Capacidad de entender el estado de un sistema a partir de sus métricas, logs y trazas. Permite ver el consumo de CPU, RAM y disco, detectar saturación y fundamentar las decisiones de escalado.
- Escalado vertical y horizontal
- Vertical: añadir más CPU o RAM a la misma máquina. Horizontal: añadir más instancias. En IaaS suele ser más manual; en PaaS y SaaS, más automático y transparente.
Dónde lo aplicamos
Aún no mostramos casos.
No inventamos resultados. Cuando tengamos casos reales —anonimizados y medibles— donde este concepto marcó la diferencia, vivirán aquí.
Conceptos relacionados
Una pieza del glosario.
Forma parte del glosario de SEO, analítica e IA de InnovaOrigen Tech: un mapa de conceptos definidos con criterio y fuentes. Si quieres llevarlo a tu caso, lo vemos sin compromiso.