Modulo 01. Introduccion a Google Cloud

Objetivo del modulo

Entender qué aporta Google Cloud como plataforma y cómo se diferencia su organización básica frente a otros proveedores.

Resultados esperados

• Explicar la propuesta de valor de GCP.
• Reconocer el papel de proyectos, regiones y red global.
• Relacionar casos de uso con servicios fundacionales de la plataforma.

Desarrollo teorico

Google Cloud Platform se apoya en una red global privada, una fuerte orientacion a servicios gestionados y una organizacion de recursos centrada en el concepto de proyecto. Para muchos equipos, GCP resulta atractiva por sus capacidades en analitica, datos, contenedores y servicios gestionados, pero tambien por la simplicidad conceptual de algunos bloques clave una vez entiendes como se organizan proyectos, IAM y recursos.

La computacion en nube en GCP comparte principios con otros hyperscalers: pago por uso, elasticidad, automatizacion y servicios bajo demanda. Sin embargo, conviene entender la terminologia propia y las decisiones de diseño que diferencian a Google Cloud de AWS o Azure. Mientras AWS organiza recursos por cuenta y region, y Azure lo hace por suscripcion y grupo de recursos, GCP utiliza el proyecto como unidad central. El proyecto agrupa recursos, permisos IAM, APIs habilitadas y facturacion en un contenedor logico que determina el ambito de casi toda la operacion.

La red global de Google es uno de sus diferenciadores tecnicos mas relevantes. Google opera una de las redes privadas mas grandes del mundo, con cables submarinos propios, puntos de presencia en mas de 180 paises y una arquitectura de red definida por software. Esto tiene implicaciones practicas directas: el trafico entre regiones de GCP viaja por la red privada de Google en lugar de por internet publico, lo que reduce latencia y mejora seguridad. El modelo de red Premium Tier enruta trafico por la red de Google desde el punto de presencia mas cercano al usuario, mientras que el Standard Tier usa internet publico hasta la region de destino, con menor coste pero mayor latencia.

Las regiones y zonas definen donde se despliegan los recursos. Una region es una ubicacion geografica independiente, como europe-west1 (Belgica), europe-southwest1 (Madrid) o us-central1 (Iowa). Cada region contiene al menos tres zonas, que son centros de datos independientes con alimentacion, refrigeracion y red propias. Esta estructura permite diseñar arquitecturas resilientes distribuyendo recursos entre zonas dentro de una region o entre regiones para disaster recovery. No todos los recursos son zonales: algunos como Cloud Storage son regionales o multi-regionales, y otros como las reglas de firewall o los roles IAM son globales.

A nivel de organizacion de recursos, GCP ofrece una jerarquia que escala desde proyectos individuales hasta estructuras corporativas complejas. En la base estan los recursos individuales: instancias de Compute Engine, buckets de Cloud Storage, bases de datos Cloud SQL. Estos recursos viven dentro de un proyecto. Los proyectos pueden agruparse en carpetas, que a su vez pueden anidarse. En la cima esta la organizacion, vinculada al dominio de Google Workspace o Cloud Identity. Las politicas IAM y las politicas de organizacion se heredan hacia abajo en esta jerarquia, lo que permite aplicar controles de seguridad y gobernanza de forma centralizada.

Para un equipo que empieza con GCP, los primeros servicios que conviene dominar son los fundacionales. Compute Engine proporciona maquinas virtuales con control completo del sistema operativo, similar a EC2 en AWS. Cloud Storage ofrece almacenamiento de objetos escalable con diferentes clases de almacenamiento segun frecuencia de acceso: Standard, Nearline, Coldline y Archive. Cloud SQL gestiona bases de datos relacionales (MySQL, PostgreSQL, SQL Server) eliminando la carga de parcheo, backups y alta disponibilidad. Cloud Run permite ejecutar contenedores de forma serverless, pagando solo por el tiempo de ejecucion. Y VPC proporciona redes virtuales privadas con subredes, reglas de firewall y conectividad.

El modelo de facturacion de GCP tiene caracteristicas propias que conviene entender desde el principio. La facturacion se vincula a una cuenta de facturacion que puede asociarse a uno o varios proyectos. Los descuentos por uso sostenido se aplican automaticamente cuando un recurso se usa mas del 25 por ciento del mes, sin necesidad de compromisos previos. Los compromisos de uso (CUDs) ofrecen descuentos mayores a cambio de reservar capacidad por uno o tres años. Las etiquetas (labels) permiten categorizar recursos para analisis de costes, aunque no afectan a permisos ni a la estructura logica del proyecto.

La consola de Google Cloud es la interfaz web principal para gestionar recursos, pero el trabajo serio con GCP requiere familiarizarse con herramientas adicionales. Cloud Shell proporciona un terminal en el navegador con gcloud CLI preinstalado y 5 GB de almacenamiento persistente. El SDK de Google Cloud (gcloud, gsutil, bq) permite gestionar recursos desde la linea de comandos local. Terraform y otras herramientas de infraestructura como codigo son fundamentales para entornos productivos. Y las APIs REST de GCP permiten automatizar cualquier operacion de forma programatica.

Los casos de uso donde GCP destaca especialmente incluyen analitica de datos y machine learning con BigQuery, Dataflow y Vertex AI; orquestacion de contenedores con GKE, que se beneficia de la experiencia de Google como creador de Kubernetes; aplicaciones serverless con Cloud Run y Cloud Functions; y cargas de trabajo que requieren alta conectividad global gracias a la red privada de Google. Tambien es frecuente ver GCP en estrategias multicloud, donde las organizaciones combinan proveedores segun fortalezas, usando por ejemplo GCP para datos y analitica mientras mantienen otros workloads en AWS o Azure.

La diferencia entre IaaS, PaaS y SaaS se manifiesta claramente en el catalogo de GCP. Compute Engine es IaaS: tu gestionas sistema operativo, runtime y aplicacion. Cloud Run y App Engine son PaaS: tu aportas la aplicacion y la plataforma gestiona infraestructura y escalado. Google Workspace es SaaS: todo esta gestionado. Elegir el nivel de abstraccion correcto para cada carga de trabajo es una de las decisiones mas importantes al diseñar en GCP, porque afecta directamente a coste, complejidad operativa, flexibilidad y responsabilidades de seguridad.

El modelo de responsabilidad compartida de GCP sigue el patron estandar de la industria: Google se responsabiliza de la seguridad de la nube (hardware, red, centros de datos, servicios base) y el cliente se responsabiliza de la seguridad en la nube (datos, identidades, configuraciones, aplicaciones). La frontera exacta varia segun el servicio: en Compute Engine el cliente gestiona desde el sistema operativo hacia arriba; en Cloud Run, desde la aplicacion; en BigQuery, desde los datos y permisos. Entender este modelo desde el primer dia evita asumir que la nube es segura por defecto sin configuracion del cliente.

Contenido ampliado

Puntos clave

• El proyecto es una pieza central en Google Cloud.
• GCP combina infraestructura, plataforma y servicios de datos con fuerte integración.
• Entender organización de recursos evita perderse en el catálogo.

Checklist operativa

• Identificar qué caso de uso se quiere resolver.
• Entender en qué proyecto vivirían los recursos.
• Relacionar región o zona con latencia y disponibilidad.

Errores frecuentes

• Pensar que todos los recursos son globales.
• Crear proyectos sin ownership o sin estructura lógica.
• Enfocar GCP solo como catálogo y no como plataforma organizada.

Practica sugerida

Describe cómo organizarías en GCP una aplicación sencilla con frontend, backend y almacenamiento.

Preguntas de autoevaluacion

• ¿Qué función cumple un proyecto en GCP?
• ¿Por qué región y zona no son lo mismo?
• ¿Qué valor diferencial sueles asociar a Google Cloud?

Cierre

Entender Google Cloud empieza por comprender cómo organiza recursos y cómo su propuesta combina agilidad operativa con servicios gestionados muy integrados.

Modulo 02. Proyectos, regiones y organizacion de recursos

Objetivo del modulo

Aprender a estructurar recursos en GCP con criterio de ownership, facturación y operación.

Resultados esperados

• Diferenciar proyecto, región y zona.
• Entender cómo se agrupan recursos y permisos.
• Evitar estructuras caóticas que dificulten gobierno y coste.

Desarrollo teorico

En GCP, el proyecto es el contenedor operativo clave. Afecta facturacion, IAM, APIs habilitadas y aislamiento logico de recursos. Esto hace que la decision de crear uno o varios proyectos sea mas importante de lo que parece. Separar produccion, desarrollo o distintas unidades puede mejorar control, coste y blast radius, pero tambien exige un modelo claro de gobierno.

El proyecto en GCP funciona como un espacio de nombres para recursos, un ambito para permisos IAM y una unidad de facturacion. Cada proyecto tiene un ID unico global inmutable (como mi-proyecto-prod-2026), un nombre editable y un numero de proyecto asignado automaticamente. Las APIs de Google Cloud se habilitan por proyecto, lo que significa que si necesitas BigQuery en un proyecto, debes activar la API alli explicitamente. Esta granularidad puede parecer pesada al principio, pero ofrece un control preciso sobre que servicios estan disponibles en cada contexto.

La estrategia de proyectos determina la salud operativa de la plataforma a largo plazo. El patron mas comun en entornos profesionales separa al menos tres proyectos: desarrollo, staging y produccion. Esto permite aplicar politicas IAM diferentes en cada entorno, asignar presupuestos independientes, limitar el blast radius de errores y mantener logs y metricas separados. En organizaciones mas grandes, es habitual tener proyectos adicionales para servicios compartidos (networking, logging centralizado, identidad), proyectos de sandbox para experimentacion, y proyectos dedicados por equipo o por aplicacion. La clave es encontrar el equilibrio entre aislamiento suficiente y complejidad operativa manejable.

La jerarquia de recursos en GCP se compone de cuatro niveles principales. En la cima esta la organizacion, que representa a la empresa y se vincula al dominio de Google Workspace o Cloud Identity. Debajo estan las carpetas, que permiten agrupar proyectos por departamento, entorno, region geografica o cualquier criterio organizativo. Los proyectos viven dentro de carpetas o directamente bajo la organizacion. Y los recursos individuales (VMs, buckets, bases de datos) viven dentro de los proyectos. Las politicas IAM y las politicas de organizacion se heredan de arriba hacia abajo: una politica aplicada a una carpeta afecta a todos los proyectos dentro de ella, y una aplicada a la organizacion afecta a todo.

Las politicas de organizacion son restricciones que se aplican a nivel de organizacion, carpeta o proyecto y que limitan lo que se puede hacer independientemente de los permisos IAM. Por ejemplo, se puede establecer una politica que impida crear recursos en determinadas regiones (util para cumplimiento de residencia de datos), que restrinja las cuentas externas que pueden recibir permisos, o que obligue a cifrar recursos con claves gestionadas por el cliente. Estas politicas actuan como barandillas de gobernanza que previenen errores de configuracion incluso cuando alguien tiene permisos suficientes para cometerlos.

La ubicacion de recursos añade otra dimension critica. GCP clasifica la ubicacion en tres categorias. Los recursos zonales dependen de una zona especifica dentro de una region: una instancia de Compute Engine en europe-west1-b dejara de funcionar si esa zona sufre una interrupcion. Los recursos regionales se distribuyen o son accesibles dentro de una region completa: una direccion IP regional, un disco regional replicado entre zonas, o un cluster regional de Cloud SQL que replica automaticamente entre zonas de la misma region. Los recursos globales son accesibles desde cualquier ubicacion: reglas de firewall, imagenes, roles IAM o redes VPC. Entender esta clasificacion es esencial para diseñar alta disponibilidad y disaster recovery.

La eleccion de region afecta a latencia, disponibilidad, coste y cumplimiento normativo. Para usuarios en España, europe-southwest1 (Madrid) ofrece la menor latencia. europe-west1 (Belgica) y europe-west3 (Frankfurt) son opciones frecuentes para organizaciones europeas que necesitan cumplir con RGPD. No todas las regiones ofrecen todos los servicios ni las mismas configuraciones de maquinas, por lo que conviene verificar disponibilidad antes de comprometerse con una region. Los precios tambien varian entre regiones: una VM identica puede costar un porcentaje diferente en us-central1 que en europe-west1.

El naming convention y el etiquetado son aspectos que parecen menores pero impactan en la operacion diaria. Un nombre de proyecto debe ser descriptivo, incluir entorno y ser coherente con una convencion global: empresa-app-prod, empresa-data-dev, empresa-shared-networking. Las etiquetas (labels) permiten añadir metadatos clave-valor a recursos para filtrado, analisis de costes y automatizacion: env:prod, team:platform, cost-center:engineering. A diferencia de las etiquetas en otros proveedores, las labels de GCP no afectan a permisos ni heredan en la jerarquia, pero son fundamentales para reportes de facturacion y para localizar recursos.

La facturacion en GCP se gestiona mediante cuentas de facturacion que se asocian a proyectos. Un proyecto sin cuenta de facturacion no puede consumir recursos de pago. Es posible tener multiples cuentas de facturacion para separar centros de coste, y cada cuenta puede configurar presupuestos con alertas que avisan al alcanzar umbrales definidos (por ejemplo, el 50, 80 y 100 por ciento del presupuesto mensual). Los informes de facturacion pueden exportarse a BigQuery para analisis detallado, lo que permite construir dashboards de costes, identificar tendencias y detectar anomalias.

La gobernanza a escala requiere combinar jerarquia, IAM, politicas de organizacion, etiquetado y facturacion de forma coherente. Un error frecuente en organizaciones que crecen rapido en GCP es dejar que cada equipo cree proyectos sin criterio, sin naming, sin labels y sin vincular a la estructura organizativa. El resultado es un inventario caotico donde nadie sabe que recursos existen, a quien pertenecen ni cuanto cuestan. Corregir esto a posteriori es mucho mas costoso que establecer las reglas basicas desde el principio. Las Landing Zones de GCP, documentadas en el Cloud Foundation Toolkit, proporcionan patrones y plantillas de Terraform para establecer esta estructura de forma automatizada y repetible.

Contenido ampliado

Puntos clave

• El proyecto es la unidad básica de organización y control.
• Separar bien entornos reduce riesgo y mejora gobernanza.
• Región y zona afectan diseño y operación.

Checklist operativa

• Decidir cuándo separar proyectos por entorno o equipo.
• Identificar recursos zonales frente a regionales.
• Revisar ownership, naming y facturación asociada.

Errores frecuentes

• Mezclar todo en un único proyecto sin criterio.
• No entender qué recursos dependen de zona concreta.
• Dejar la organización crecer sin estructura común.

Practica sugerida

Plantea una estructura de proyectos para una empresa con desarrollo, pruebas y producción en GCP.

Preguntas de autoevaluacion

• ¿Qué problemas evita separar proyectos?
• ¿Qué diferencia hay entre zona y región?
• ¿Qué relación tiene el proyecto con IAM y facturación?

Cierre

Organizar bien proyectos y ubicaciones es una de las primeras decisiones que marcan la salud futura de una plataforma en Google Cloud.