# ADR 0012 — Práctica multi-cloud: GCP y Azure DevOps en paralelo al lab ZimaOS **Estado:** aceptada — Fase 1 (Google Workspace) completa y verificada en vivo, con un giro real: el MCP self-hosted planeado (`taylorwilsdon/google_workspace_mcp`) quedó abandonado por un límite real de esa librería (ver §Fase 1), reemplazado por los Connectors nativos de claude.ai. Fases 2-4 quedan documentadas como roadmap, explícitamente no implementadas hasta que se pidan en una sesión futura. **Fecha:** 2026-09-20 (Fase 1 cerrada 2026-09-21) ## Contexto El lab GitOps de CruzCloud (ZimaOS + k3d + Gitea + Argo CD) ya prueba en vivo, con rigor de ADR, patrones que después se pueden proponer en trabajo real con clientes — pero corre íntegro sobre hardware propio, sin tocar ningún proveedor de nube público. Dos motivaciones concretas empujan a abrir una segunda línea de práctica en paralelo: 1. **Practicar herramientas que el cliente actual restringe.** Ciertas plataformas/herramientas de nube no están disponibles en el entorno de trabajo del cliente actual — la única forma real de ganar experiencia con ellas es un entorno propio. 2. **Preparar propuestas de arquitectura con evidencia, no solo teoría.** Poder decir "ya lo corrí, así se ve, esto cuesta X" en una propuesta a un cliente vale más que una descripción de manual. 3. **Portafolio.** Los mismos ADRs, diagramas y decisiones documentadas que ya sostiene este lab sirven como muestra de trabajo verificable. **Alcance confirmado explícitamente por el usuario, no asumido:** - **Entorno paralelo, no migración.** ZimaOS sigue siendo el lab principal — nada de lo de acá reemplaza nada de lo ya construido. - **Cuentas personales únicamente.** Nunca credenciales del cliente actual ni de ningún cliente futuro — separación total. - **Costo cero o mínimo**, con alertas de presupuesto como red de seguridad desde el primer recurso pago que se cree (ver [Análisis de costo](#analisis-de-costo-explicito) más abajo). - Mismo rigor documental que el resto del lab: un ADR por decisión arquitectónica real, diagramas Mermaid, cifras verificadas en vivo o contra fuente primaria (no contra un blog de terceros sin corroborar — ver el caso del supuesto MCP "oficial" de Google Workspace en la [Fase 1](#fase-1-ejecutada-google-workspace-con-un-giro-real-en-la-implementacion)). ## Diagrama del lab actual (ZimaOS) Versión simplificada, con solo los componentes relevantes para la comparación de este ADR — el diagrama completo (con Traefik, `serverlb`, cada `Host` de Ingress, etc.) vive en [Visión general](../arquitectura/vision-general.md). ```mermaid flowchart LR User(["Usuario"]) -->|HTTPS| CF["Cloudflare Tunnel
(sin puertos abiertos)"] CF --> NPM["Nginx Proxy Manager
enrutamiento por dominio"] NPM --> K3D["k3d
(cluster K8s local, Docker)"] subgraph K3D_INT["Dentro de k3d"] ARGO["Argo CD"] -->|sync| APPS["Apps reales
(ecommerce, docs-portal)"] GIT["Gitea
(auto-alojado)"] -.->|watch repos| ARGO end K3D --> K3D_INT ``` **Costo real:** $0 — hardware propio (NAS ZimaOS), sin proveedor de nube de por medio. ## Diagrama Fase 1 — entorno paralelo en GCP (VM + k3s) **Esto NO es GKE administrado.** Es una VM `e2-micro` corriendo k3s self-managed, elegida específicamente para mantener el costo real en $0 — GKE (administrado, ver [Fase 4](#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado)) no tiene una vía 100% gratuita permanente (ver el análisis de costo más abajo). ```mermaid flowchart LR User(["Usuario / Claude"]) -->|SSH / kubectl| VM["Compute Engine e2-micro
Always Free — us-west1/us-central1/us-east1
NO es GKE administrado"] subgraph VM_INT["Dentro de la VM"] K3S["k3s
(single-node, self-managed)"] ARGO2["Argo CD
(instancia propia, no la de ZimaOS)"] -->|sync| APPS2["Manifiestos del nuevo repo
(mismo patrón base+overlay
de platform-templates)"] end VM --> VM_INT GIT_EXISTENTE["Gitea existente
gitea.cruzcloud.net
(reusado, repo nuevo, NO uno nuevo)"] -.->|watch| ARGO2 ``` **Por qué reusar el Gitea existente en vez de levantar uno nuevo en GCP:** el objetivo es practicar el patrón GitOps completo (Kustomize base+overlay + Argo CD sincronizando) con el mínimo de piezas nuevas — levantar un segundo Gitea solo sumaría superficie a mantener sin enseñar nada nuevo sobre GCP en sí. El *cómputo* (la VM, k3s) es lo que cambia de proveedor; el origen de verdad (Git) se queda donde ya funciona. **Costo real:** $0 — `e2-micro` es Always Free **de forma permanente** (no es el trial de $300/90 días), siempre que la VM viva en `us-west1`, `us-central1` o `us-east1` y no supere 1 instancia no-preemptible + 30 GB-mes de disco persistente estándar + 1 GB/mes de salida hacia Norteamérica — límites reales del programa, verificados contra la documentación oficial de Google Cloud.[^1] ## Fase futura (no implementada) — GKE real con Spot + auto-apagado Marcada explícitamente como **fase futura, no implementada** — ver [Fase 4](#fase-4-documentar-no-ejecutar-gke-real-con-spot-auto-apagado) para cuándo se decidiría ejecutarla. ```mermaid flowchart LR TF["Terraform
(provisiona todo)"] --> GKE["GKE Standard
1 cluster zonal"] GKE --> NP["Node pool
Spot VMs (e2-small)"] SCHED["Cloud Scheduler
(cron: apagar/prender)"] -->|invoca| FN["Cloud Run/Functions
job de auto-apagado"] FN -->|resize node pool
a 0 / de vuelta| NP style GKE fill:#333,stroke:#f90,color:#fff style NP fill:#333,stroke:#f90,color:#fff style SCHED fill:#333,stroke:#f90,color:#fff style FN fill:#333,stroke:#f90,color:#fff ``` ### Mecanismo de auto-apagado: comparación antes de recomendar Dos mecanismos reales existen para esto; se investigaron ambos antes de elegir uno, sin asumir cuál es "obviamente" mejor: | | Escalar node pool a 0 | Destruir/recrear cluster completo (`terraform apply`/`destroy` programado) | |---|---|---| | Qué apaga | Solo el cómputo (los nodos) | Todo, incluido el control plane | | Ahorra el fee de control plane ($0.10/hora) | No — pero **ya está cubierto por el crédito mensual de $74.40** para un único cluster, así que no hay nada real que ahorrar ahí | Sí, pero es un ahorro sobre algo que ya es $0 | | Tiempo de "volver a prender" | ~1-3 min (crear nodos sobre un cluster que ya existe) | ~5-10 min (crear el cluster entero de cero) | | Piezas para automatizarlo | Cloud Scheduler → Cloud Function/Run → 1 llamada a la API de GKE (resize node pool) | Cloud Scheduler → runner con Terraform + credenciales + state remoto seguro → `apply`/`destroy` completo | | Riesgo de drift/config perdida | Bajo — el cluster nunca se borra | Mayor — cualquier cosa hecha fuera de Terraform se pierde en cada destroy | | Patrón documentado en la industria | Sí, es el patrón estándar (Cloud Scheduler + Pub/Sub + Cloud Function), con casos reales de ~30% de ahorro de cómputo en clusters no-críticos[^2] | Existe, pero es la opción menos común para este caso puntual | **Recomendación (sin implementar todavía):** escalar el node pool a 0/de vuelta vía Cloud Scheduler + Cloud Function, no destruir/recrear el cluster completo. Razón concreta: el crédito de $74.40/mes **ya cubre el fee de control plane de un único cluster exista o no exista un nodo adentro** — destruir el cluster entero no ahorra nada sobre ese componente porque ya es $0, y a cambio suma la complejidad real de manejar Terraform state de forma segura dentro de un cron job automatizado, más un tiempo de arranque 3-5x más largo. La única razón real para preferir destruir/recrear sería eliminar *toda* huella en GCP entre usos (por ejemplo, para no depender de que el crédito mensual siga existiendo) — no es el caso acá. ## Tabla comparativa | | Lab actual (ZimaOS) | GCP Fase 1 (VM + k3s) | GCP Fase futura (GKE + Spot) | |---|---|---|---| | Cómputo | NAS propio, Docker/k3d | Compute Engine `e2-micro` | GKE Standard, node pool Spot `e2-small` | | ¿Kubernetes administrado? | No (k3d local) | No (k3s self-managed) | Sí (GKE Standard) | | Control plane | N/A (local) | N/A (k3s corre en la misma VM) | $0.10/hora — cubierto por crédito de $74.40/mes para 1 cluster | | Cómputo de nodos | $0 (hardware propio) | $0 (Always Free permanente) | ~$7-10/mes (Spot `e2-small`, sin cubrir por ningún crédito) | | GitOps | Argo CD + Gitea, ambos autoalojados | Argo CD propio en la VM, mismo Gitea reusado | Igual que Fase 1, sobre GKE | | Costo mensual real | $0 | $0 | ~$7-10/mes (no $0) | | Estado | En producción, uso diario | A ejecutar esta sesión (Parte 2/3) | Documentado, no implementado | ## Análisis de costo explícito **No existe un GKE administrado 100% gratis de forma permanente.** El crédito de $74.40/mes por cuenta de facturación cubre exactamente el fee de control plane ($0.10/hora) de **un** cluster zonal Standard o Autopilot — nunca el cómputo real. GKE Autopilot factura desde el primer pod que se programa (vCPU/memoria/almacenamiento por pod), sin ningún equivalente al Always Free de Compute Engine; GKE Standard sí puede correr sobre un único nodo Spot/preemptible barato (~$7/mes para un `e2-small`, verificado contra tarifas actuales), pero ese cómputo nunca es gratis.[^3] **La única ruta de costo cero real y permanente es Compute Engine `e2-micro` (Always Free) + k3s self-managed** — exactamente la Fase 1 de este ADR. No es el trial de $300/90 días (que expira y no es "gratis", es prepago con reloj corriendo); es un beneficio permanente del programa de nivel gratuito de Google Cloud, activo mientras la VM cumpla los límites de región/tamaño/tráfico ya descritos arriba. **Activar cualquier billing account de GCP requiere tarjeta igual**, incluso para quedarse exclusivamente en recursos Always Free — Google verifica el medio de pago aunque el cargo real sea $0. Detalle no obvio, verificado contra documentación oficial: **las alertas de presupuesto no se pueden configurar mientras la cuenta esté operando sobre crédito gratuito de prueba** — hace falta pasar la cuenta de facturación a estado "paga" (el uso real sigue siendo $0 si no se sale del Always Free) para que la opción de crear un presupuesto/alerta quede disponible.[^4] **Recomendación:** hacer ese paso — pasar a cuenta de facturación paga — como parte del setup inicial, y configurar de inmediato una alerta de presupuesto en **$1-5 USD** como red de seguridad, antes de crear ningún recurso más allá de lo cubierto por Always Free. ## Secuencia de fases Todas documentadas acá; **solo la Fase 1 se ejecuta en esta sesión.** Las Fases 2-4 no se implementan sin pedido explícito en una sesión futura — quedan como roadmap, no como trabajo en curso. ### Fase 1 (ejecutada) — Google Workspace, con un giro real en la implementación **Objetivo cumplido — acceso real a Google Calendar desde Claude, verificado en vivo — pero por un camino distinto al planeado originalmente.** Detalle de la investigación previa (qué MCP usar, oficial vs comunitario) — resumen: **no existe un MCP oficial de Google Workspace** publicado por Google (se verificó explícitamente buscando en los GitHub `google`/`googleworkspace` oficiales — no aparece ninguno; un solo blog de terceros afirma que "ya existe uno oficial" sin que ninguna otra fuente lo corrobore, así que se descarta esa afirmación por no verificable). Se optó por `taylorwilsdon/google_workspace_mcp` (comunitario, el más completo y activamente mantenido: 120+ herramientas, OAuth 2.1, +2500 estrellas) como primer intento, self-hosted dentro de `tmux-host`. **Ese self-hosted quedó abandonado — límite real encontrado en la librería, no un error de configuración.** El servidor usa FastMCP's `GoogleProvider`/`OAuthProxy`, que construye el `redirect_uri` enviado a Google directamente desde su propio `base_url` — **no** desde la variable `GOOGLE_OAUTH_REDIRECT_URI` que el proyecto expone (esa variable solo valida entradas, no arma la salida real; hallazgo confirmado leyendo el código fuente instalado, no la documentación pública). Y `base_url` es la misma variable de la que depende por default `issuer_url`, que el SDK de MCP exige sea HTTPS salvo que sea literalmente `localhost`/`127.0.0.1` (chequeo hardcodeado en `mcp/server/auth/routes.py:validate_issuer_url`, sin variable de entorno que lo salte). Resultado: **no hay combinación de variables de entorno que satisfaga a la vez** "el navegador del usuario debe poder llegar al callback" (necesita un dominio real, no `localhost`) y "el issuer debe ser HTTPS o `localhost`" — `workspace-mcp` no expone `issuer_url` por separado de `base_url` en su capa de configuración (confirmado en `core/server.py`: solo pasa `base_url` a `GoogleProvider(...)`). **Decisión del usuario ante ese límite:** en vez de armar un proxy HTTPS con certificado autofirmado (infraestructura extra, fricción de certificado no confiable en cada uso) o parchear el paquete instalado a mano (frágil, se pierde en cualquier reinstalación), se usaron los **Connectors nativos de claude.ai** (Google Calendar, vía el directorio de conectores de la cuenta, fuera de Claude Code por completo) — mismo resultado práctico (Claude con acceso real al calendario personal), infraestructura cero de nuestro lado, sin tocar código de terceros. Contrapartida real: es una integración de cuenta de claude.ai, no un MCP configurado dentro del proyecto `platform-multicloud` — no aparece como herramienta en sesiones de Claude Code (`lab`/`cloud-practice`), solo en el chat normal de claude.ai. **Verificado en vivo:** pregunta real en claude.ai normal ("¿qué tengo en el calendario esta semana?") devolvió una respuesta correcta revisando 3 calendarios reales de la cuenta (principal, Familia, festivos de Colombia) vía la herramienta `Google Calendar: Lists calendar events`, con razonamiento correcto sobre qué cuenta como "esta semana" dado el día/hora real de la consulta. ### Fase 2 (documentar, no ejecutar) — Terraform aislado Instalar el marketplace oficial de HashiCorp Agent Skills, y practicar aprovisionando algo mínimo y desechable en GCP. Nota para cuando se ejecute: HashiCorp también publica un **MCP Server de Terraform** propio y oficial (`hashicorp/terraform-mcp-server`, integra con el Terraform Registry y HCP Terraform) — es una pieza distinta a los Agent Skills (el MCP es el "tubo" hacia herramientas reales; los Skills son paquetes de conocimiento/instrucciones) y vale la pena evaluar si se usan juntos o solo uno de los dos en ese momento. ### Fase 3 (documentar, no ejecutar) — Azure DevOps en paralelo MCP oficial `microsoft/azure-devops-mcp` (confirmado como el oficial y activamente mantenido por Microsoft, hay varios forks/alternativas comunitarias que no son la vía recomendada). Replicar el mismo pipeline DevSecOps que ya corre en Gitea Actions para este lab (Gitleaks → Trivy → Semgrep → Syft → Cosign) como Azure Pipelines YAML, en un proyecto personal — mismo objetivo de práctica que la Fase 1: tener el patrón ya probado para proponerlo en trabajo con clientes que usen Azure DevOps. ### Fase 4 (documentar, no ejecutar) — GKE real con Spot + auto-apagado Solo si se decide conscientemente asumir el costo bajo pero no-cero (~$7-10/mes, ver el análisis de costo arriba) — vía Terraform, node pool Spot, y el mecanismo de auto-apagado recomendado en la sección de arriba (escalar a 0, no destruir/recrear el cluster). ## Opciones consideradas | Opción | A favor | En contra | |---|---|---| | Entorno paralelo en GCP+Azure (elegido) | Practica exactamente lo que el cliente actual restringe; portafolio con evidencia real; ZimaOS sigue intacto | Dos entornos más que mantener; curva de aprendizaje de dos proveedores nuevos a la vez | | Migrar el lab completo a un solo cloud | Un solo entorno que mantener | Pierde justo lo que se quiere conservar (costo $0, control total de hardware); no es lo que se pidió | | Solo AWS (el "default" de la industria) | Ecosistema más grande | El cliente actual ya usa/restringe otras plataformas específicas — practicar AWS no cierra esa brecha puntual | | GKE administrado desde el día 1 (saltear la VM self-managed) | Más parecido a "producción real" desde el inicio | Rompe el requisito de costo cero explícito del usuario — ningún tier de GKE es gratis de forma permanente | ## Decisión Se abre una línea de práctica multi-cloud paralela al lab ZimaOS, en cuentas personales, arrancando por Compute Engine `e2-micro` (Always Free) + k3s self-managed en GCP como Fase 1 de cómputo, y Google Workspace vía MCP comunitario (`taylorwilsdon/google_workspace_mcp`) como primer MCP a configurar en esta sesión. Terraform, Azure DevOps y GKE administrado quedan documentados como Fases 2-4, sin implementar. ## Consecuencias - **Se gana** un segundo entorno real, documentado con el mismo rigor de ADR que ya sostiene el lab, listo para mostrar en propuestas a clientes — sin tocar nunca credenciales de cliente. - **Se sacrifica/queda como deuda técnica:** la Fase 1 de GCP usa k3s self-managed, no un Kubernetes administrado real — cualquier lección específica de operar GKE (autoscaling nativo, node pools, IAM de GCP) queda pendiente hasta la Fase 4, y esa fase sí tiene costo real (~$7-10/mes) que hoy no se está pagando. - **Para revertir:** dar de baja la VM `e2-micro` y (si se llegó a crear) el node pool de la Fase 4 — ningún componente de este ADR toca o depende del lab ZimaOS existente, así que no hay nada que revertir de ese lado. [^1]: [Compute Engine Free Tier — Google Cloud](https://cloud.google.com/free/docs/compute-getting-started), [GCP Free Tier Complete Guide 2026](https://agentdeals.dev/gcp-free-tier-2026) [^2]: [Reduce Your GKE Bill with Cloud Scheduler by Scaling to Zero](https://chimbu.medium.com/reduce-your-gke-bill-with-cloud-scheduler-by-scaling-to-zero-during-off-peak-hours-9796bb4f7b8b), [Scaling GKE Standard Clusters to Zero](https://medium.com/@gustavo.romerobenitez_34616/scaling-gke-standard-clusters-to-zero-56bf5270510e) [^3]: [GKE Pricing Guide 2026 — Sedai](https://sedai.io/blog/google-cloud-kubernetes-cluster-cost), [e2-small pricing — Economize](https://www.economize.cloud/resources/gcp/pricing/compute-engine/e2-small/), [Google Kubernetes Engine pricing — Google Cloud](https://cloud.google.com/kubernetes-engine/pricing) [^4]: [Google Cloud Free Trial FAQs](https://cloud.google.com/signup-faqs), [Create, edit, or delete budgets and budget alerts — Google Cloud](https://docs.cloud.google.com/billing/docs/how-to/budgets)