A lo largo de este módulo hemos desplegado el catálogo de AlpinaShop de cuatro formas distintas: en máquinas virtuales con un grupo gestionado, en App Engine con un app.yaml, en contenedores sobre GKE Autopilot, y hemos mencionado Cloud Run y Cloud Functions como opciones que se estudian más adelante. Todas funcionan. Todas sirven la misma página. Y todas tienen implicaciones muy distintas en coste, en esfuerzo operativo, en velocidad de despliegue y en la libertad que tendrás dentro de tres años.

Esta lección es la síntesis del módulo. No introduce servicios nuevos: te da el criterio para elegir entre los que ya conoces, con una tabla comparativa completa, preguntas de decisión que puedes aplicar mañana en tu trabajo, un cálculo de coste transparente sobre el mismo escenario de tráfico, los patrones de migración habituales y, al final, la arquitectura definitiva de AlpinaShop, documentada y razonada, que sostendrá el resto del curso.

1. El continuo de abstracción
2. Qué ganas y qué pierdes al subir de nivel
3. Tabla comparativa completa
4. Las seis preguntas de decisión
5. Coste comparado sobre un mismo escenario
6. Patrones de migración: lift-and-shift, replatform, refactor
7. Arquitecturas híbridas: casi nadie elige uno solo
8. La arquitectura de AlpinaShop al cerrar el módulo
9. Lo que falta: la red

Los servicios de cómputo de Google Cloud no son una lista de opciones sueltas: forman un continuo. En cada escalón cedes control a la plataforma y recibes a cambio menos trabajo operativo.

Leído de izquierda a derecha:

• Compute Engine. Tú das una imagen de disco y Google te da una máquina. Todo lo demás —sistema operativo, parches, runtime, servidor web, escalado, despliegue— es tuyo.
• GKE Standard. Tú das contenedores y decides el tamaño y número de nodos. Kubernetes coloca los contenedores; tú mantienes la flota de VM.
• GKE Autopilot. Tú das contenedores y declaras cuántos recursos piden. Los nodos desaparecen de tu vista.
• App Engine. Tú das código y un app.yaml. Desaparecen también los contenedores.
• Cloud Run. Tú das un contenedor y una configuración mínima. Escala a cero, se factura por uso y no hay infraestructura visible.
• Cloud Functions. Tú das una función y un disparador. Es la unidad de despliegue más pequeña posible.

Fíjate en que hay dos caminos hacia Cloud Run: desde contenedores (GKE) y desde código (App Engine). Esa convergencia no es casual, y explica por qué Cloud Run se ha convertido en el punto de encuentro de ambos mundos.

Dos matices que evitan conclusiones simplistas:

Más abstracción no siempre es más barato. Una carga constante 24×7 sale más barata en Compute Engine con descuento por uso comprometido que en un servicio serverless facturado por petición. Serverless gana con tráfico intermitente o muy variable, que es precisamente el caso de AlpinaShop.

Más abstracción no siempre es menos portable. Un contenedor en Cloud Run es tan portable como en GKE: la misma imagen corre en ambos, en tu portátil y en otra nube. Lo que ata no es el nivel de abstracción, sino el formato propietario: app.yaml de App Engine o las firmas específicas de Cloud Functions.

Dos filas merecen un comentario adicional.

Concurrencia por instancia. Es el parámetro más malinterpretado y el que más dinero mueve. Cloud Run puede atender hasta 1000 peticiones simultáneas en una misma instancia; Cloud Functions atiende una sola por defecto. Para una aplicación que pasa el tiempo esperando a la base de datos, una concurrencia alta significa muchas menos instancias y una factura mucho menor. Para una aplicación que consume CPU, subirla degrada la latencia de todos.

Arranque en frío. Existe siempre que se pueda escalar a cero. Se mitiga con instancias mínimas, pero eso elimina precisamente la ventaja del escalado a cero. Es un compromiso, no un problema con solución.

En la práctica, la elección se resuelve respondiendo a seis preguntas en orden.

1. ¿Necesitas control del sistema operativo o hardware especial? Kernel concreto, drivers, GPU, software con licencia atada a hardware, agentes de seguridad corporativos, procesos que deben ver el host. Si la respuesta es sí → Compute Engine (o GKE Standard si además quieres contenedores). Si no, sigue.

2. ¿Tienes contenedores, o estás dispuesto a tenerlos? Si no y no quieres aprender ahora → App Engine estándar o Compute Engine. Si sí → sigue, se abre todo lo demás. Merece la pena insistir: contenedorizar es la inversión con mejor retorno de todo el módulo, porque la misma imagen funciona en Cloud Run, en GKE, en tu portátil y en otra nube.

3. ¿Necesitas estado local persistente o procesos muy largos? Sesiones en memoria, disco local con datos, procesos de horas, servidores con conexiones de larga duración. Si sí → Compute Engine o GKE. Si no → sigue.

4. ¿El tráfico es intermitente o muy variable? Si el tráfico cae a casi cero por la noche o tiene picos estacionales de diez a uno → Cloud Run (escala a cero, se paga por uso). Si es constante y elevado 24×7 → Compute Engine o GKE con descuentos por uso comprometido salen mejor.

5. ¿Es una unidad de trabajo pequeña disparada por un evento? Un fichero que llega a un bucket, un mensaje en Pub/Sub, un webhook, una tarea programada → Cloud Functions. Si es un servicio con varias rutas y una API → Cloud Run.

6. ¿Te preocupa la dependencia del proveedor? Si es un criterio real de tu organización → contenedores (Cloud Run o GKE), que se ejecutan en cualquier parte. Evita app.yaml y las firmas propietarias de funciones.

Y una regla transversal que resume el estado del arte en 2026: si tienes una aplicación web o una API contenedorizable y ninguna de las restricciones anteriores aplica, Cloud Run es la respuesta por defecto. Es el consejo que Google mismo da, y este curso lo suscribe.

Comparar precios de catálogo no sirve de nada; hay que comparar el coste de una carga concreta. Usamos la de AlpinaShop:

Escenario. El catálogo de AlpinaShop recibe:

• 500.000 peticiones al mes en un mes normal (unas 0,2 peticiones/segundo de media).
• Distribución muy desigual: 80 % del tráfico entre las 9:00 y las 23:00; prácticamente nada de madrugada.
• Picos de campaña: hasta 20 peticiones/segundo durante unas 40 horas repartidas en otoño.
• Cada petición consume unos 150 ms de CPU y 300 MiB de memoria.
• La aplicación necesita ~0,25 vCPU y 512 MiB por instancia.

Cifras orientativas para europe-west1 a 2026, redondeadas, con el único fin de mostrar el orden de magnitud y la forma de razonar. No incluyen Cloud SQL, Cloud Storage, egress ni CDN, que son comunes a todas las opciones y que en este escenario superan al propio cómputo. Verifica siempre en la calculadora oficial de Google Cloud antes de tomar una decisión.

Las conclusiones que hay que extraer, que valen más que los números:

• El escalado a cero importa cuando el tráfico es desigual. AlpinaShop no tiene tráfico ocho horas al día; pagar por capacidad encendida durante ese tiempo es puro desperdicio.
• El plano de control de GKE es un coste fijo relevante a escala pequeña. No lo pongas para desplegar un solo servicio; sí cuando haya diez servicios compartiéndolo, momento en el que ese coste se diluye.
• La concurrencia manda en Cloud Run. Con concurrencia 80, un pico de 20 peticiones por segundo se atiende con muy pocas instancias. Si la bajaras a 1, necesitarías veinte veces más y el coste se multiplicaría.
• El cómputo no suele ser la partida mayor. En este escenario, Cloud SQL con alta disponibilidad cuesta bastante más que cualquiera de las opciones de cómputo. Optimizar el cómputo antes que la base de datos y el egress es empezar por el sitio equivocado. La disciplina completa de optimización de costes está en 07-05.

Cuando una empresa mueve una aplicación existente a la nube, hay tres estrategias, y la mayoría de las migraciones exitosas las recorren en orden.

Por qué el orden importa. Intentar refactorizar y migrar a la vez es la receta clásica del proyecto que no termina: cuando algo falla, no sabes si es por el cambio de arquitectura o por el cambio de plataforma. Separar las variables reduce el riesgo drásticamente.

El recorrido de AlpinaShop en este módulo ha sido exactamente ese:

1. Lift-and-shift (02-01): el catálogo Flask a una VM alpinashop-web-1 con un startup script, y luego a un grupo gestionado con autoescalado. La aplicación no cambió una línea.
2. Replatform (02-02, 02-03, 02-06): las imágenes salieron del disco local al bucket alpinashop-catalogo; la base de datos tienda pasó a la instancia gestionada alpinashop-pedidos con alta disponibilidad y copias; el carrito y las sesiones se movieron a Firestore. La lógica de negocio sigue siendo la misma; lo que cambió es dónde vive cada cosa.
3. Refactor (en curso): contenedorizar la aplicación, que ya hicimos para GKE en 02-05, y desacoplar el trabajo asíncrono con colas y eventos, que empezamos a ver con Cloud Tasks en 02-04 y completaremos con Pub/Sub en 04-04.

Por qué AlpinaShop empieza en Compute Engine pero se dirige a contenedores. Empezar en VM fue lo correcto: permitió migrar en un fin de semana sin reescribir nada, con un riesgo mínimo y con la posibilidad de volver atrás. Pero el destino son los contenedores, por tres razones que ya hemos comprobado a lo largo del módulo:

• La imagen de contenedor es portable. La misma que corre en GKE corre en Cloud Run, en el portátil de Dani y, si algún día hiciera falta, en otro proveedor.
• El despliegue se vuelve trivial y reversible. Frente a plantillas de instancia versionadas, startup scripts e imágenes de disco, un contenedor se despliega y se revierte en un comando.
• La inversión se acumula. Aprender contenedores sirve en todos los servicios y en toda la industria; aprender app.yaml sirve en App Engine.

La pregunta "¿qué servicio de cómputo uso?" está mal planteada si se hace una sola vez para todo el sistema. Se hace por carga de trabajo, y lo normal es acabar con varios.

Una arquitectura completa y realista para AlpinaShop combina cuatro:

Reparto y motivo:

Esta mezcla no es indecisión: es usar la herramienta adecuada para cada trabajo. El coste de la variedad es tener que conocer varios servicios; el beneficio es no forzar ninguna carga a un modelo que no le encaja.

Esta es la decisión documentada que cierra el módulo 2 y que servirá de base para el resto del curso.

Estado actual (lo construido en este módulo):

Decisión de arquitectura objetivo:

1. El catálogo web (alpinashop-web) irá a Cloud Run. Tráfico intermitente con picos estacionales, contenedor ya construido, escala a cero, coste muy inferior a las alternativas y sin acoplamiento al proveedor. Se configurará con min-instances: 1 en producción para evitar arranques en frío en la primera visita, y concurrencia alta porque la aplicación pasa la mayor parte del tiempo esperando a la base de datos. Cloud Run se estudia en 07-02.

2. El clúster alpinashop-cluster se conserva como plataforma para los servicios internos que vayan apareciendo (panel de administración, integración con el ERP, procesos de sincronización de stock). Cuando haya tres o más, el coste del plano de control quedará amortizado. Mientras tanto, se mantiene apagado o reducido al mínimo.

3. Compute Engine se conserva para trabajo por lotes con VM Spot: reproceso de imágenes, pruebas de carga, tareas puntuales de CPU intensiva.

4. App Engine queda descartado, de forma razonada: funciona bien, pero su formato propio no es portable y la inversión no se acumula. Se conoce, se ha probado y se descarta.

5. Cloud Functions se reserva para el trabajo dirigido por eventos: correo de confirmación de pedido, generación de miniaturas al subir una imagen al bucket, webhooks de la pasarela de pago (06-03).

6. Los datos quedan como se decidió en 02-06: Cloud SQL para productos, pedidos y clientes; Firestore para carrito y sesiones; Cloud Storage para imágenes; Memorystore como caché de portada; Pub/Sub y BigQuery para la telemetría, con Bigtable descartado por ahora.

Ruta de migración acordada con Marta, Dani y Lucía:

Repasa lo construido en este módulo con ojo crítico y encontrarás un problema serio.

La VM alpinashop-web-1 tiene una IP pública y el puerto 80 abierto a todo internet. Las instancias del grupo gestionado, también. El Service de tipo LoadBalancer de GKE expuso una IP pública directa, sin HTTPS. La instancia de Cloud SQL, si se creó con IP pública y redes autorizadas, es alcanzable desde fuera. Los buckets están bien protegidos, pero las URL firmadas viajan por HTTP si alguien las usa mal. No hay ningún nombre de dominio propio, ningún certificado TLS, ninguna protección frente a ataques de denegación de servicio ni frente a inyección SQL, y ninguna separación de red entre lo que debe ser público (el catálogo) y lo que jamás debería serlo (la base de datos).

Dicho con crudeza: hemos construido una tienda funcional y la hemos dejado con la puerta abierta y sin cartel en la fachada. Todo lo de este módulo estaba bien para aprender y para probar; nada de ello es publicable tal cual.

Eso es exactamente lo que resuelve el módulo 3.

• Elegir el servicio antes de entender la carga. El patrón de tráfico, la duración de las peticiones y la necesidad de estado determinan la respuesta; el gusto personal, no.
• Elegir Kubernetes por defecto. Es una herramienta excelente para muchos servicios y equipos con capacidad de plataforma. Para un servicio y una persona, es sobrecarga pura.
• Comparar precios de catálogo en lugar de coste de la carga. El precio por vCPU-hora no dice nada si no sabes cuántas horas vas a necesitar.
• Olvidar el coste del plano de control de GKE al comparar con alternativas serverless a escala pequeña.
• Dejar la concurrencia de Cloud Run en 1 "por seguridad". Multiplica el número de instancias y el coste.
• Refactorizar y migrar a la vez. Cuando falle algo, no sabrás qué cambio lo causó.
• Quedarse para siempre en el lift-and-shift. Es un punto de partida legítimo y un destino malo: sigues manteniendo servidores.
• Aceptar acoplamiento al proveedor sin decidirlo. Si vas a asumirlo, que sea una decisión consciente y anotada, no un accidente.
• Consejo: contenedoriza aunque no vayas a usar Kubernetes. Es lo que más opciones te abre por menos esfuerzo.
• Consejo: decide por carga de trabajo, no por sistema. Una arquitectura con Cloud Run, funciones y VM Spot no es incoherente: es apropiada.
• Consejo: documenta y fecha cada decisión de arquitectura, con las alternativas descartadas y el motivo. Es lo que permite revisarla con criterio dentro de un año.
• Consejo: mide antes de optimizar. Casi siempre el gasto está donde no lo esperas, y rara vez en el cómputo.

Para cada carga de AlpinaShop, elige el servicio de cómputo, indica una alternativa razonable y justifica la decisión aplicando las seis preguntas del apartado 4:

1. Una API REST de stock que consultan los proveedores, con tráfico irregular y muy bajo por la noche.
2. Un proceso que, cada vez que se sube una imagen al bucket, genera la miniatura y la versión web.
3. Un servidor de sincronización con el ERP local que mantiene una conexión permanente y guarda estado en disco.
4. El panel interno de administración, usado por 8 personas en horario de oficina.
5. Un reproceso puntual de las 60.000 imágenes que tarda 3 horas y puede reintentarse.

Un servicio interno de AlpinaShop recibe 100.000 peticiones al mes, cada una de 200 ms de CPU, necesita 0,5 vCPU y 1 GiB de memoria, y su tráfico se concentra en horario de oficina (unas 9 horas al día, 22 días al mes).

1. Estima el coste en Compute Engine con una VM encendida 24×7.
2. Estima el coste si se apaga fuera de horario.
3. Estima el coste en Cloud Run con escalado a cero.
4. Indica a partir de qué volumen de tráfico Compute Engine empezaría a ser competitivo.
5. Enumera qué costes has dejado fuera del cálculo y por qué pueden invertir la conclusión.

Redacta el documento de decisión de arquitectura del catálogo de AlpinaShop, con esta estructura:

1. Contexto: situación de partida y restricciones.
2. Opciones consideradas: al menos cuatro, con una ventaja y un inconveniente de cada una.
3. Decisión: qué se elige y con qué configuración concreta.
4. Consecuencias: qué mejora, qué empeora y qué queda pendiente.
5. Criterios de revisión: qué tendría que ocurrir para reconsiderarla.

Solución 1

Solución 2

1. Compute Engine 24×7. Una e2-small (2 vCPU compartidas, 2 GiB) ronda los 13–15 €/mes, más unos 2 € del disco balanceado de 20 GB: ≈ 16 €/mes. Se paga la máquina las 730 horas del mes, aunque solo se use durante 198.

2. Compute Engine apagada fuera de horario. Con 198 horas encendida de 730, el coste de cómputo baja a un 27 %: unos 4 €. El disco se sigue pagando entero (≈2 €), porque los discos facturan estén o no encendidas las máquinas. Total: ≈ 6 €/mes, más el trabajo de automatizar el encendido y apagado con Cloud Scheduler y una función.

3. Cloud Run con escalado a cero. Facturación aproximada:

A los precios orientativos de europe-west1, todo eso queda en el entorno de 1–2 €/mes, y una parte importante puede caer dentro del nivel gratuito mensual de Cloud Run. Es entre 3 y 10 veces más barato que las opciones anteriores, sin ningún trabajo de automatización.

4. ¿Cuándo empieza a compensar Compute Engine? Cuando la máquina esté ocupada de forma sostenida. El punto de equilibrio llega aproximadamente cuando el uso de CPU facturado en Cloud Run se acerca a tener una vCPU ocupada de forma continua: del orden de varios millones de peticiones al mes con este perfil, o cualquier carga que mantenga la CPU trabajando 24 horas al día. Añadiendo un descuento por uso comprometido a uno o tres años, ese umbral baja bastante. La regla mental es clara: serverless gana con tráfico intermitente; las VM ganan con carga constante y alta.

5. Costes dejados fuera, y por qué pueden cambiar la conclusión:

• Balanceador de carga y IP estática (~18–20 €/mes en Compute Engine). Cloud Run incluye endpoint HTTPS gestionado, lo que amplía aún más su ventaja.
• Egress y CDN, comunes a todas las opciones, pero que en una tienda con imágenes superan al cómputo.
• Cloud SQL, que en este escenario cuesta más que cualquiera de las opciones de cómputo comparadas.
• El tiempo de las personas. Mantener una VM (parches, monitorización, automatización de encendido) son horas de Marta. Si se valoran a precio de mercado, el ahorro de 10 €/mes de la opción 2 desaparece con la primera hora de trabajo al mes.
• Descuentos por uso comprometido y por uso sostenido, que solo aplican a Compute Engine y GKE y pueden reducir su coste entre un 20 y un 55 %.

Este último punto es el más importante y el que más se olvida: el coste de una arquitectura no es solo su factura.

Solución 3

DA-001 — Servicio de cómputo del catálogo web de AlpinaShop Fecha: 2026-08-05 · Autores: Marta (infraestructura), Dani (backend) · Estado: aceptada

1. Contexto. El catálogo web es una aplicación Flask en Python con PostgreSQL, actualmente desplegada en un grupo de instancias gestionado de Compute Engine tras el lift-and-shift. El tráfico es intermitente: prácticamente nulo de madrugada, con picos de hasta 20 peticiones por segundo en las campañas de otoño. El equipo de infraestructura es de una persona. La aplicación ya está contenedorizada y su imagen publicada en Artifact Registry. No requiere estado en disco local ni acceso al sistema operativo. Restricciones: minimizar el trabajo operativo, evitar el acoplamiento al proveedor y contener el coste fuera de campaña.

2. Opciones consideradas.

3. Decisión. Desplegar alpinashop-web en Cloud Run, en europe-west1, con la imagen europe-west1-docker.pkg.dev/alpinashop-prod/alpinashop/catalogo, etiquetada con el hash del commit. Configuración: min-instances: 1 y max-instances: 50 en producción; min-instances: 0 en desarrollo; concurrencia 80; 1 vCPU y 512 MiB por instancia; conexión a Cloud SQL mediante el conector; credenciales resueltas por la cuenta de servicio adjunta; secretos en Secret Manager. El clúster alpinashop-cluster se conserva para futuros servicios internos. Compute Engine se mantiene únicamente para trabajo por lotes con VM Spot.

4. Consecuencias. Mejora: desaparecen el mantenimiento del sistema operativo, las plantillas de instancia y los startup scripts; el coste de cómputo baja aproximadamente un orden de magnitud fuera de campaña; los despliegues y los rollbacks pasan a ser inmediatos con división de tráfico entre revisiones; se obtiene HTTPS gestionado sin configurar nada. Empeora: se pierde el control del sistema operativo y la capacidad de diagnóstico a bajo nivel; aparece la posibilidad de arranques en frío en desarrollo; las tareas de más de 60 minutos deben ejecutarse fuera de Cloud Run. Pendiente: balanceador HTTPS global con dominio propio, Cloud CDN, Cloud Armor y red privada hacia Cloud SQL (módulo 3); pipeline de despliegue automatizado (módulo 6).

5. Criterios de revisión. Se reconsiderará esta decisión si: el número de servicios internos supera tres, en cuyo caso GKE Autopilot amortiza su plano de control y podría absorber también el catálogo; el tráfico pasa a ser constante y elevado 24×7, escenario en el que Compute Engine o GKE con descuentos por uso comprometido resultarían más económicos; aparece un requisito de estado local o de procesos de más de 60 minutos; o el arranque en frío afecta a métricas de negocio pese a min-instances: 1. Revisión programada: agosto de 2027, o antes si se cumple alguno de los criterios anteriores.

Cerramos el módulo 2 con criterio, que es lo que distingue conocer una plataforma de saber usarla. Has visto que los servicios de cómputo de Google Cloud forman un continuo de abstracción —de la máquina virtual a la función— y que en cada escalón cedes control a cambio de trabajo operativo. Sabes qué se gana y qué se pierde al subir de nivel, y también los dos matices que evitan las conclusiones fáciles: más abstracción no siempre es más barato, porque una carga constante 24×7 sale mejor en VM con compromiso de uso, y más abstracción no siempre es menos portable, porque lo que ata no es el nivel sino el formato propietario.

Tienes una tabla comparativa completa de siete opciones con criterios que se pueden medir —unidad de despliegue, escalado a cero, arranque en frío, facturación, portabilidad, tiempo máximo, esfuerzo operativo, concurrencia— y seis preguntas de decisión que puedes aplicar mañana a cualquier carga: control del sistema operativo, contenedores, estado y duración, patrón de tráfico, disparo por eventos y dependencia del proveedor. Has hecho un cálculo de coste transparente sobre el escenario real de AlpinaShop y has extraído las lecciones que importan más que los números: el escalado a cero manda cuando el tráfico es desigual, el plano de control de GKE es un coste fijo relevante a escala pequeña, la concurrencia gobierna el coste en Cloud Run, y el cómputo rara vez es la partida mayor de la factura. Has recorrido los tres patrones de migración y has entendido por qué separar la migración del rediseño reduce el riesgo, y por qué AlpinaShop empezó en Compute Engine pero se dirige a contenedores. Y has visto que la pregunta correcta no se hace una vez para todo el sistema, sino una vez por carga de trabajo: la arquitectura objetivo combina Cloud Run, Cloud Functions, Cloud Run Jobs, VM Spot y un clúster de GKE en reserva.

Repasando el módulo entero: creamos máquinas virtuales con plantillas, grupos gestionados regionales, autoescalado y reparación automática; movimos los 60 GB de imágenes al bucket alpinashop-catalogo con clases de almacenamiento, ciclo de vida, versionado y URLs firmadas; migramos la base de datos tienda a alpinashop-pedidos con alta disponibilidad regional, PITR y réplica de lectura; probamos App Engine con su app.yaml, su división de tráfico y su cron, y lo descartamos con argumentos; contenedorizamos la aplicación, la publicamos en Artifact Registry y la desplegamos en alpinashop-cluster sobre GKE Autopilot con HPA, sondas, secretos y actualizaciones sin corte; repartimos los datos entre Cloud SQL, Firestore, Memorystore, Cloud Storage y BigQuery con un árbol de decisión; y hemos terminado documentando y fechando la arquitectura completa. La migración de AlpinaShop ya no es un plan: es infraestructura que funciona.

Y termina con un problema evidente. Todo lo que hemos construido está expuesto: la VM tiene el puerto 80 abierto a internet, el Service de GKE publicó una IP sin HTTPS, la base de datos es alcanzable desde fuera, no hay dominio propio ni certificado, no hay protección frente a ataques y no existe separación de red entre lo que debe ser público y lo que nunca debería serlo. En el módulo 3, Redes y seguridad, lo arreglamos de raíz: diseñaremos la red VPC de AlpinaShop con subredes y reglas de firewall, pondremos un balanceador de carga HTTPS global delante del catálogo, aceleraremos las imágenes con Cloud CDN, repartiremos permisos con IAM aplicando el mínimo privilegio a Marta, Dani y Lucía, protegeremos la tienda con Cloud Armor, guardaremos las credenciales en Secret Manager con cifrado gestionado por Cloud KMS, y publicaremos alpinashop.example con Cloud DNS y certificados TLS gestionados. Lo que hoy funciona pasará a ser, además, publicable.