Compute, Containers and Serverless in Google Cloud

Resumen

Todo el cómputo en la nube resuelve la misma pregunta —dónde y cómo se ejecuta el código que procesa una transacción—, pero lo resuelve con contratos operativos muy distintos. En un extremo está la máquina virtual, que entrega control total del sistema operativo a cambio de que alguien lo parchee, lo monitoree y lo escale; en el otro está el serverless, donde la plataforma ejecuta el código y cobra por la invocación, y el equipo renuncia casi por completo a la gestión de servidores a cambio de un modelo operativo más estrecho. Entre ambos está el contenedor con orquestación, que reparte la responsabilidad: la plataforma gestiona la distribución, el escalado y el balanceo, mientras el equipo gestiona la imagen, la configuración y la aplicación.

Este tema recorre esas tres modalidades con el criterio que la certificación espera: saber qué es una máquina virtual, qué es la containerization y qué problema resuelve, qué son los microservicios, qué significa serverless, qué son las Spot VMs (preemptible VMs) y por qué existen, qué aporta Kubernetes como orquestador, y cómo funcionan el autoscaling y el load balancing que convierten una arquitectura cloud en elástica. Sobre esa base se estudian los beneficios del cómputo en la nube y, sobre todo, las elecciones y restricciones entre opciones: cada plataforma tiene un límite de tiempo de ejecución, un modelo de escalado, un grado de control y un perfil de coste, y elegir mal se paga con reescrituras.

También se trata el caso que el examen plantea con frecuencia: una aplicación legacy especializada —dependiente de un sistema operativo concreto, de un middleware propietario o de licencias atadas a la máquina— para la que la respuesta correcta sigue siendo rehost sobre Compute Engine, sin pretender que la plataforma sustituya un rediseño que nadie ha presupuestado.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Definir qué es una máquina virtual y describir el valor de negocio de Compute Engine como plataforma de cómputo bajo demanda.
Explicar qué es la containerization, en qué se diferencia un contenedor de una máquina virtual y qué aporta en portabilidad y densidad.
Definir microservicios y señalar tanto su beneficio de despliegue independiente como su coste operativo.
Explicar qué es serverless y cómo se diferencia de un modelo de servidores gestionados.
Describir las Spot VMs (preemptible VMs) y justificar su uso con criterios de interrupción y de tipo de carga.
Explicar qué es Kubernetes, qué problemas de orquestación resuelve y qué añade Google Kubernetes Engine (GKE).
Describir cómo el autoscaling y el load balancing sostienen la elasticidad de una arquitectura en la nube.
Comparar las opciones de cómputo de Google Cloud por grado de control, operación, escalado y perfil de carga.
Señalar las restricciones de cada opción (tiempo de ejecución, estado, hardware especializado, conocimiento requerido).
Justificar el rehost de una aplicación legacy especializada sobre Compute Engine como decisión correcta y no como fracaso de modernización.

Contenido Principal

Subtema 1: Máquinas virtuales y el valor de Compute Engine

Una máquina virtual (VM) es una instancia de servidor creada por software sobre un hypervisor, con su propio sistema operativo, su memoria y su disco dedicados en el host. En la nube, la VM es el nivel más bajo de servicio (IaaS): el proveedor entrega cómputo, red y almacenamiento, y el cliente es responsable del sistema operativo, del parcheo, de la configuración de la aplicación y del escalado. La ventaja es control total; la contrapartida es que todo lo que la plataforma puede automatizar sigue siendo responsabilidad del cliente.

Compute Engine es el servicio de máquinas virtuales de Google Cloud. Su valor de negocio no está en el precio de la hora —que es una parte del argumento, no el argumento—, sino en cuatro capacidades: aprovisionamiento en minutos en lugar de ciclos de compra, una gama de familias de máquinas ajustada a perfiles distintos (general purpose, optimizadas para memoria o para cómputo, con soporte de GPU), integración con el resto de la plataforma (red privada, balanceo, discos, imágenes) y el pago por el tiempo que la instancia está encendida, combinado con descuentos de uso sostenido y con opciones de compromiso a cambio de menor precio.

Sobre Compute Engine descansan los patrones operativos que la modernización usa cuando la aplicación todavía no es contenedor. Los grupos de instancias gestionadas mantienen un número definido de réplicas de una plantilla y las recrean cuando un host falla; el autoscaling de grupo ajusta ese número según una métrica; el balanceo de carga reparte el tráfico entre las réplicas con health checks. Es decir, la VM también puede ser elástica, aunque esa elasticidad se gestione en la capa de instancias en lugar de en la de contenedores.

El caso que conviene retener para el examen: una aplicación legacy especializada —un sistema de diseño asistido, un middleware propietario, un motor con licencia ligada al sistema operativo, una carga que depende de un dispositivo o de un kernel concreto— no se beneficia de contenedores ni de serverless, porque su problema no es la operación sino su dependencia del entorno. Rehost sobre Compute Engine es la ruta correcta: se gana la resiliencia de la plataforma y la salida del datacenter, y se conserva un entorno compatible. Presentar esa decisión como un "falta de modernización" es no entender el criterio de compatibilidad.

Atributo	Qué ofrece Compute Engine	Qué queda en el cliente
Control	Máquina completa, elección de SO y de arranque	Parcheo, configuración, endurecimiento
Escalado	Grupos gestionados con autoscaling	Definición de la métrica y del tamaño correcto
Coste	Pago por uso, descuento por uso sostenido, Spot VMs	Dimensionado y apagado de capacidad ociosa
Resiliencia	Zonas, imágenes, discos persistentes	Réplicas, backups y plan de recuperación
Integración	Red, balanceo, discos, IAM	Arquitectura de red y de seguridad de la carga

Los beneficios del cómputo en la nube, que son el argumento de negocio que sostiene toda la elección de plataforma, se concentran en seis resultados verificables. Provisionamiento en minutos: capacidad nueva disponible antes de la siguiente reunión de negocio, sin ciclo de compra. Elasticidad: la capacidad sigue a la demanda mediante autoscaling, y el pico de campaña deja de ser una decisión de compra permanente. Coste variable: el gasto se alinea con el uso, y el mes de baja actividad cuesta menos que el de actividad alta. Economía de escala del proveedor: el hardware, la red y la energía se gestionan a una escala que ninguna empresa media replica. Integración: el cómputo nace conectado a discos, balanceo, redes privadas e identidad, lo que elimina la infraestructura auxiliar que hay que construir en el datacenter. Innovación gestionada: nuevas familias de máquinas, soporte de aceleradores y mejoras de red aparecen como opciones del catálogo y no como proyectos de infraestructura.

La distinción de niveles de servicio también conviene fijarla con precisión, porque condiciona la conversación con el negocio. Infrastructure as a Service entrega recursos crudos —máquina, red, disco—; Platform as a Service entrega un entorno de ejecución gestionado donde el cliente publica código o imágenes; Function as a Service entrega la ejecución de una unidad de lógica vinculada a un evento. Cada nivel elimina una capa de operación y a cambio acota las opciones; un Digital Leader debe poder indicar en qué nivel está cada recomendación para que el negocio entienda qué control cede y qué coste deja de pagar.

Subtema 2: Containerization, contenedores y microservicios

La containerization es la técnica de empaquetar una aplicación con sus dependencias —bibliotecas, runtimes, configuración de arranque— en una imagen inmutable que se ejecuta de la misma forma en el portátil del desarrollador, en el entorno de pruebas y en producción. Un contenedor es la instancia en ejecución de esa imagen. La diferencia clave con una máquina virtual es la compartición: mientras cada VM incluye su propio sistema operativo invitado, los contenedores comparten el kernel del sistema anfitrión y aíslan solo los recursos de proceso, red y ficheros, con mecanismos del propio kernel.

Las consecuencias de esa diferencia son las que interesan al negocio. Densidad: al no cargar un sistema operativo por cada unidad de trabajo, se ejecutan más instancias por host y se reduce el coste por proceso. Portabilidad: la misma imagen corre en cualquier entorno que exponga un runtime de contenedores, lo que elimina la clase de incidentes causada por diferencias entre el entorno de desarrollo y el de producción. Consistencia de despliegue: el artefacto que se promueve es el mismo, y la promoción se convierte en una operación de copia, no de reconstrucción. Ciclo de vida rápido: crear y destruir un contenedor es una operación de segundos, lo que habilita despliegues frecuentes y entornos efímeros.

Los microservicios son un estilo arquitectónico en el que la aplicación se compone de servicios pequeños, con responsabilidad acotada, que se despliegan de forma independiente y se comunican por red, habitualmente por API. Su beneficio de negocio es la independencia de release: un equipo puede desplegar su servicio sin coordinar ventana con el resto, y el escalado puede aplicarse al componente que de verdad recibe la carga. Su coste es la complejidad distribuida: fallos de red en lugar de fallos de llamada, transacciones que cruzan varios servicios, observabilidad más difícil y un modelo de datos que deja de ser único. Por eso los microservicios no son un objetivo en sí mismos: son la respuesta correcta cuando el tamaño del equipo y la frecuencia de cambio justifican el coste operativo de la distribución.

La distinción que aparece en el examen es de intención: un contenedor no es un microservicio. Puede empaquetarse un monolito en un contenedor y obtener densidad y portabilidad sin ganar ninguna independencia de despliegue; puede construirse un sistema de microservicios desplegados como procesos de máquina virtual y seguir teniendo la agilidad de release, con más coste de operación. La containerization es una técnica de empaquetado; los microservicios, un diseño de aplicación; y la combinación de ambas es lo que hace que la nube se pueda aprovechar al máximo.

El empaquetado también desplaza parte de la responsabilidad hacia la cadena de suministro de imágenes. La imagen se construye una vez, se firma, se almacena en un registro gestionado —Artifact Registry en Google Cloud— y se promueve por entornos sin reconstruirse; las vulnerabilidades se detectan sobre esa imagen y no sobre servidores individuales, y la auditoría de qué se ejecuta en producción se resuelve consultando el registro y el despliegue, no recorriendo máquinas. Para el negocio, esa disciplina reduce el tiempo entre la publicación de un parche de seguridad y su presencia real en producción, que es una de las métricas de riesgo que los comités empiezan a pedir.

Subtema 3: Kubernetes, Google Kubernetes Engine y la capa de orquestación

Kubernetes es un sistema de código abierto para orquestar contenedores: declara el estado deseado —número de réplicas, imagen, recursos, puertos, políticas— y la plataforma se encarga de alcanzarlo y de mantenerlo, incluso cuando un nodo falla o una imagen se actualiza. Sus conceptos operativos básicos son el clúster (el conjunto de nodos gestionados), el nodo (la máquina que ejecuta los contenedores), el pod (la unidad de despliegue, normalmente un contenedor con su red y sus volúmenes), y los objetos declarados —deployments, services, ingresses— que describen cómo se publica y se expone la carga.

Google Kubernetes Engine (GKE) es el servicio gestionado de Kubernetes de Google Cloud. El valor de negocio no está en crear el clúster —que es rápido—, sino en que el control plane, las actualizaciones de versión, los parches de nodo, la integración con la red y con IAM, y la integración con el balanceo de carga son operación de Google. Un equipo de aplicación puede concentrarse en los manifiestos y en la imagen, y delegar la salud del plano de control. GKE multiplica ese valor con capacidades gestionadas: node pools separados por tipo de carga, actualizaciones de versión sin ventana manual, Binary Authorization, y el modelo de flotas (fleets) que permite administrar varios clústeres desde una sola configuración, base técnica de los escenarios híbridos y multicloud.

El autoscaling en este mundo tiene tres planos que conviene distinguir. El cluster autoscaler añade o retira nodos según la cola de pods que no caben; el horizontal pod autoscaler ajusta el número de réplicas de un servicio según una métrica como la utilización de CPU o la tasa de peticiones; y el escalado a cero —disponible sobre plataformas construidas sobre Kubernetes como Cloud Run— apaga las réplicas cuando no hay tráfico. Para el negocio, la diferencia es la granularidad: escalar infraestructura (nodos) es lento y grueso; escalar réplicas de un servicio es rápido y fino; y escalar a cero es la forma de que un servicio con tráfico esporádico no cueste dinero en los periodos muertos.

El load balancing completa el cuadro. Un servicio de Kubernetes tipo LoadBalancer expone un punto único de entrada y reparte el tráfico entre los pods listos; el ingress gestiona reglas por host y por ruta; y el balanceo nativo de contenedores de Google Cloud, integrado con GKE, enruta directamente al pod de destino sin una capa intermedia de reenvío, con health checks basados en la aplicación. Para un Digital Leader, el argumento de negocio es que el tráfico deja de depender de una máquina concreta: la réplica que falla sale del balanceo y la plataforma la recrea, y el usuario no percibe el evento.

Otro valor de GKE que se traduce en coste operativo es la gestión del ciclo de vida. Las actualizaciones automáticas de versión del plano de control y las actualizaciones de nodo gestionadas sustituyen a ventanas de mantenimiento manuales, y la separación en node pools permite aislar cargas sensibles del ritmo de actualización del resto. La gobernanza se apoya en políticas de red, de cuotas y de acceso por identidad, de modo que un equipo puede crear entornos de prueba sin convertirse en administrador de la plataforma. Sin esa capa de gobierno, la adopción de Kubernetes en varios equipos produce lo contrario del objetivo: cada equipo con su clúster, sus políticas y su forma de desplegar, que es el shadow IT de la orquestación.

La observabilidad es el tercer pilar operativo que distingue una adopción madura de una improvisada. Los clústeres y las instancias generan métricas, logs y trazas desde el primer despliegue; el trabajo del equipo es definir qué se vigila —latencia del servicio, tasa de error, saturación de CPU, cola de trabajos pendientes— y qué umbral dispara una alerta que alguien pueda atender. Sin ese trabajo, la plataforma elástica funciona bien y nadie se entera de que el usuario está sufriendo: los fallos de una arquitectura distribuida se manifiestan como lentitud acumulada, no como una máquina apagada, y ese tipo de fallo solo se detecta con métricas de la aplicación, no con indicadores de host.

Ejemplo Práctico

Para comparar opciones de cómputo con datos y no con folletos, el primer paso es ver qué perfiles de máquina existen en la región elegida:

gcloud compute machine-types list --filter="zone:us-central1-a" \
  --format="table(name, guestCpus, memoryMb)"

La tabla permite dimensionar una VM rehost contra la carga real: si el servidor de origen tenía 8 vCPU y 32 GB, la fila equivalente define el coste de la línea base de la migración sin sobreaprovisionar por costumbre.

Cuando la carga es un lote de trabajo tolerante a interrupciones, el ahorro se consigue con Spot VMs (la evolución de las preemptible VMs):

gcloud compute instances create batch-worker-01 \
  --zone=us-central1-a \
  --machine-type=e2-standard-4 \
  --provisioning-model=SPOT \
  --maintenance-policy=TERMINATE \
  --image-family=debian-12 \
  --image-project=debian-cloud

La bandera --provisioning-model=SPOT marca la instancia como Spot; --maintenance-policy=TERMINATE indica que la instancia se puede interrumpir cuando Google necesita la capacidad, condición que hace posible el descuento. La lectura de negocio es que este ahorro solo se puede aplicar a cargas que se pueden reiniciar sin pérdida —procesamiento por lotes, transformaciones, pruebas—; aplicarlo a una base de datos transaccional convertiría un ahorro en un incidente.

Para ver el cómputo ya desplegado en los dos modelos, contenedores y VMs:

gcloud container clusters list \
  --format="table(name, location, status, currentNodeCount)"
gcloud compute instances list --filter="scheduling.automaticRestart=true" \
  --format="table(name, machineType, zone, status)"

Un clúster con nodos activos indica capacidad de orquestación ya contratada y un equipo que debe saber operarla; una lista larga de VMs sin grupos gestionados señala la oportunidad de introducir plantillas y autoscaling antes de plantearse el paso a contenedores. La lectura conjunta de ambos inventarios es la que permite presentar un plan de cómputo por fases en lugar de una discusión ideológica entre VM y contenedor.

Temas relacionados: Cloud modernization y estrategias de migración, Desarrollo serverless con Cloud Run y Cloud Functions, Hybrid y multicloud con Anthos.

Subtema 4: Serverless y gestión de capacidad: Spot VMs y autoscaling

Serverless es el modelo en el que la plataforma ejecuta el código sin que el cliente administre servidores: no hay nodos que parchear, no hay clústeres que actualizar y el escalado —incluido el escalado a cero— es un atributo del servicio. El coste se reconoce por el tiempo de cómputo realmente ejecutado, no por la hora en la que la instancia permanece encendida esperando tráfico. La renuncia a la operación de servidores no es gratuita: se aceptan límites de tiempo de ejecución, un modelo de entorno más estrecho y, en algunos patrones, latencia adicional en el primer arranque. Serverless no significa "sin operación": el equipo sigue responsable del código, de la configuración, de la seguridad del endpoint y del coste por invocación.

Las Spot VMs (preemptible VMs en su denominación anterior) son la contrapartida de bajo coste en el mundo de las máquinas virtuales. Una Spot VM usa capacidad sobrante de Google y puede ser interrumpida cuando esa capacidad hace falta, con un preaviso corto; a cambio, su precio es sustancialmente menor que el de una VM estándar. La restricción de uso es simple y tajante: solo cargas que toleran la interrupción. Un pipeline de procesamiento por lotes, una prueba automatizada, un entrenamiento de modelo reanudable o un servicio con caché regenerable son candidatos correctos; una base de datos, un servicio transaccional o un sistema con sesión en memoria no lo son. La regla de negocio es convertir el ahorro en una decisión consciente de arquitectura: si la carga no puede reiniciarse sin pérdida, no puede correr en Spot.

El autoscaling, por su parte, es lo que convierte la infraestructura en un recurso elástico. Funciona en los planos de infraestructura (añadir capacidad de host o de nodo), de servicio (añadir réplicas de la aplicación) y de evento (instancias efímeras que se crean al llegar un mensaje de una cola y desaparecen al procesarlo). Cada plano tiene una métrica distinta y una latencia de reacción distinta, y la combinación correcta depende del patrón de carga: una campaña de tráfico diario se responde con réplicas de servicio; un lote nocturno de mil tareas se responde con instancias efímeras; un crecimiento anual sostenido se responde con capacidad de nodo.

La medición del coste debe acompañar a cualquiera de estas decisiones. La nube permite atribuir el gasto de cómputo por proyecto, por etiqueta y por servicio, y la disciplina que conviene instalar desde la primera wave es que cada carga tenga etiqueta de propietario y de entorno antes de escalarla: sin esa cobertura, el autoscaling produce instancias que nadie puede justificar y el cierre mensual se convierte en una negociación. Para las cargas serverless, el modelo mental cambia: el coste se reconoce por tiempo de ejecución o por invocación, de modo que la optimización de la duración media de la función tiene un impacto directo y medible en la factura, a diferencia de las VMs, donde el ahorro casi siempre pasa por dimensionar o apagar.

En el serverless conviene anticipar también la latencia del arranque. Cuando un servicio escala a cero o crea una instancia nueva, la primera petición de ese periodo paga el tiempo de arranque del runtime y de la aplicación; ese tiempo es el que se conoce como arranque en frío y afecta sobre todo a las cargas con latencia exigente y tráfico muy disperso. Las respuestas de negocio habituales son mantener una instancia mínima para el servicio que no puede tolerar esa latencia, medir el impacto real antes de optimizarlo y recordar que en muchos casos el arranque en frío es preferible a pagar capacidad ociosa las veinticuatro horas.

Opción	Modelo operativo	Escalado típico	Carga para la que encaja	Restricción principal
Compute Engine	Cliente gestiona el SO	Grupos gestionados, autoscaling por métrica	Legacy especializado, estado, hardware propio	Operación completa del sistema
GKE	Plataforma gestiona el clúster	Pods y nodos, autoscaling multinivel	Microservicios, cargas portables	Exige habilidad de orquestación
Cloud Run	Servidor totalmente gestionado	Por peticiones, hasta cero	Servicios HTTP stateless	Límites de tiempo y de concurrencia
Cloud Functions	Funciones sin servidor	Por invocaciones y eventos	Reacción a eventos, lógica acotada	Duración limitada, ejecución acotada
App Engine	PaaS con entornos standard y flexible	Por versión y por métrica	Aplicaciones web con despliegue por versión	Menor control que IaaS

Subtema 5: Elecciones y restricciones entre opciones de cómputo

La pregunta "¿dónde corro esto?" no se responde con preferencias, sino con restricciones. Cinco restricciones descartan opciones de forma casi inmediata. Hardware o sistema operativo especializado: GPU con controlador concreto, licencia ligada al SO, dispositivo físico, kernel modificado; la respuesta es Compute Engine. Estado en memoria y sesiones: un contenedor o una función con estado local complica el escalado; la respuesta es externalizar el estado y usar una opción stateless, o aceptar una sola instancia. Tiempo de ejecución: una carga que necesita horas no encaja en límites de funciones serverless y requiere un servicio de larga duración o un trabajo por lotes. Frecuencia de tráfico: un servicio consultado unas pocas veces al día no justifica una VM encendida las 24 horas; serverless con escalado a cero alinea coste y uso. Habilidades del equipo: un equipo sin experiencia de orquestación que adopta GKE por moda multiplica la superficie de fallo; la adopción de Kubernetes debe acompañarse de capacitación y de una carga piloto de riesgo controlado.

Las restricciones también operan en el sentido inverso: hay opciones que parecen cómodas y resultan caras para el patrón de uso. Un monolito con picos marcados desplegado en una única VM de gran tamaño paga capacidad ociosa la mayor parte del mes; el mismo monolito, trasladado a un grupo de instancias con autoscaling, paga solo el pico. Una función serverless invocada millones de veces al día con duración media larga puede superar el coste de un servicio contenedorizado permanente, porque en el serverless se cobra por invocación y no por capacidad reservada. La disciplina correcta es modelar el coste con el perfil de tráfico real antes de elegir, y revisar el modelo después de un mes de operación.

El rehost de aplicaciones legacy especializadas entra en este marco como una elección con restricciones conocidas. Su justificación no es la comodidad del equipo, sino la incompatibilidad verificable con las alternativas. Su gestión correcta implica documentar el alcance del rehost, activar sobre la VM los controles que la plataforma ofrece —grupo de instancias, health checks, discos con política de retención, etiquetas para atribución— y dejar definida la condición que permitiría revisar la decisión más adelante: por ejemplo, que el proveedor del middleware lance una versión compatible con contenedores, o que el negocio acepte reemplazar la herramienta por una de mercado.

La lista de comprobación que conviene aplicar antes de elegir plataforma es corta y se puede resolver con evidencia del sistema de origen:

Versión y ciclo de soporte del sistema operativo exigido por la carga, y disponibilidad de una imagen base mantenida.
Duración real de las operaciones críticas, porque determina si caben en límites de funciones o requieren un servicio de larga duración.
Ubicación del estado —sesiones, caché, cola de trabajos—, que decide si la carga puede escalar horizontalmente.
Perfil de tráfico a lo largo del día y del año, con valores pico y valle medidos, no estimados.
Habilidades del equipo y capacidad de acompañamiento durante los primeros meses de operación.
Requisitos de red y de seguridad: exposición pública, comunicación con sistemas on-premises y aislamiento por carga.

La secuencia de adopción que funciona con más frecuencia es incremental: primero VMs con plantillas y grupos gestionadas para ganar reproducibilidad, después contenedores para cargas nuevas o rediseñadas, y solo al final la orquestación, cuando hay suficientes servicios como para que el coste de operar un clúster se reparta. Saltar directamente a GKE con dos o tres aplicaciones suele consumir la atención del equipo en la plataforma y no en el producto; quedarse indefinidamente en VMs consolidadas deja de ser una decisión técnica y se convierte en una renuncia a la agilidad que la nube prometía.

Ejemplo Práctico

La elección entre Spot VM y VM estándar se puede auditar sobre el entorno real. El siguiente bloque muestra las instancias con su modelo de aprovisionamiento y su política de mantenimiento:

gcloud compute instances list \
  --format="table(name, machineType, scheduling.provisioningModel, scheduling.maintenancePolicy)"

Un lote de trabajo transaccional con SPOT en la columna de modelo de aprovisionamiento es un hallazgo de riesgo, no un ahorro. Un grupo de workers de procesamiento con SPOT y política de terminación es la configuración correcta, y conviene acompañarla de una cola que reintente las tareas interrumpidas.

Cuando la decisión es entre VM y contenedor para una carga existente, la lectura del perfil de tráfico se puede apoyar en las métricas de instancias si ya hay autoscaling configurado:

gcloud compute instance-groups managed list \
  --format="table(name, baseInstanceName, targetSize, version.template.name)"
gcloud container node-pools list --cluster=CLUSTER --region=us-central1 \
  --format="table(name, config.machineType, autoscaling.minNodeCount, autoscaling.maxNodeCount)"

La columna targetSize frente a los límites de autoscaling permite ver si el grupo crece de verdad con la carga o si está congelado en un tamaño fijado manualmente —señal de que el autoscaling está declarado pero no operativo—. En el lado de Kubernetes, unos límites de nodo iguales al mínimo y al máximo de la capacidad existente significan que el cluster autoscaler no puede absorber picos: se está pagando por una plataforma elástica que está funcionando como infraestructura fija. Ambas lecturas se corrigen sin tocar el código, y son el tipo de hallazgo que un Digital Leader puede llevar a un comité el primer mes de una migración.

El valor de presentar estas lecturas en lugar de una recomendación genérica es que convierte la discusión de plataforma en una discusión de restricciones y de hechos: qué carga admite interrupción, cuál necesita estado, cuál puede escalar a cero y cuál exige hardware concreto. Ese es exactamente el tipo de razonamiento que el examen espera cuando presenta un escenario y pide la opción de cómputo más adecuada.

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Máquina virtual	Instancia de servidor con SO propio sobre hypervisor	Legacy especializado, estado, control total del entorno
Compute Engine	Servicio de VMs de Google Cloud	Rehost, cargas con restricciones, base de grupos con autoscaling
Containerization	Empaquetado de aplicación y dependencias en imagen inmutable	Para lograr portabilidad y consistencia entre entornos
Contenedor	Instancia en ejecución de una imagen de contenedor	Como unidad de despliegue, no como sinónimo de microservicio
Microservicios	Arquitectura de servicios pequeños, desplegados de forma independiente	Cuando el tamaño del equipo y la frecuencia de cambio lo justifican
Kubernetes	Orquestador de contenedores de código abierto	Para declarar estado deseado de cargas contenedorizadas
Google Kubernetes Engine (GKE)	Kubernetes gestionado por Google Cloud	Microservicios y cargas portables con operación delegada
Autoscaling	Ajuste automático de capacidad según métrica	En cargas con picos o crecimiento variable
Load balancing	Reparto de tráfico entre réplicas con health checks	Siempre que haya más de una réplica sirviendo
Serverless	Modelo sin administración de servidores, pago por ejecución	Servicios HTTP y reacciones a eventos con tráfico irregular
Spot VMs (preemptible VMs)	Capacidad con descuento, interrumpible	Lotes, pruebas y cargas reanudables sin pérdida
Escalado a cero	Apagado de réplicas cuando no hay tráfico	Servicios de baja o nula actividad por tramos del día
Estado deseado	Modelo declarativo en el que la plataforma mantiene el estado definido	En orquestación y en infraestructura como código
Registro de imágenes	Almacén gestionado de imágenes de contenedor	Para promoción auditada entre entornos y control de vulnerabilidades
Arranque en frío	Latencia de la primera petición tras escalar desde cero	Al dimensionar servicios con tráfico muy disperso
Nivel de servicio	Contrato de operación entre cliente y plataforma (IaaS, PaaS, FaaS)	Para explicar qué control se cede y qué coste se elimina

Comparaciones

Dimensión	Máquina virtual (Compute Engine)	Contenedor (GKE)	Serverless (Cloud Run / Cloud Functions)
Nivel de servicio	IaaS	PaaS de orquestación	FaaS o servicio gestionado
Responsabilidad del SO	Cliente	Imagen base del cliente, clúster gestionado	Proveedor
Unidad de despliegue	Imagen de disco	Imagen de contenedor	Imagen o función
Escalado	Por grupo de instancias	Por pods y nodos	Automático, incluido a cero
Coste cuando no hay tráfico	Se paga la instancia encendida	Se paga la capacidad del clúster	Casi nulo, por ejecución
Control del entorno	Total	Alto dentro del pod	Limitado por la plataforma
Requisito de habilidad	Operación de sistemas	Orquestación y red	Configuración y código
Ciclo de vida del SO	Cliente, con ventana de parcheo	Cliente sobre imagen base, clúster gestionado	Proveedor
Adecuado para legacy especializado	Sí, es el caso de uso natural	Solo si el software admite imagen estándar	No, por límites de entorno y de ejecución
Aceleradores y hardware propio	Disponible por máquina y por familia	Disponible, con restricciones de programación	Limitado o no disponible

Dimensión	VM estándar	Spot VM (preemptible)	Carga servida por serverless
Continuidad	Alta, con política de reinicio	Interrumpible con preaviso	Depende del servicio y de la plataforma
Perfil de coste	Por hora de uso	Con descuento por capacidad sobrante	Por tiempo o invocación ejecutada
Carga adecuada	Transaccional, estado, larga duración	Lotes, pruebas, procesos reanudables	HTTP y eventos con tráfico irregular
Riesgo principal	Capacidad ociosa	Pérdida de contexto en la interrupción	Límites de ejecución y arranque en frío
Operación delegada	No, la gestiona el cliente	No, la gestiona el cliente	Sí, la gestiona la plataforma
Cómo se recupera un trabajo interrumpido	No aplica: la instancia no se interrumpe	Cola con reintentos o reinicio del lote	Reintento definido por el trigger o por la aplicación
Cuándo se elige	Cuando la continuidad es requisito	Cuando el trabajo admite reinicio	Cuando no se quiere operar servidores

Errores Comunes

Error: Tratar un contenedor como "una VM más ligera" y asumir que mover un monolito a contenedor produce microservicios. → Solución: Separar la técnica de empaquetado del diseño de aplicación: el contenedor aporta portabilidad y densidad; la independencia de despliegue y el escalado granular vienen de un diseño en componentes desacoplados, con estado externo y contratos claros.
Error: Emplear Spot VMs (preemptible VMs) en cargas que no admiten interrupción con el argumento del ahorro. → Solución: Reservar Spot para trabajos reanudables —lotes, pruebas, procesamiento con cola de reintentos— y mantener cargas transaccionales en VMs estándar o en servicios gestionados con alta disponibilidad; el ahorro de Spot solo es ahorro si la interrupción no cuesta nada.
Error: Adoptar GKE porque "es el estándar de la industria" sin capacidad de operación ni una carga que lo justifique. → Solución: Evaluar el requisito real: si la carga es una o dos aplicaciones HTTP con tráfico moderado, Cloud Run ofrece escalado y balanceo con menos superficie operativa; reservar GKE para carteras de servicios, equipos con habilidad de orquestación y necesidad de multinodo o multicluister.
Error: Suponer que serverless elimina toda la operación y que el coste siempre es menor. → Solución: Reconocer que serverless traslada la operación del servidor al código y a la configuración: seguridad del endpoint, límites de ejecución, observabilidad y coste por invocación; modelar el coste con el tráfico real, porque una función muy invocada y de duración larga puede costar más que un servicio permanente.
Error: Configurar autoscaling declarativamente y no comprobar si el sistema reacciona de verdad a la carga. → Solución: Verificar los límites de escala —nodos, réplicas, destinos del balanceo— y contrastarlos con métricas de tráfico; unos límites idénticos al tamaño actual o una métrica mal definida dejan el autoscaling inoperante, y la plataforma elástica se comporta como infraestructura fija.

Puntos para el Examen

🎯 Punto clave 1: Máquina virtual, contenedor y serverless son tres repartos distintos de la misma responsabilidad. La VM deja el sistema operativo al cliente; el contenedor deja la imagen al cliente y gestiona la ejecución; el serverless elimina casi toda la administración de servidores y cobra por ejecución. La pregunta de escenario siempre se responde comparando restricciones de carga con el contrato operativo de cada opción.

🎯 Punto clave 2: Compute Engine es la respuesta correcta para aplicaciones legacy especializadas y para cargas con requisitos de hardware, sistema operativo o licencia; el rehost sobre VM no es un fracaso de modernización, es la única ruta compatible en el plazo. Su valor de negocio es la salida del datacenter, la resiliencia de la plataforma y el coste variable, no la agilidad.

🎯 Punto clave 3: Kubernetes orquesta declarando estado deseado; GKE lo entrega como servicio gestionado y añade integración con red, balanceo y flotas. El autoscaling tiene tres planos —nodos, pods y escala a cero— y el load balancing con health basados en la aplicación es lo que permite que el fallo de una réplica no se note.

🎯 Punto clave 4: Las Spot VMs (preemptible VMs) ofrecen capacidad con descuento a cambio de ser interrumpibles: solo cargas reanudables sin pérdida. El serverless ofrece escalado automático y pago por ejecución a cambio de límites de tiempo y de entorno: adecuado para servicios HTTP y reacciones a eventos, no para procesos de larga duración con estado.

🎯 Punto clave 5: Los beneficios del cómputo en la nube —provisionamiento en minutos, escalado elástico, coste variable, integración con el resto de la plataforma— solo se materializan si la carga puede aprovecharlos. La habilidad que se evalúa es la de emparejar cada carga con su opción y justificar tanto la elección como la restricción que descarta las demás.

Recursos Externos

Documentación de Compute Engine — Referencia de máquinas virtuales, imágenes, discos, grupos de instancias y políticas de disponibilidad.
Spot VMs (preemptible VMs) — Condiciones de interrupción, duración y configuración de instancias con descuento.
Documentación de Google Kubernetes Engine — Clústeres, node pools, despliegues y operación de cargas contenedorizadas.
Autoscaler de clúster en GKE — Funcionamiento del escalado de nodos y su relación con la capacidad del clúster.
Balanceo de carga de Google Cloud — Balanceadores HTTP(S), TCP y su integración con grupos de instancias y con GKE.

Autoevaluación Rápida

Pregunta: Una empresa tiene un motor de cálculo propietario que depende de una versión concreta del sistema operativo y de una licencia por núcleo. ¿Dónde se ejecuta y qué se moderniza? Respuesta: Sobre Compute Engine, mediante rehost: la restricción de compatibilidad descarta contenedores y serverless porque el software exige un entorno específico. La modernización posible sin tocar el motor es de infraestructura —plantilla de imagen, grupo de instancias, health checks, etiquetas y política de discos—; la modernización de aplicación queda pendiente de que el proveedor del motor lo permita, y esa condición debe documentarse.
Pregunta: ¿Qué diferencia hay entre un contenedor y un microservicio, y por qué importa en el examen? Respuesta: El contenedor es una forma de empaquetar y ejecutar software con sus dependencias; el microservicio es un diseño en el que la aplicación se divide en servicios desplegables de forma independiente. Puede haber monolitos contenedorizados que no ganan agilidad de release, y microservicios desplegados en máquinas virtuales que sí la ganan. Importa porque las preguntas de escenario evalúan si se identifica qué está pidiendo el negocio: portabilidad (contenedor) o velocidad de cambio (microservicio).
Pregunta: Un equipo propone usar Spot VMs para la base de datos de la tienda en línea para reducir el coste. ¿Qué se responde? Respuesta: Se descarta. Las Spot VMs (preemptible VMs) pueden ser interrumpidas cuando Google necesita la capacidad, y una base de datos transaccional con sesión y estado en memoria no puede reiniciarse sin pérdida. El descuento de Spot está pensado para cargas reanudables: lotes, pruebas, transformaciones con cola de reintentos. Para la base de datos corresponde una instancia gestionada con alta disponibilidad, cuyo valor de negocio es la continuidad, no el menor coste por hora.
Pregunta: ¿Cuándo tiene sentido Cloud Run frente a GKE para el mismo servicio HTTP? Respuesta: Cuando el equipo quiere el escalado automático —incluido el escalado a cero— y el balanceo gestionados sin operar un clúster: Cloud Run se encarga de la plataforma y cobra por el tiempo de ejecución servido. GKE se elige cuando hay una cartera de servicios, necesidad de tráfico mTLS, colas, nodos dedicados o políticas multinivel, o cuando ya existe capacidad de orquestación y experiencia. La restricción de Cloud Run es de plataforma —límites de ejecución y de concurrencia—; la de GKE es de operación y de habilidad del equipo.
Pregunta: Un clúster de GKE y un grupo de instancias con autoscaling muestran ambos dimensiones fijas tras un mes de campaña con picos. ¿Qué conclusiones se extraen? Respuesta: Que la infraestructura declarada como elástica está funcionando como infraestructura fija, y que el fallo es de configuración y de medición, no de arquitectura. Hay que revisar los límites de escala —nodos y pods— y la métrica que dispara el autoscaling, y contrastarla con la carga real; mientras los límites no cubran el pico observado, se paga por la capacidad de escalar sin que esa capacidad esté operativa, lo que se corrige sin tocar el código y es verificable en el primer mes de operación.