Por qué las opciones de cómputo en GCP parecen abrumadoras
Cuando un ingeniero se acerca a Google Cloud por primera vez, la pregunta que lo detiene casi siempre es la misma: ¿qué servicio de cómputo debo usar? Compute Engine, GKE, GKE Autopilot, App Engine Standard, App Engine Flexible, Cloud Run, Cloud Functions — siete opciones distintas antes de haber escrito una sola línea de código de infraestructura. Los nombres se confunden y los límites parecen arbitrarios, pero dos ejes clarifican todo el panorama de inmediato.
El primer eje es el nivel de control: ¿necesitas gestionar el sistema operativo directamente, o prefieres subir código y dejar que Google se encargue del resto? El segundo eje es la unidad de ejecución: ¿estás levantando una máquina virtual completa, ejecutando un contenedor, o invocando una función única?
| Nivel de control | VM | Contenedor | Función | |---|---|---|---| | Alto (autogestión) | Compute Engine | GKE Standard | — | | Medio (gestionado) | — | GKE Autopilot / App Engine Flex | — | | Bajo (serverless) | — | Cloud Run / App Engine Standard | Cloud Functions |
Memoriza esta tabla y el resto se convierte en rellenar los detalles de cada servicio. Más del 80% de las preguntas del examen sobre este tema se derivan únicamente de estos dos ejes.
---
Compute Engine: el poder completo de IaaS
Compute Engine es la oferta IaaS fundamental de GCP. Tienes control total sobre una máquina virtual: selección de sistema operativo, fijación de versión de JVM, ajuste de parámetros del kernel, instalación de bibliotecas personalizadas, configuración de puertos — todo lo que puedes hacer en un servidor físico on-premises está disponible aquí.
Dos señales en una pregunta del examen apuntan directamente a Compute Engine como respuesta. La primera es un requisito de Lift-and-Shift: migrar sin modificar el código. Si una aplicación Java legada tiene dependencias fuertes con flags específicos de JVM (-Xms, -Xmx) y versiones de bibliotecas propietarias, App Engine y Cloud Run imponen entornos de ejecución con sandbox que hacen la migración imposible. Compute Engine es el único camino viable. La segunda señal es aislamiento físico: un requisito de Sole-tenant Nodes para mantener las cargas de trabajo fuera de hardware compartido.
Estrategia de selección de tipo de máquina
| Familia de máquina | Series de ejemplo | Casos de uso principales | |---|---|---| | Propósito general | N2, E2, N1 | Servidores web, entornos de desarrollo, bases de datos medianas | | Optimizada para cómputo | C2, C2D | Computación de alto rendimiento, servidores de juegos, simulaciones científicas | | Optimizada para memoria | M2, M3 | SAP HANA, grandes bases de datos en memoria | | Optimizada para acelerador | A2, G2 | Entrenamiento de ML, inferencia GPU, renderizado | | Optimizada para almacenamiento | Z3 | SSD local de alto rendimiento, Spanner, etc. |
Custom Machine Type es la opción correcta cuando ningún tipo predefinido coincide con tu combinación exacta de recursos. E2 escala en incrementos de 1 vCPU; N1 y N2 en incrementos de 2. La memoria se ajusta en pasos de 256 MB. Si necesitas más memoria por vCPU de lo que permite el límite predeterminado, agrega la opción Extended Memory.
Spot VM: la palanca de reducción de costos
Spot VM ofrece hasta un 91% de ahorro en comparación con los precios bajo demanda, con una contrapartida: Google puede recuperar la instancia con 30 segundos de aviso. Esto hace que Spot VM sea ideal para cargas de trabajo que admiten reinicios basados en puntos de control — procesamiento por lotes, entrenamiento de ML, pipelines de renderizado. Los Committed Use Discounts (compromisos de 1 o 3 años, 20–57% de descuento) funcionan mejor para cargas de trabajo siempre activas y son ineficientes para trabajos por lotes intermitentes.
Managed Instance Groups y autoescalado
Un Managed Instance Group (MIG) agrupa múltiples VMs construidas a partir de la misma plantilla de instancia y escala el recuento automáticamente según la utilización de CPU o el backlog de suscripción de Cloud Pub/Sub. Cuando los volúmenes de solicitudes se disparan a cientos de miles, el patrón recomendado es que Pub/Sub absorba mensajes de forma duradera (retenidos hasta 7 días, nunca eliminados antes del ACK) mientras el MIG escala el recuento de VMs contra la métrica de backlog. Esto desacopla la ingesta del procesamiento y evita la pérdida de mensajes bajo picos de carga.
---
Google Kubernetes Engine: el estándar para orquestación de contenedores
GKE ofrece clústeres de Kubernetes gestionados en GCP. Es la opción más potente para ejecutar cargas de trabajo en contenedores a escala, y lleva consigo una complejidad operativa proporcionalmente mayor.
Si tu aplicación ya está en contenedores o sigue una arquitectura de microservicios, GKE merece estar en la conversación. Si estás migrando una aplicación monolítica sin refactorizar, Compute Engine evita por completo la sobrecarga de la contenedorización.
GKE Standard es la elección correcta cuando necesitas control directo sobre los node pools, DaemonSets, políticas de red personalizadas u otras primitivas avanzadas de Kubernetes. GKE Autopilot elimina la gestión de nodos de tus responsabilidades: declaras los requisitos de recursos a nivel de Pod y Google se encarga del aprovisionamiento, el escalado y las actualizaciones. La facturación pasa de horas de VM de nodo a solicitudes reales de recursos de Pod, por lo que dejas de pagar por capacidad de nodo ociosa.
Una limitación importante de GKE: el Horizontal Pod Autoscaler (HPA) mantiene un mínimo de un Pod en todo momento. Incluso con tráfico cero, incurres en costos. Si se requiere un verdadero scale-to-zero, Cloud Run es la respuesta.
---
App Engine y Cloud Run: dos caminos hacia los contenedores serverless
Tanto App Engine como Cloud Run son servicios PaaS serverless. Los desarrolladores suministran código (App Engine) o una imagen de contenedor (Cloud Run) y se saltan por completo el parcheo del sistema operativo, la planificación de capacidad y el aprovisionamiento de servidores. La diferencia en la filosofía de diseño es lo que impulsa la decisión de selección.
App Engine Standard vs App Engine Flexible
| Dimensión | App Engine Standard | App Engine Flexible | |---|---|---| | Runtime | Runtimes limitados (Python, Java, Node.js, Go, PHP, Ruby) | Contenedor Docker personalizado | | Scale-to-zero | Soportado (cero instancias cuando está inactivo) | No soportado (mínimo 1 instancia) | | Cold start | Sí | No (siempre activo) | | Facturación | Horas de instancia (gratis cuando está inactivo) | Horas de VM (mínimo 1 minuto) | | Restricciones de red | Algunas limitaciones | Sin restricciones | | Mejor para | Tráfico intermitente, runtimes estándar | Binarios personalizados, servicios siempre activos |
La ventaja clave de App Engine Standard es el scale-to-zero: cuando no hay tráfico, el costo cae a cero. La restricción es el sandbox — los flags de JVM personalizados y las bibliotecas nativas propietarias generalmente no están soportadas.
Cloud Run: características fundamentales
Cloud Run aparece con más frecuencia que cualquier otro servicio como respuesta correcta en el examen. Sus características definitorias son tres: scale-to-zero, facturación basada en solicitudes con granularidad de milisegundos, y portabilidad de contenedores. Es la opción óptima para cargas de trabajo con variabilidad de tráfico extrema — imagina un sitio de venta de boletos que pasa de inactivo a millones de solicitudes en minutos tras el anuncio de un evento. Si las arrancadas en frío son una preocupación, configura min-instances para mantener un pool caliente disponible. Al elegir entre Cloud Run y App Engine Standard, el separador más claro es el artefacto: ¿estás desplegando una imagen de contenedor o código fuente directamente?
---
Cloud Functions: ejecución basada en eventos con granularidad de función
Cloud Functions es la oferta FaaS de GCP. Despliegas funciones individuales que se ejecutan únicamente en respuesta a eventos. Pagas según el recuento de invocaciones y la duración de ejecución, sin cargo por tiempo inactivo.
Palabras clave que hacen de Cloud Functions la respuesta correcta: sin gestión de servidores, precio de pago por uso con costo cero en inactividad, tráfico esporádico, tareas que se completan en segundos, disparadores de eventos HTTP/Pub/Sub/Cloud Storage.
Un ejemplo práctico: los datos de pedidos de socios llegan en ráfagas a ciertas horas del día, y cada registro requiere solo una transformación rápida antes de ser enviado al siguiente paso. Cloud Functions maneja este patrón limpiamente. App Engine Standard también admite scale-to-zero, pero para el manejo de eventos de una sola función, Cloud Functions ofrece una facturación más granular y una menor superficie operativa.
Los límites de tiempo de ejecución importan. Las Cloud Functions de primera generación tienen un máximo de 9 minutos; la segunda generación admite hasta 60 minutos. Para procesos de larga ejecución o conexiones sostenidas a bases de datos on-premises, Cloud Functions no es el ajuste correcto. Comparte el estado entre funciones usando almacenes externos como Cloud Firestore o Cloud Memorystore — nunca confíes en el estado en memoria entre invocaciones.
---
Comparación de todas las opciones en una sola tabla
La tabla a continuación consolida el modelo de facturación, el soporte de scale-to-zero, la carga operativa y el ajuste de carga de trabajo para cada servicio.
| Servicio | Base de facturación | Scale-to-zero | Carga operativa | Cargas de trabajo ideales | |---|---|---|---|---| | Compute Engine | Horas de instancia | No | Alta | Lift-and-Shift, apps legadas, runtimes personalizados | | GKE Standard | Horas de VM de nodo | No | Alta | Control avanzado de K8s, microservicios | | GKE Autopilot | Solicitudes de recursos de Pod | No | Baja | Contenedores sin gestión de nodos K8s | | App Engine Standa