Antes de tocar una sola consola o escribir un comando, conviene entender qué compras exactamente cuando contratas la nube, qué parte del trabajo deja de ser tuya y qué parte sigue siéndolo. Esta lección construye ese marco mental: qué significa "computación en la nube", en qué se diferencian IaaS, PaaS y SaaS, qué es concretamente Google Cloud Platform y sobre qué infraestructura se apoya, qué familias de servicios ofrece y cómo se corresponden con los módulos de este curso, cómo se compara con AWS y Azure, y por qué el modelo económico de la nube (pagar por uso en lugar de comprar hierro) cambia las decisiones técnicas. Terminaremos presentando AlpinaShop, la tienda online que migraremos paso a paso a lo largo de todo el curso y que dará contexto a cada ejemplo y cada ejercicio.

Es la lección más conceptual del curso, y también la que más rentabilidad da: casi todos los errores caros que se cometen en la nube no son errores de comando, sino errores de modelo mental.

1. Qué es la computación en la nube
2. IaaS, PaaS y SaaS: quién gestiona qué
3. Qué es Google Cloud Platform y en qué se apoya
4. Catálogo de familias de servicios de GCP
5. Comparación honesta con AWS y Azure
6. El modelo económico: CapEx frente a OpEx
7. El caso AlpinaShop: de dónde partimos

La computación en la nube consiste en consumir recursos informáticos —capacidad de cálculo, almacenamiento, red, bases de datos, modelos de IA— como un servicio bajo demanda a través de internet, en lugar de comprarlos, instalarlos y mantenerlos tú.

La definición clásica (la del NIST, todavía vigente como referencia) identifica cinco características esenciales. Merece la pena leerlas despacio, porque cada una tiene consecuencias prácticas:

• Autoservicio bajo demanda: puedes crear una máquina o una base de datos sin llamar a nadie ni abrir un ticket. Consecuencia práctica: la velocidad de aprovisionamiento pasa de semanas a segundos, y por eso la gobernanza deja de ser un trámite y pasa a ser crítica (cualquiera puede crear gasto).
• Acceso amplio por red: los recursos se consumen por red con protocolos estándar (HTTPS, API REST). Consecuencia: todo lo que hagas en la consola se puede hacer también por API, y por tanto automatizar.
• Agrupación de recursos (pooling): el proveedor comparte una infraestructura enorme entre muchos clientes usando virtualización y aislamiento. Consecuencia: economías de escala, pero también la necesidad de entender el aislamiento y la seguridad multiinquilino.
• Elasticidad rápida: puedes crecer y decrecer casi instantáneamente. Consecuencia: dimensionar para el pico deja de ser obligatorio.
• Servicio medido: todo se mide y se factura por uso. Consecuencia: el coste se convierte en una métrica de ingeniería más, como la latencia.

AlpinaShop hará una migración que empieza como híbrida (durante unas semanas conviven el servidor antiguo y GCP) y termina siendo nube pública pura. La conectividad híbrida y las estrategias multinube se tratan en el módulo 7 (Anthos y redes avanzadas).

La distinción entre modelos de servicio es, en el fondo, una línea que separa lo que gestiona el proveedor de lo que gestionas tú. Cuanto más arriba subes, menos controlas y menos mantienes.

Traducido a servicios concretos de Google Cloud:

Una advertencia importante: "menos gestión" no significa "menos responsabilidad". En todos los modelos sigues siendo responsable de tus datos, de quién accede a ellos y de la configuración que aplicas. Un bucket de Cloud Storage mal configurado expone datos igual de bien siendo serverless. Este reparto se formaliza en el modelo de responsabilidad compartida, que estudiaremos en detalle en la lección 01-05.

Google Cloud Platform (GCP) es el conjunto de servicios de infraestructura y plataforma que Google comercializa sobre la misma infraestructura física que utiliza para sus propios productos: Búsqueda, YouTube, Gmail o Maps. Esa frase, que suena a eslogan, tiene tres implicaciones técnicas muy concretas:

• Red troncal privada global. Google opera su propia red de fibra entre centros de datos y más de un centenar de puntos de presencia. Cuando el tráfico entra en un PoP de Google (por ejemplo, en Madrid), viaja hasta tu servicio por esa red privada, no por el internet público. Esto reduce latencia y variabilidad, y es la base de servicios como el balanceador de carga global y Cloud CDN (módulo 3).
• Centros de datos propios y diseño a medida. Google diseña sus servidores, sus conmutadores de red y sus chips (TPU para IA, Titan para seguridad de arranque). El cifrado de datos en reposo y en tránsito dentro de su infraestructura está activado por defecto, sin que tengas que configurarlo.
• Tecnologías nacidas para escala interna. Varios servicios de GCP son la versión comercial de sistemas internos: BigQuery desciende de Dremel, Cloud Bigtable de Bigtable, Pub/Sub del sistema de mensajería interno, y Kubernetes es la reescritura abierta de Borg. No son productos concebidos para el mercado y luego escalados: fueron escalados primero.

Una precisión de nomenclatura útil desde el principio: hoy Google usa mayoritariamente la marca "Google Cloud" para todo (incluyendo Workspace y las soluciones sectoriales), y "Google Cloud Platform" o GCP para la parte de infraestructura y plataforma que nos ocupa. Verás ambos términos en la documentación; en este curso los usamos indistintamente para referirnos a la plataforma técnica.

El catálogo de Google Cloud supera los doscientos servicios, pero se agrupa en un puñado de familias. No necesitas conocerlos todos: necesitas saber qué familia resuelve qué problema para poder buscar dentro de ella.

Dos observaciones sobre nomenclatura, porque encontrarás documentación antigua que usa nombres retirados:

• Cloud Monitoring, Cloud Logging y Cloud Trace son los nombres actuales de lo que durante años se llamó Stackdriver.
• Vertex AI unificó lo que antes eran AI Platform y AutoML por separado.
• Artifact Registry sustituye a Container Registry (gcr.io), que está en desuso.

Si un tutorial que encuentras por internet menciona Stackdriver, AI Platform o gcr.io, es anterior a 2022 y probablemente contenga más cosas desactualizadas.

Los tres grandes proveedores cubren prácticamente las mismas necesidades. Las diferencias reales están en los detalles de cada servicio, en el modelo de precios y en el ecosistema de la empresa, no en "cuál puede hacer X".

Dónde suele destacar cada uno, dicho sin marketing:

• Google Cloud tiene ventaja reconocida en analítica de datos (BigQuery es serverless de verdad: no gestionas clúster) y en Kubernetes, que es tecnología de origen Google. Su red global y el balanceador global con una única IP anycast son técnicamente elegantes. Su cuota de mercado es la tercera, lo que en la práctica significa menos oferta de profesionales con experiencia y a veces menos integraciones de terceros.
• AWS tiene el catálogo más amplio, la mayor comunidad y la documentación más abundante de terceros. También la mayor complejidad acumulada y una consola menos coherente.
• Azure domina donde ya hay una fuerte inversión en Microsoft (Active Directory, .NET, licencias de Windows Server), con ventajas de integración y licenciamiento difíciles de igualar en ese contexto.

Para AlpinaShop, con una aplicación Python sin dependencias de Microsoft y con ambición de explotar sus datos de ventas, Google Cloud es una elección razonable. No es la única posible, y eso es una respuesta perfectamente profesional.

Este es el cambio que más afecta a las decisiones técnicas, y el que peor se entiende al principio.

Los conceptos clave que debes interiorizar:

• Pago por uso: se factura por segundos de CPU, gigabytes almacenados por mes, gigabytes de tráfico de salida, consultas ejecutadas. Un recurso apagado deja de generar coste de cómputo, pero un disco persistente sigue costando aunque la VM esté parada. Es el error de novato número uno.
• Elasticidad: la capacidad se ajusta a la demanda. Para AlpinaShop, cuyo tráfico se multiplica en las campañas de otoño, esto significa dejar de pagar todo el año por la capacidad que solo necesita seis semanas.
• Descuentos por compromiso y por uso sostenido: Google aplica automáticamente descuentos por uso sostenido a las VMs que corren gran parte del mes, y ofrece descuentos mayores si te comprometes a 1 o 3 años. También existen las VMs Spot, mucho más baratas a cambio de poder ser interrumpidas.
• Coste de salida (egress): mover datos hacia Google es gratis; sacarlos hacia internet, no. En arquitecturas con mucho tráfico de descarga (imágenes de catálogo, por ejemplo) esta partida importa.

Advertencia sobre cifras. Los precios, las cuotas y los detalles del nivel gratuito cambian con frecuencia y varían por región. En este curso usamos cifras solo como orden de magnitud; verifica siempre los importes vigentes en la calculadora y en la documentación oficial de precios de Google Cloud antes de tomar una decisión. La optimización sistemática de costes se trata en la lección 07-05.

Un matiz que conviene decir pronto: la nube no es automáticamente más barata. Una carga estable, predecible y siempre encendida puede resultar más cara en la nube que en un servidor propio amortizado. Lo que la nube compra de verdad es elasticidad, velocidad de cambio y servicios gestionados que sustituyen horas de personal. Si tu carga no aprovecha nada de eso, el argumento económico se debilita.

Durante todo el curso trabajaremos con un caso único, para que cada servicio que veamos encaje en una arquitectura que crece de forma coherente.

AlpinaShop es una pyme española de unas 40 personas que vende material de montaña por internet: mochilas, botas y tiendas de campaña. Su dominio corporativo es alpinashop.example. Las personas con las que trabajaremos son:

• Marta, responsable de infraestructura. Lidera la migración y será quien cree proyectos, configure redes y vigile la facturación.
• Dani, desarrollador backend. Mantiene la aplicación Flask y despliega los cambios.
• Lucía, analista de datos. Hoy vive dentro de una hoja de cálculo y quiere responder preguntas de negocio con datos reales.

• Un servidor físico alquilado en un proveedor de hosting tradicional, con contrato anual y un dimensionado fijo.
• Una única instancia de PostgreSQL en ese mismo servidor, con la base de datos tienda, y una copia de seguridad diaria a un disco externo cuyo restablecimiento no se ha probado nunca.
• La aplicación web es un catálogo en Python con Flask servido por Gunicorn detrás de Nginx.
• Las imágenes de producto (unos 60 GB y creciendo) están en el disco local del servidor, servidas por el mismo Nginx.
• La analítica consiste en exportar un CSV mensual desde la base de datos a una hoja de cálculo.

A lo largo del curso construiremos, pieza a pieza, esta arquitectura destino. Los nombres son fijos y los reencontrarás en cada módulo:

• Proyectos alpinashop-prod y alpinashop-dev, en la región europe-west1 (zona europe-west1-b).
• Bucket alpinashop-catalogo para las imágenes de producto.
• Instancia Cloud SQL alpinashop-pedidos (PostgreSQL) con la base de datos tienda.
• Servicio Cloud Run alpinashop-web y clúster GKE alpinashop-cluster.
• Topic Pub/Sub pedidos-nuevos y dataset BigQuery alpinashop_analitica.

En esta lección no hemos creado nada todavía: hemos establecido el porqué. En la siguiente abriremos la cuenta y pondremos las primeras defensas contra sustos en la factura.

• Creer que migrar es "levantar las mismas VMs en la nube". Un lift and shift literal reproduce en GCP los mismos problemas de antes, y además pagando por hora. Es un primer paso válido para reducir riesgo, pero solo es un paso: el valor llega al sustituir componentes por servicios gestionados.
• Confundir "gestionado" con "no es mi problema". El proveedor gestiona la infraestructura; tus datos, tus permisos y tu configuración siguen siendo tuyos.
• Asumir que la nube sale más barata sin hacer números. Compara con la carga real, no con la teórica, e incluye el coste de personal y el de tráfico de salida.
• Olvidar el egress. Servir 60 GB de imágenes a muchos usuarios genera tráfico de salida facturable. Es un argumento a favor de una CDN, no en contra de la nube.
• Aprender el catálogo de memoria. Nadie conoce doscientos servicios. Aprende las familias, y dentro de cada familia el criterio de elección. La lección 02-07 está dedicada precisamente a ese criterio para el cómputo.
• Consejo: piensa en el coste como una métrica de ingeniería. Igual que revisas latencia y errores, revisa gasto. Verlo pronto evita rediseños dolorosos.
• Consejo: no busques "el mejor proveedor". Busca el que mejor encaje con tu equipo, tu stack y tus requisitos regulatorios. Los tres funcionan.

Para cada una de estas situaciones, indica si corresponde a IaaS, PaaS, serverless o SaaS, y justifica qué parte del mantenimiento desaparece de tu lista de tareas:

1. Marta crea una máquina virtual con Debian donde instalará ella misma PostgreSQL.
2. Dani despliega la aplicación Flask empaquetada en un contenedor y solo indica cuánta CPU necesita por petición.
3. AlpinaShop contrata Google Workspace para el correo corporativo.
4. Marta crea una instancia gestionada de PostgreSQL y elige versión, tamaño y ventana de copias de seguridad.

Para cada uno de estos tres problemas reales de AlpinaShop, indica la familia de servicios de GCP que lo aborda y el módulo del curso donde se estudia. No hace falta que aciertes el servicio exacto: el objetivo es razonar por familia.

1. En la campaña de otoño la web tarda 8 segundos en cargar y algunos clientes abandonan el carrito.
2. Lucía necesita cruzar tres años de pedidos con datos de stock para decidir cuánto material comprar.
3. Cuando la web falla, nadie se entera hasta que un cliente escribe por el formulario de contacto.

El servidor actual de AlpinaShop cuesta 280 € al mes con contrato anual y está dimensionado para soportar el pico de otoño. Durante 10 meses al año utiliza en torno al 15 % de su CPU; durante 6 semanas se satura y la web se degrada.

Sin hacer cálculos exactos de precios de GCP (que cambian y hay que consultar), argumenta en cinco o seis líneas qué ventajas económicas y operativas ofrecería un modelo de pago por uso con autoescalado, y qué riesgo económico nuevo aparece que antes no existía.

Solución 1

1. IaaS (Compute Engine). Google se ocupa del hardware, la energía, la red física y la virtualización. Marta sigue siendo responsable del sistema operativo, los parches, la instalación de PostgreSQL, sus copias de seguridad y su alta disponibilidad.
2. Serverless (Cloud Run). Desaparecen el sistema operativo, el servidor de aplicaciones, el dimensionado y el escalado. Dani solo mantiene la imagen del contenedor y su configuración.
3. SaaS. No queda ninguna tarea de infraestructura: solo administración de usuarios y configuración del producto.
4. PaaS (Cloud SQL). Google gestiona el SO, la instalación del motor, los parches, las copias de seguridad y la conmutación por error. Marta sigue siendo responsable del esquema, las consultas, los índices y de quién tiene acceso.

Solución 2

1. Familias de cómputo (escalado automático) y redes (balanceo de carga y CDN). Módulos 2, 3 y 7. La causa puede estar tanto en la capacidad de cómputo como en la entrega de las imágenes.
2. Familia de datos y analítica, con BigQuery como almacén y Looker Studio para visualizar. Módulo 4.
3. Familia de DevOps y operaciones: Cloud Monitoring para métricas y alertas, Cloud Logging para diagnóstico. Módulo 6.

Solución 3

Respuesta orientativa: hoy AlpinaShop paga durante todo el año la capacidad que solo necesita seis semanas, y aun así esa capacidad resulta insuficiente en el pico (paga de más y sirve de menos, que es lo peor de ambos mundos). Con pago por uso y autoescalado, el coste seguiría aproximadamente a la demanda: bajo en los meses tranquilos y alto solo durante la campaña, cuando además coincide con el máximo de ingresos, de modo que el coste se correlaciona con la facturación. A esto se suman ventajas operativas difíciles de valorar en euros pero reales: desaparece el riesgo de quedarse sin capacidad en el peor momento, y desaparecen tareas de mantenimiento del servidor.

El riesgo nuevo es que el gasto deja de tener un techo natural. Un error de configuración, un bucle de reintentos, un proceso que no se apaga o un pico de tráfico ilegítimo pueden disparar la factura sin que nadie lo autorice explícitamente. Por eso los presupuestos y las alertas de facturación se configuran el primer día, no el primer susto: es exactamente lo que haremos en la lección 01-02.

En esta lección hemos construido el marco conceptual del curso. Hemos visto qué es la computación en la nube y qué cinco características la definen; cómo IaaS, PaaS, serverless y SaaS dibujan una línea móvil entre lo que gestiona el proveedor y lo que gestionas tú; qué es Google Cloud Platform y por qué su red global, sus centros de datos propios y su herencia tecnológica interna son argumentos técnicos y no solo comerciales; qué familias de servicios existen y en qué módulo del curso se estudia cada una; cómo se compara GCP con AWS y Azure sin caer en el fanatismo; y por qué el paso de CapEx a OpEx cambia las decisiones de diseño, con el pago por uso y la elasticidad como piezas centrales y el control del gasto como nueva responsabilidad de ingeniería.

Y hemos conocido a AlpinaShop: su servidor alquilado, su PostgreSQL único, sus 60 GB de imágenes en disco local y sus picos de otoño que tumban la web. Marta, Dani y Lucía nos acompañarán en cada lección.

En la siguiente lección, Configuración de tu cuenta de GCP, pasamos de la teoría a la acción: crearemos la cuenta, entenderemos qué incluye realmente el nivel gratuito, veremos por qué una empresa como AlpinaShop necesita Cloud Identity y no cuentas personales, crearemos la cuenta de facturación y el proyecto alpinashop-dev, y configuraremos presupuestos y alertas antes de encender nada. Empezamos a construir.