Comparar App Engine y Cloud Run

Esta guía ofrece una introducción a Cloud Run para los usuarios que conocen App Engine. En él se describen las principales similitudes y diferencias entre las plataformas sin servidor para ayudarte a prepararte para migrar desde el entorno estándar o el entorno flexible de App Engine.

Información general

Cloud Run es la última evolución de Google Cloud sin servidor, basada en la experiencia de ejecutar App Engine durante más de una década. Cloud Run se ejecuta en gran parte de la misma infraestructura que el entorno estándar de App Engine, por lo que hay muchas similitudes entre estas dos plataformas.

Cloud Run está diseñado para mejorar la experiencia de App Engine e incorpora muchas de las mejores funciones del entorno estándar y flexible de App Engine. Los servicios de Cloud Run pueden gestionar las mismas cargas de trabajo que los servicios de App Engine, pero Cloud Run ofrece a los clientes mucha más flexibilidad a la hora de implementar estos servicios. Esta flexibilidad, junto con las integraciones mejoradas con Google Cloud y servicios de terceros, también permite que Cloud Run gestione cargas de trabajo que no se pueden ejecutar en App Engine.

Resumen de la comparación

Aunque hay muchas similitudes y diferencias entre App Engine y Cloud Run, esta descripción general se centra en las áreas más relevantes para los clientes de App Engine que empiezan a usar Cloud Run.

Modelo de recurso

El modelo de recursos de Cloud Run es muy similar al de App Engine, pero hay algunas diferencias clave:

• Cloud Run no tiene un recurso Application de nivel superior ni el servicio default correspondiente.
• Los servicios de Cloud Run del mismo proyecto se pueden desplegar en diferentes regiones. En App Engine, todos los servicios del proyecto están en la misma región.
• Cloud Run usa el término Revisión en lugar de Versión para ajustarse al modelo de recursos de Knative.
• Los nombres de las revisiones de Cloud Run tienen el formato SERVICE_NAME-REVISION_SUFFIX, donde REVISION_SUFFIX se genera automáticamente o se define mediante la marca de despliegue --revision-suffix=REVISION_SUFFIX.
• Las revisiones de Cloud Run son inmutables, lo que significa que no puedes reutilizar nombres como en las versiones de App Engine (con la marca de implementación --version=VERSION_ID).
• Las URLs de servicio de Cloud Run se basan en un identificador de servicio que se genera automáticamente en el primer despliegue del servicio. Los identificadores de servicio tienen el formato SERVICE_NAME-<auto-generated identifier>. El identificador de servicio es único y no cambia durante la vida útil del servicio.
• En Cloud Run, solo se exponen de forma predeterminada las URLs de servicio (SERVICE_IDENTIFIER.run.app y https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app). Para dirigirte a una revisión específica, debes configurar una etiqueta de tráfico. En App Engine, se exponen automáticamente tanto las URLs de servicio como las de versión.

Implementación y configuración

En App Engine, la mayoría de las configuraciones se realizan en el archivo app.yaml, que se incluye en cada implementación. Esta sencillez tiene un coste, ya que, aunque se pueden actualizar algunos ajustes mediante la API Admin, la mayoría de los cambios requieren volver a implementar el servicio.

Aunque Cloud Run tiene el archivo de configuración service.yaml, no se usa de la misma forma que app.yaml. El service.yaml de Cloud Run no se puede usar al implementar desde el código fuente, ya que uno de los elementos obligatorios es la ruta a la imagen de contenedor final. Además, service.yaml cumple las especificaciones de Knative y puede resultar difícil de leer para quienes no estén familiarizados con los archivos de configuración de Kubernetes. Para obtener más información sobre cómo usar service.yaml para gestionar la configuración, consulta la documentación de Cloud Run.

Para los clientes de App Engine que empiezan a usar Cloud Run, el uso de las marcas de despliegue de la CLI gcloud se ajusta mucho más a la gestión de la configuración de App Engine en el momento del despliegue.

Para definir la configuración al desplegar código nuevo en Cloud Run, usa las marcas gcloud run deploy:

gcloud run deploy SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Aunque no es necesario usar las marcas de configuración en todas las implementaciones (consulta Gestión de configuraciones), puedes hacerlo para simplificar la gestión de la configuración.

En Cloud Run, también puedes actualizar la configuración sin volver a desplegar el código fuente mediante gcloud run services update:

gcloud run services update SERVICE_NAME \
--cpu CPU \
--memory MEMORY \
--concurrency CONCURRENCY

Como las revisiones de Cloud Run son inmutables, este comando creará una nueva revisión con la configuración actualizada, pero usará la misma imagen de contenedor que la revisión actual.

Gestionar configuraciones

En las implementaciones de App Engine, se deben proporcionar todos los ajustes para cada implementación. Los ajustes que no se proporcionen tendrán valores predeterminados. Por ejemplo, App Engine service-a, con versiones que usan los archivos app.yaml de la siguiente tabla:

runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a

runtime: python39
service: service-a
instance_class: F4
default values:
..
..

runtime: python39
service: service-a
default values:
instance_class: F1
..
..

version1 se configura con instance_class: F4, mientras que version2, que no ha proporcionado ningún valor para instance_class, se configura con el valor predeterminado instance_class: F1.

En Cloud Run, se aplican los ajustes de configuración que se proporcionen, pero los que no se proporcionen mantienen sus valores. Solo tiene que proporcionar valores para los ajustes que quiera cambiar. Por ejemplo:

gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a

service: service-a
vCPUs: 4
default values:
..
..

service: service-a
vCPUs: 4
default values:
..
..

En App Engine, si se realiza un despliegue sin ajustes de configuración, se crea una versión con todos los ajustes predeterminados. En Cloud Run, si se hace un despliegue sin ajustes de configuración, se crea una revisión con los mismos ajustes de configuración que la revisión anterior. En la primera revisión de un servicio de Cloud Run, si se despliega sin ajustes de configuración, se crea una revisión con todos los ajustes predeterminados.

Valores predeterminados de configuración

Punto de entrada

Cuando se implementa desde el origen, App Engine lee el comando de punto de entrada del atributo entrypoint en el archivo app.yaml. Si no se proporciona ningún punto de entrada, se utiliza un valor predeterminado específico del tiempo de ejecución. Cloud Run usa buildpacks de Google Cloud al desplegar desde una fuente. Algunos lenguajes no tienen un punto de entrada predeterminado, por lo que debes proporcionar uno o la compilación fallará. Por ejemplo, los paquetes de compilación de Python requieren un Procfile o especificar la variable de entorno de compilación GOOGLE_ENTRYPOINT.

Consulta la documentación de los buildpacks para ver los requisitos de configuración específicos de cada lenguaje.

Comprobaciones del estado

En App Engine, las comprobaciones del estado son en gran medida automáticas y las gestiona la plataforma. App Engine realiza comprobaciones de actividad y de disponibilidad para determinar si una instancia está operativa y lista para atender el tráfico. Si una instancia no supera las comprobaciones automáticas de forma constante, App Engine la finaliza y la sustituye por una nueva para asegurar la continuidad del servicio.

Cloud Run ofrece un control más granular con sondas de inicio y de vivacidad configurables. Estas sondas te permiten definir una instancia correcta, lo cual es fundamental para los microservicios complejos.

En Cloud Run, puede configurar las siguientes sondas:

• Sonda de inicio para definir cuándo se ha iniciado un contenedor y está listo para servir tráfico. Cuando configuras una sonda de inicio, se inhabilitan las comprobaciones de actividad hasta que el inicio se realiza correctamente, lo que asegura que las sondas de actividad no interfieran con el inicio de la aplicación.

• Sonda de actividad para determinar cuándo reiniciar un contenedor. Por ejemplo, las sondas de actividad pueden detectar un interbloqueo cuando una aplicación se está ejecutando, pero no puede avanzar. Reiniciar un contenedor en ese estado asegura que tu aplicación esté disponible a pesar de los errores.

Para obtener más información, consulta Configurar comprobaciones del estado de los contenedores para los servicios.

Escalado

Aunque Cloud Run y el entorno estándar de App Engine comparten una infraestructura de escalado similar, Cloud Run se ha optimizado para ofrecer un escalado más rápido y la posibilidad de reducir la escala a cero. Esto da como resultado menos ajustes configurables. Esta simplificación limita los ajustes configurables a los siguientes:

• Simultaneidad máxima
• Instancias máximas y mínimas

En las instancias de Cloud Run, la utilización de CPU objetivo no se puede configurar, sino que se fija en el 60%. Para obtener más información, consulta el artículo Acerca del escalado automático de instancias en servicios de Cloud Run.

El entorno flexible de App Engine usa la herramienta de escalado automático de Compute Engine y, por lo tanto, tiene características de escalado muy diferentes a las del entorno estándar de App Engine y Cloud Run.

Migrar controles de escalado de App Engine a Cloud Run

En esta sección se describe cómo asignar la configuración de escalado de App Engine a Cloud Run.

Número mínimo de instancias (calentamiento)

Mantén un número mínimo de instancias activas para gestionar el tráfico base y evitar los arranques en frío.

Estrategia de migración: define el número mínimo de instancias para el calentamiento a nivel de servicio. Si diriges el tráfico a una revisión específica, el ajuste a nivel de revisión anula el valor predeterminado a nivel de servicio. Usa este ajuste para probar una nueva revisión con un número mínimo de instancias diferente antes de promocionarla a producción.

Número máximo de instancias

Define un límite estricto en el número total de instancias para controlar los costes y proteger las dependencias posteriores.

Estrategia de migración: define un límite global a nivel de servicio. Cloud Run aplica el valor más bajo de los ajustes de nivel de servicio y de nivel de revisión. Para obtener más información, consulta Definir el número máximo de instancias de los servicios.

Simultaneidad

Define la capacidad de solicitudes de una sola instancia.

Estrategia de migración: sigue una de estas dos estrategias de migración:

• Empieza con el valor predeterminado de capacidad de instancia de Cloud Run, que es 80, y haz pruebas de carga para encontrar el límite de simultaneidad estable de tu aplicación en Cloud Run. Ajustar este valor es una forma eficaz de optimizar el rendimiento y los costes en Cloud Run. Reduce el valor de 80 en función de los resultados de las pruebas. Para obtener más información, consulta Configurar el número máximo de solicitudes simultáneas por instancia.

• Usa el valor de configuración que ya tengas en el entorno estándar de App Engine, que es de 10 solicitudes simultáneas por instancia de forma predeterminada. Es una opción segura, ya que se trata de una configuración conocida que funciona en tu aplicación. Sin embargo, esto puede provocar una infrautilización significativa de tus instancias de Cloud Run y, potencialmente, un aumento de los costes, ya que el autoescalador crea más instancias de las necesarias para gestionar la carga.

Uso de CPU

Escala cuando la carga de la CPU supere un umbral determinado.

Estrategia de migración: no puedes configurar este valor. El autoescalador de Cloud Run mantiene un uso de CPU de aproximadamente el 60% en las instancias activas. A diferencia de App Engine, Cloud Run solo asigna CPU durante el procesamiento de solicitudes y, en el resto de los casos, la limita a cero. En el entorno estándar de App Engine, independientemente del tipo de escalado que configures, App Engine se asegura de que la CPU esté disponible continuamente para tu instancia.

Si tu aplicación realiza alguna tarea en segundo plano entre solicitudes, como usar hilos en segundo plano en el escalado básico o manual, configura la facturación basada en instancias en Cloud Run para evitar que se suspendan tus tareas de procesamiento en segundo plano.

Rendimiento de solicitud

Escala en función del rendimiento de las solicitudes cuando tu aplicación alcance el límite de simultaneidad.

Estrategia de migración: la herramienta de escalado automático de Cloud Run intenta mantener el número de solicitudes simultáneas por instancia en el 60% del valor de maxInstanceRequestConcurrency. Cuando define este valor, implícitamente define el rendimiento de destino que activa un evento de escalado vertical.

Latencia

Define un periodo de espera de los usuarios que active el escalado. App Engine reacciona parcialmente a la puesta en cola de solicitudes.

Estrategia de migración: Cloud Run escala automáticamente antes de que las solicitudes empiecen a ponerse en cola y se produzcan picos de latencia. Si se producen picos de latencia, considera la posibilidad de ajustar el valor de template.maxInstanceRequestConcurrency para que el escalado horizontal sea más rápido.

Instancias inactivas

Propósito: en App Engine, los ajustes de instancias inactivas controlan un grupo de instancias inactivas precalentadas que absorben los picos de tráfico y controlan los costes.

Estrategia de migración: no puedes configurar un número mínimo o máximo de instancias inactivas en Cloud Run. Para mantener las instancias activas y listas para recibir tráfico inmediato, y para mitigar los arranques en frío en Cloud Run, usa el ajuste scaling.min_instance_count, que asegura que siempre se ejecute un número mínimo de contenedores. Para obtener más información, consulta el artículo Acerca del escalado automático de instancias en los servicios de Cloud Run.

Tiempo de espera de instancia inactiva

En App Engine, las instancias inactivas permanecen activas durante aproximadamente 15 minutos después de la última solicitud. Cloud Run controla este comportamiento mediante su ajuste de facturación.

Para conseguir un comportamiento de facturación similar al de App Engine, donde la CPU se asigna fuera del procesamiento de solicitudes, usa la facturación basada en instancias en Cloud Run.

También puedes usar la facturación basada en solicitudes para que la CPU solo se asigne durante el procesamiento de solicitudes. Con este ajuste, la instancia seguirá activa durante un máximo de 15 minutos después de la última solicitud, pero la CPU se limitará durante ese tiempo de inactividad.

Escalado básico

Cuando configuras el ajuste basic_scaling en el entorno estándar de App Engine, se crean instancias cuando se reciben solicitudes y se reduce a cero después de un periodo de inactividad. Puedes replicar este comportamiento en Cloud Run mediante el escalado automático configurando min-instances en 0.

Escalado manual

Ejecuta un número fijo de instancias e inhabilita el autoescalado.

Estrategia de migración: en Cloud Run, hay una asignación directa para el escalado manual. Define el modo de escalado como MANUAL en el nivel de servicio de Cloud Run y especifica el número exacto de instancias que se van a ejecutar con manualInstanceCount. Esto tiene el mismo efecto que inhabilitar por completo el ajuste de escala automático. Para obtener más información, consulta Escalado manual en Cloud Run.

Periodo de enfriamiento

Configura un periodo de enfriamiento después de un evento de escalado vertical antes de que se produzca otro evento.

Estrategia de migración: no es necesaria. Cloud Run se escala automáticamente en función de la demanda y la utilización, y se ha diseñado para reaccionar de forma eficiente sin necesidad de configurar un periodo de enfriamiento manual.

Solicitudes de preparación

Cloud Run activa automáticamente las instancias mediante el comando entrypoint del contenedor, por lo que no tienes que habilitar manualmente las solicitudes de activación ni configurar un controlador /_ah/warmup. Si tienes código que quieres ejecutar al iniciar la instancia antes de que se procese ninguna solicitud, puedes hacer lo siguiente:

• Configurar la aplicación para que escuche las solicitudes
• Configurar una sonda de inicio personalizada

Contenido estático

En el entorno estándar de App Engine, puedes publicar contenido estático sin usar recursos de computación publicándolo desde Cloud Storage o configurando gestores.Cloud Run no tiene la opción de gestores para publicar contenido estático, por lo que puedes publicar el contenido desde el servicio Cloud Run (igual que el contenido dinámico) o desde Cloud Storage.

Rol Invocador de Cloud Run

Cloud Run también ofrece la posibilidad de controlar el acceso a un servicio con Gestión de Identidades y Accesos (IAM). Los enlaces de políticas de gestión de identidades y accesos de un servicio se pueden configurar mediante la CLI de gcloud, la consola o Terraform.

Para replicar el comportamiento de App Engine, puedes hacer que el servicio sea público permitiendo las solicitudes sin autenticar. Se puede definir durante la implementación o actualizando los enlaces de la política de gestión de identidades y accesos en un servicio.

gcloud run deploy SERVICE_NAME ... --allow-unauthenticated

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member="allUsers" \
--role="roles/run.invoker"

También puedes controlar quién tiene acceso al servicio concediendo el rol de gestión de identidades y accesos Invocador de Cloud Run, que se puede configurar por servicio.

gcloud run deploy SERVICE_NAME ... --no-allow-unauthenticated
gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

gcloud run services add-iam-policy-binding SERVICE_NAME \
--member=MEMBER_TYPE \
--role="roles/run.invoker"

Variables de entorno y metadatos

Tanto App Engine como Cloud Run tienen determinadas variables de entorno que se definen automáticamente. En la siguiente tabla se muestran las variables de entorno de App Engine y sus equivalentes en Cloud Run. Cloud Run solo implementa unas pocas variables de entorno, en comparación con App Engine, pero los datos disponibles en el servidor de metadatos son prácticamente los mismos.

Variables de entorno predeterminadas

Rutas comunes del servidor de metadatos

Siguientes pasos

• Guía de inicio rápido: despliega un servicio web con Cloud Run
• ¿Mi aplicación es adecuada para Cloud Run?
• Migrar mi dominio personalizado de App Engine a Cloud Load Balancing
• Otros recursos:
  • Migrar de App Engine a Cloud Run con Docker (Python: laboratorio, vídeo; Java: laboratorio)
  • Migrar de App Engine a Cloud Run con buildpacks (Python: laboratorio, vídeo; Java: laboratorio)