Google Cloud encaja bien cuando lo difícil es runtime gobernado: Kubernetes, identidad, networking, observabilidad y entornos de desarrollo que se crean y destruyen constantemente.
Lo elegimos cuando el control del runtime es el producto. Eso normalmente significa infraestructura para desarrolladores, sandboxes de agentes, entornos de CI o workloads donde aislamiento y lifecycle importan más que una superficie rápida de chatbot.
Dónde encaja Google Cloud
- Infraestructura para desarrolladores con GKE como plano de control.
- Workloads de agentes o CI que necesitan sandboxes aislados con NetworkPolicy predecible.
- Equipos que ya operan Google Cloud y quieren que las funciones de IA hereden el mismo modelo de release e incidentes.
- Productos donde los agentes necesitan sus propios entornos gobernados en vez de tomar prestados los permisos de un desarrollador humano.
Qué miramos de cerca
- Complejidad de Kubernetes. GKE es potente, pero el producto debe esconder namespaces, políticas y lifecycle del usuario.
- Costo de entornos. Entornos por rama y por agente se multiplican rápido si TTL, líneas base compartidas y cleanup no son comportamiento central.
- Bordes de identidad. Usuarios humanos, jobs de CI y agentes necesitan scopes distintos aunque toquen el mismo entorno.
Decisiones que solemos tomar
- Usar primitivos nativos de GKE cuando recuperan tiempo en vez de abstraer multi-cloud demasiado pronto.
- Hacer teardown, TTL y audit trail parte del flujo principal.
- Poner métricas y logs antes de exponer creación self-serve de entornos.
- Diseñar sandboxes de agentes como usuarios gobernados, no como excepción.
Qué incluimos en el handover
- Modelo de namespaces, NetworkPolicy e identidad para humanos, jobs de CI y agentes.
- Reglas de lifecycle de entornos: crear, compartir, snapshot, expirar, destruir.
- Métricas y logs ligados a cada workspace, PR, run de agente o acción de usuario.
- Controles de costo para entornos idle, builds repetidos, líneas base compartidas y cleanup.
- Runbooks para provisioning fallido, recursos filtrados, violaciones de política y teardown trabado.
Cuándo lo evitamos
Si el producto es principalmente workflow de documentos, automatización back-office o una herramienta interna de IA acotada, Kubernetes puede ser más maquinaria que problema. Usamos Google Cloud cuando runtime gobernado es central, no cuando solo necesitamos hospedar una API.
Trabajo relacionado
Microstax es el ejemplo público: namespaces de Kubernetes aislados, entornos de referencia compartidos, entornos por PR, logs, métricas y primitivos listos para agentes.