GCP vs Azure para DevOps: comparativa real con criterios tecnicos
Si trabajas en DevOps tarde o temprano te toca decidir, o al menos opinar, entre Google Cloud y Azure. No hay una nube mejor en abstracto: depende de tu equipo, de lo que ya usa tu empresa y de que tipo de carga vas a desplegar. En este post comparo ambas con criterios tecnicos que importan en el dia a dia de un equipo de plataforma. Hablo desde la experiencia de trabajar con GKE Autopilot en GCP y con Azure en entornos enterprise. Para los precios concretos consulta siempre las calculadoras oficiales, porque cambian con frecuencia y dependen de region y de compromiso de uso.
Resumen rapido: GCP vs Azure
| Criterio | Google Cloud (GCP) | Microsoft Azure |
|---|---|---|
| Kubernetes gestionado | GKE, con modo Autopilot muy maduro | AKS, integrado con el ecosistema Microsoft |
| Identidad | Cloud IAM y Workload Identity | Microsoft Entra ID, muy fuerte en empresa |
| CI/CD nativo | Cloud Build y Cloud Deploy | Azure DevOps Pipelines |
| Contenedores sin servidor | Cloud Run | Container Apps |
| IaC nativo | Sin herramienta propia dominante, se usa Terraform o Pulumi | Bicep y ARM, ademas de Terraform |
| Registro de imagenes | Artifact Registry | Azure Container Registry |
| Gestion de secretos | Secret Manager | Key Vault |
| Perfil tipico de cliente | Startups tecnicas, cargas cloud native | Gran empresa, banca, seguros, sector publico |
Kubernetes gestionado: GKE vs AKS
Si Kubernetes es el centro de tu plataforma, este es el criterio que mas pesa. GKE es el servicio gestionado con mas recorrido y su modo Autopilot elimina la gestion de nodos: defines pods con sus requests de recursos y Google se encarga del resto. AKS es una opcion solida y se integra muy bien con Entra ID, Azure Monitor y Azure DevOps, lo que lo hace natural si tu empresa ya vive en Microsoft.
# Crear un cluster GKE Autopilot
gcloud container clusters create-auto mi-cluster \
--region europe-west1
# Crear un cluster AKS
az aks create \
--resource-group mi-rg \
--name mi-cluster \
--node-count 3 \
--generate-ssh-keys
Una diferencia practica: con Autopilot pagas por los recursos que piden tus pods, asi que definir bien los requests y limits es doblemente importante. Si no lo tienes claro, repasa el post de OOMKilled en Kubernetes.
Identidad y acceso desde los pipelines
Las dos nubes permiten autenticar un pipeline sin guardar credenciales de larga duracion, usando OIDC y federacion de identidad. En GCP se configura con Workload Identity Federation y en Azure con federated credentials sobre una App Registration. En ambos casos el pipeline obtiene un token temporal en cada ejecucion. Es la practica recomendada frente a guardar un fichero de clave de servicio o un client secret en los secretos del repositorio. Tienes el contexto de CI/CD en el post de GitHub Actions vs GitLab CI.
CI/CD: Azure DevOps frente a Cloud Build
Azure DevOps ofrece repositorios, boards, pipelines y artefactos en una sola plataforma, con un sistema de environments y aprobaciones muy completo. Es la razon por la que muchas empresas se quedan en Azure. Cloud Build es mas sencillo y encaja bien con cargas en GCP, pero mucha gente usa GitHub Actions o GitLab CI con cualquiera de las dos nubes y deja el CI/CD fuera del proveedor. Si te interesa la parte de Microsoft, tienes la guia de pipelines en Azure DevOps.
Contenedores sin servidor: Cloud Run frente a Container Apps
Si tu carga no necesita Kubernetes, ambas nubes tienen una opcion para desplegar un contenedor y olvidarte de la infraestructura. Cloud Run es muy directo: le das una imagen y te devuelve una URL con escalado automatico, incluido el escalado a cero. Azure Container Apps ofrece un modelo parecido con funciones extra como Dapr y KEDA integrados. Para ver como encaja Cloud Run en una decision de costes, tienes el post de Cloud Run vs Compute Engine.
Infraestructura como codigo en cada nube
Azure tiene su propio lenguaje declarativo, Bicep, que compila a ARM y cubre los recursos de la plataforma desde el primer dia. GCP no tiene una herramienta propia equivalente con tanto peso, asi que la practica habitual es Terraform o Pulumi. Si trabajas en las dos nubes, usar Terraform en ambas te da un unico flujo de trabajo. En el post de Ansible vs Terraform explico cuando encaja cada herramienta.
# Terraform: el mismo flujo en las dos nubes
terraform init
terraform plan
terraform apply
# Solo cambia el provider:
# provider google { project = mi-proyecto region = europe-west1 }
# provider azurerm { features {} }
Costes: como compararlos con criterio
Comparar precios entre nubes con una tabla fija suele inducir a error, porque el coste real depende de la region, del tipo de instancia, de los descuentos por uso comprometido y del trafico de salida. Estas son las preguntas que si conviene hacerse:
- Que descuentos aplican a tu empresa: acuerdos enterprise, licencias que ya pagas o creditos.
- Si tu carga es estable o con picos: el escalado a cero favorece los modelos serverless.
- Cuanto trafico de salida generas: suele ser una partida que sorprende.
- Si ya tienes licencias de Windows Server o SQL Server: en Azure pueden reducir el coste mediante sus ventajas de licencias.
Usa la calculadora oficial de cada proveedor con tu carga real antes de decidir.
Cuando elegir cada una
| Situacion | Mejor encaje |
|---|---|
| Tu empresa ya usa Microsoft 365 y Entra ID | Azure |
| Cargas cloud native centradas en Kubernetes | GCP, por la madurez de GKE y Autopilot |
| Quieres desplegar contenedores sin gestionar nada | GCP con Cloud Run, o Azure con Container Apps |
| Requisitos fuertes de gobierno y cumplimiento corporativo | Azure, por su integracion con la identidad corporativa |
| Tu equipo ya sabe una de las dos | La que conoce, el coste de aprender pesa mas que la diferencia tecnica |
Conclusion
Para un equipo DevOps la diferencia tecnica entre GCP y Azure es menor de lo que parece. Lo que mas pesa en la practica es el ecosistema que ya tienes, la identidad corporativa y lo que sabe tu equipo. Si estas empezando, aprende bien una nube y despues traslada los conceptos a la otra: Kubernetes, IaC y pipelines con OIDC funcionan igual en ambas. Si aun no tienes claro por donde empezar, mira la hoja de ruta de sysadmin a DevOps.
Con cual de las dos trabajas tu y por que? Cuentamelo en los comentarios.
