Servicios de consultoría de Google Cloud (GCP) para empresas

GCP Migration Center (antes StratoZone + Migrate for Compute Engine) es la superficie principal de descubrimiento para entornos de origen VMware, AWS y Azure. Desplegamos el colector mcdc, ingerimos el inventario de VMware vCenter o los datos de facturación de la nube y hacemos análisis de grupos para producir comparaciones de TCO frente a destinos GCE, GKE Autopilot, Cloud Run y Cloud SQL. El resultado es una decisión de las 7R por aplicación (el planteamiento de Google es similar al de AWS) con una proyección de costes defendible. Complementamos el punto ciego de Migration Center en la capa de aplicación con nuestro propio trazado de dependencias con eBPF durante dos semanas cuando importan los patrones de tráfico este-oeste.

Terraform con los módulos oficiales del Cloud Foundation Toolkit (CFT) y Terraform Example Foundation como punto de partida, adaptado a la estructura de su organización. No usamos Config Connector para la base — está bien para recursos de GCP de la capa de aplicación dentro de GKE, pero añade riesgo de radio de impacto en los recursos a nivel de organización. La jerarquía de recursos es organización → carpetas por unidad de negocio → entornos (dev/stage/prod/security/logging) → proyectos. La identidad es Cloud Identity o Workspace federado con su IdP (Okta, Entra ID), con elevación just-in-time obligatoria mediante Privileged Access Manager para roles superiores a visor en proyectos de producción. Las Org Policies imponen la fijación de regiones, OS Login y los requisitos de shielded VM.

Los datos personales de la UE aterrizan en europe-west1 (Bélgica), europe-west3 (Fráncfort), europe-west4 (Países Bajos), europe-west9 (París) o europe-west12 (Turín) según los requisitos de latencia y soberanía. Para cargas soberanas desplegamos en Sovereign Controls by Partner (T-Systems para Alemania, Thales para Francia) donde sea necesario por contrato. Org Policy impone restricciones de ubicación de recursos — denegadas a nivel de organización, no de proyecto. Para el cumplimiento de Schrems II usamos Confidential VMs (AMD SEV / Intel TDX), Cloud KMS con EKM (External Key Manager) para claves custodiadas fuera de GCP, perímetros de VPC Service Controls alrededor de BigQuery y Cloud Storage y cláusulas contractuales tipo en el DPA con los logs de Access Transparency activados.

Cloud Run para servicios HTTP sin estado en los que importan el escalado basado en peticiones y la escala a cero — es la respuesta correcta más barata para aproximadamente el 70 % de los microservicios que vemos, y los equipos que eligen GKE para esas cargas suelen pagar un impuesto de complejidad por nada. GKE Autopilot cuando realmente necesita primitivas de Kubernetes (StatefulSets, sidecars, service mesh, CNI a medida) pero no quiere operar el node pool. GKE Standard solo cuando necesita GPU, configuraciones de nodo a medida o cargas que superan los límites de Autopilot. Cloud Run Jobs para batch y Workflows para orquestación. Nos resistimos al patrón por defecto de «todo en GKE» que añade un 30 % de sobrecarga operativa sin ningún beneficio.

BigQuery es el motivo más sólido por el que la mayoría de los equipos eligen GCP frente a AWS o Azure — sin servidor, separación de almacenamiento y cómputo, BI Engine para paneles en menos de un segundo y un dialecto SQL sensato. Diseñamos con particionado + clustering por defecto, reservas de slots (Editions) para cargas predecibles, bajo demanda para las irregulares y dbt para la transformación. Streaming con Pub/Sub + Dataflow (Apache Beam) o con la Storage Write API de BigQuery para ingesta de baja latencia. Para IA/ML, Vertex AI Pipelines para MLOps, Vertex AI Model Garden para Gemini gestionado y modelos de pesos abiertos y Vertex AI Vector Search para embeddings, con perímetros de VPC Service Controls que imponen el límite de datos sobre todo ello.

Precio todo incluido y de alcance cerrado en USD: servicios individuales desde $200, un lift-and-shift desde $1,800, un re-platform desde $4,100 y una salida completa de AWS/Azure/GCP desde $5,800. Usted ve el presupuesto desglosado al final del descubrimiento y lo aprueba antes de que se escriba una sola línea de código — sin recargo por intermediación, sin sobrecostes por herramientas y con los costes de nube en sus propias cuentas, de modo que usted conserva el control del coste. Los plazos dependen del tamaño del entorno: un entorno de 150 VM con una capa analítica de BigQuery suele completarse en 4–6 meses, con el trabajo de re-platform y de plataforma de datos presupuestado por oleada.

A menudo no conviene mover todo el entorno, y se lo diremos. El caso defendible de GCP suele ser específico de la carga de trabajo: el plano de analítica e IA (BigQuery + Vertex AI) es donde la migración se amortiza, mientras que una aplicación transaccional estable en AWS puede costar más de mover de lo que ahorra. Nuestro descubrimiento produce una comparación de TCO por aplicación — coste de origen frente a destinos GCE, GKE Autopilot, Cloud Run y Cloud SQL — para que la decisión sea una cifra, no una preferencia. Los resultados habituales son un traslado específico de la plataforma de datos a GCP con BigQuery Omni consultando su S3 en el sitio, o un re-platform completo cuando la factura de origen y la dependencia lo justifican. No tenemos una cuota de migraciones que cumplir.

FinOps está integrado en la base, no se añade después. Committed Use Discounts y Sustained Use Discounts dimensionados según la utilización real, escala a cero de Cloud Run para servicios inactivos, reservas de slots de BigQuery Editions en lugar de un consumo bajo demanda descontrolado, alertas de presupuesto e informes de desperdicio de Recommender conectados a su equipo y atribución de costes por proyecto/etiqueta para que cada equipo sea dueño de su gasto. La exportación de facturación llega a BigQuery con un panel de Looker Studio que usted conserva. El objetivo es una factura que su equipo financiero pueda leer línea a línea, no una factura de BigQuery de seis cifras que nadie sabe explicar. Los costes de nube corren por su propia cuenta de facturación en todo momento, de modo que usted tiene el control del coste desde el primer día.

Sí — la mayoría de los proyectos son colaborativos, no de relevo. Trabajamos dentro de su GitLab/GitHub, enviamos Terraform mediante merge request con su revisión, hacemos pairing con sus ingenieros en la landing zone para que el conocimiento se transfiera sobre la marcha y documentamos cada decisión en un registro de decisiones de arquitectura. El traspaso incluye runbooks, el repositorio de Terraform que usted ya posee y un recorrido por la estructura del Cloud Foundation Toolkit. Los equipos que quieren operar GCP por su cuenta después conservan todo lo que necesitan; los que quieren SRE continuo pueden contratarnos por oleada. En ambos casos no hay dependencia de nosotros para operar lo que construimos.

Ninguna. La organización de GCP, los proyectos y la cuenta de facturación son suyos y viven bajo su Cloud Identity desde el principio — operamos con acceso concedido y limitado en el tiempo mediante Privileged Access Manager, no como propietarios. Toda la infraestructura es Terraform en su repositorio, todos los pipelines en su CI y toda la documentación en su wiki. El contrato incluye una cláusula explícita contra la dependencia del proveedor: puede revocar nuestro acceso y continuar con cualquier otro equipo o internamente sin reconstruir nada. Evitamos deliberadamente herramientas propietarias o scripts a medida que solo nosotros podamos mantener.

Los ingenieros de entrega tienen certificaciones Google Cloud Professional en los itinerarios pertinentes — Cloud Architect, Data Engineer, DevOps Engineer y Security Engineer — y el equipo trabaja con el Google Cloud Architecture Framework y el Security Foundations Blueprint como estándar. Construimos sobre los patrones de referencia del propio Google (Cloud Foundation Toolkit, Terraform Example Foundation) en lugar de equivalentes propios y, para cargas reguladas, nos alineamos con el centro de buenas prácticas de seguridad de Google Cloud y revisamos cada trimestre. Además del rigor específico de GCP, trabajamos con controles internos preparados para ISO 27001 y SOC 2 Type II (en curso), tratamiento alineado con el RGPD con cláusulas contractuales tipo y entrega apta para HIPAA para datos de salud.

La recuperación ante desastres se diseña según su RTO/RPO, no según una plantilla. Opciones que diseñamos: multizona por defecto para alta disponibilidad dentro de una región, failover regional para datos con estado (réplicas entre regiones de Cloud SQL, AlloyDB, Spanner multirregión para RPO cero) y copia de seguridad entre regiones con Backup and DR Service. Durabilidad de objetos mediante buckets de Cloud Storage de doble región o multirregión, replicación de datasets de BigQuery donde la analítica deba sobrevivir a la pérdida de una región e infraestructura totalmente recreable desde Terraform, de modo que reconstruir una región sea ejecutar un pipeline y no una carrera manual. Documentamos el runbook, definimos el desencadenante del failover y, donde el presupuesto lo justifica, hacemos un game-day para demostrar que la cifra de RTO es real y no aspiracional.