Compara App Engine y Cloud Run

ID de región

REGION_ID es un código abreviado que Google asigna en función de la región que eliges cuando creas la app. El código no corresponde a un país ni a una provincia, aunque algunos ID de región puedan parecer similares a los códigos de país y provincia que se suelen usar. En el caso de las apps creadas después de febrero de 2020, REGION_ID.r se incluye en las URL de App Engine. En el caso de las apps existentes creadas antes de esta fecha, el ID de región es opcional en la URL.

Obtén más información acerca de los ID de región.

En esta guía, se proporciona una introducción a Cloud Run para quienes están familiarizados con App Engine. Se abordarán las similitudes y diferencias clave entre las plataformas sin servidores a fin de prepararte para la migración desde el entorno estándar de App Engine o el entorno flexible de App Engine.

Descripción general

Cloud Run es la evolución más reciente de Google Cloud sin servidores, basada en la experiencia de ejecución de 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, ya que incorpora muchas de las mejores funciones del entorno estándar de App Engine y de su entorno flexible. Los servicios de Cloud Run pueden manejar las mismas cargas de trabajo que los servicios de App Engine, pero Cloud Run ofrece a los clientes más flexibilidad para implementar estos servicios. Esta flexibilidad, junto con las integraciones mejoradas en Google Cloud y los servicios de terceros, también permite que Cloud Run maneje las cargas de trabajo que no se pueden ejecutar en App Engine.

Resumen de comparación

Si bien hay muchas similitudes y diferencias entre App Engine y Cloud Run, en esta descripción general nos enfocaremos en las áreas más relevantes para los clientes de App Engine que comienzan a usar Cloud Run.

Entorno estándar de App Engine Entorno flexible de App Engine Cloud Run
Terminología Aplicación N/A
Service Service
Versión Revisión

Extremos de URL
URL de la app
(servicio default) 		https://PROJECT_ID.REGION_ID.r.appspot.com N/A
URL de servicio https://SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://SERVICE_IDENTIFIER.run.app
URL de la versión/revisión https://VERSION-dot-SERVICE-dot-PROJECT_ID.REGION_ID.r.appspot.com
  • https://TAG---SERVICE_NAME-PROJECT_NUMBER.REGION.run.app
  • https://TAG---SERVICE_IDENTIFIER.run.app

Escalamiento
Ajuste de escala automático Sí Sí Sí
Ajuste de escala manual Sí Sí Si bien no existe una configuración específica de ajuste de escala manual, se puede replicar el mismo comportamiento si configuras la cantidad máxima de instancias igual a la cantidad mínima de ellas
Escala a cero Sí No Sí
Solicitudes de preparación Configurable No Automático
Tiempo de espera de la instancia inactiva (después de finalizar la última solicitud) Hasta 15 minutos Depende de la configuración de asignación de CPU. Usa CPU siempre asignada para emular el comportamiento de App Engine
Tiempo de espera de la solicitud
  • Ajuste de escala automático: 10 minutos
  • Ajuste de escala manual o básico: 24 horas
 60 minutos Se puede configurar hasta 60 minutos (valor predeterminado: 5 minutos)

Implementación
Desde la fuente Sí Sí
Imagen de contenedor No Sí (entornos de ejecución personalizados) Sí

Recursos de procesamiento
CPU virtual
Clase de instancia CPU virtual* Memoria
F/B1 .25 384MB
F/B2 0.5 768MB
F/B4 1 1.5GB
F/B4_1G 1 3GB
B8 2 3GB
* Los equivalentes de CPU virtual son aproximados 		Hasta 80 CPU virtuales Hasta 8 CPU virtuales
Memoria Hasta 6.5 GB por CPU virtual Hasta 32 GB

Modelo de precios
Tarifa por solicitud No No, cuando la CPU siempre está asignada.
Sí, cuando la CPU solo se asigna durante el procesamiento de la solicitud.
Instancias mínimas inactivas El mismo costo que las instancias activas Menor costo para instancias mínimas inactivas (consulta Tiempo de instancia de contenedor facturable)
Descuentos por compromiso de uso (CUD) No Sí

Seguridad
Configuración de entrada Sí Sí Sí
Rol de invocador No Sí
IAP Sí Sí Configura con Cloud Load Balancing
Firewalls Sí Sí Configura con Google Cloud Armor

Conectividad
Dominios personalizados Sí Sí Configura con Cloud Load Balancing
Conectividad VPC (incluida la VPC compartida) Sí N/A Sí
Configuración de salida de VPC Sí N/A Sí
Balanceo de cargas multirregional No Sí

Accede a servicios de Google Cloud
Cloud SQL Sí Sí Sí
Bibliotecas cliente de Cloud Si usas bibliotecas cliente de Cloud en App Engine, no es necesario que cambies nada cuando migres a Cloud Run. Estas funcionan donde sea, lo que significa que la aplicación es más portátil.
Servicios en paquetes heredados de App Engine Sí (solo Java, Python, Go y PHP) No No

Modelo de recursos

Diagrama del modelo de recursos de App Engine y Cloud Run

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

  • Cloud Run no cuenta con un recurso de aplicación de nivel superior ni el servicio de default correspondiente.
  • Los servicios de Cloud Run en el mismo proyecto se pueden implementar en diferentes regiones. En App Engine, todos los servicios del proyecto se encuentran en la misma región.
  • Cloud Run usa el término Revisión, en lugar de Versión, para alinearse con el modelo de recursos de Knative.
  • Los nombres de las revisiones de Cloud Run usan el formato SERVICE_NAME-REVISION_SUFFIX, en el que REVISION_SUFFIX se genera automáticamente o se configura con la marca de implementación --revision-suffix=REVISION_SUFFIX.
  • Las revisiones de Cloud Run son inmutables, lo que significa que no puedes volver a usar nombres como lo haces con las versiones de App Engine (mediante 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 la primera implementación del servicio. Los identificadores de servicio usan 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 las URLs del servicio (SERVICE_IDENTIFIER.run.app y https://SERVICE_NAME-PROJECT_NUMBER.REGION.run.app) de forma predeterminada. Para abordar una revisión específica, debes configurar una etiqueta de tráfico. En App Engine, las URLs del servicio y de la versión se exponen automáticamente.

Implementación y configuración

En App Engine, la mayor parte de la configuración se realiza en la app.yaml que se incluye en cada implementación. Esta simplicidad tiene un costo, ya que, si bien algunos parámetros de configuración se pueden actualizar con la API de Admin, la mayoría de los cambios requieren volver a implementar el servicio.

Si bien Cloud Run tiene el archivo de configuración service.yaml, no se usa de la misma manera que app.yaml. No se puede usar service.yaml de Cloud Run cuando se implementa desde la fuente, ya que uno de los elementos obligatorios es la ruta a la imagen del contenedor final. Además, el service.yaml cumple con la especificación de Knative y puede ser difícil de leer para quienes no están familiarizados con los archivos de configuración de estilo de Kubernetes. Si quieres obtener más información sobre el uso de service.yaml para administrar la configuración, consulta la documentación de Cloud Run.

Para los clientes de App Engine que comienzan a usar Cloud Run, el uso de las marcas de implementación de CLI de gcloud se alinea mucho más con la administración de configuración en la implementación de App Engine.

Para establecer la configuración cuando implementas un código nuevo en Cloud Run, usa las marcas gcloud run deploy:

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

Si bien no es necesario usar las marcas de configuración con cada implementación (consulta Administra las configuraciones), puedes hacerlo para simplificar la administración de configuración.

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

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

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

Administra la configuración

Para las implementaciones de App Engine, se deben proporcionar todas las opciones de configuración de todas las implementaciones y se debe asignar cualquier valor predeterminado a todas las opciones no proporcionadas. Por ejemplo, como sucede con service-a de App Engine, con versiones que usan los archivos app.yaml que se muestran a continuación:

Versión 1 de servicio a de App Engine Versión 2 del servicio a de App Engine
app.yaml 
runtime: python39
service: service-a
instance_class: F4

runtime: python39
service: service-a
Configuración aplicada 
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 proporciona ningún valor para instance_class, se configura con instance_class: F1 predeterminado.

En Cloud Run, se aplican todos los parámetros de configuración proporcionados, pero los que no se proporcionan mantienen sus valores existentes. Solo debes proporcionar los valores de la configuración que deseas cambiar. Por ejemplo:

Revisión 1 de servicio a de Cloud Run Revisión 2 de servicio a de Cloud Run
Comando de implementación 
gcloud run deploy service-a \
--cpu=4

gcloud run deploy service-a
Configuración aplicada 
service: service-a
vCPUs: 4
default values:
..
..

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

En App Engine, la implementación sin parámetros de configuración crea una versión con todos los parámetros de configuración predeterminados. En Cloud Run, la implementación sin parámetros de configuración crea una revisión con los mismos parámetros de configuración que la revisión anterior. Para la primera revisión de un servicio de Cloud Run que se implementa sin configuración, se crea una revisión con todos los parámetros de configuración predeterminados.

Parámetros de configuración predeterminados

Parámetros de configuración Entorno estándar de App Engine Entorno flexible de App Engine Cloud Run
Recursos de procesamiento F1 1 CPU virtual, .6 GB 1 CPU virtual, 512 MB
Simultaneidad máxima (solicitudes) 10 Ninguna 80
Tiempo de espera de la solicitud
  • Ajuste de escala automático: 10 minutos
  • Ajuste de escala manual o básico: 24 horas
 60 minutos 5 minutos
Objetivo de uso de CPU 60% 50% 60%
Cantidad máxima de instancias Ninguna 20 100
Cantidad mínima de instancias 0 2 0

Punto de entrada

Cuando implementas desde la fuente, App Engine lee el comando de punto de entrada del atributo entrypoint en app.yaml. Si no se proporciona un punto de entrada, se usa un valor predeterminado específico del entorno de ejecución. Cloud Run usa paquetes de compilación de Google Cloud cuando se implementa desde la fuente, y algunos lenguajes no tienen un punto de entrada predeterminado, lo que significa que debes proporcionar uno o la compilación fallará. Por ejemplo, los paquetes de compilación de Python requieren un Procfile o especifican la variable de entorno de compilación GOOGLE_ENTRYPOINT.

Revisa la documentación de los paquetes de compilación para cualquier requisito de configuración específico del lenguaje.

Escalamiento

Si bien el entorno estándar de Cloud Run y App Engine comparten gran parte de la misma infraestructura de escalamiento, Cloud Run se optimizó para permitir un escalamiento mucho más rápido. Como parte de esta optimización, los parámetros que se pueden configurar se limitan a lo siguiente:

Para las instancias de Cloud Run, el uso objetivo de CPU no se puede configurar y se establece en el 60%. Consulta la documentación de Cloud Run para obtener más detalles sobre el ajuste de escala automático.

El entorno flexible de App Engine usa el escalador automático de Compute Engine, por lo que tiene características de escalamiento muy diferentes de las del entorno estándar de App Engine y Cloud Run.

Tiempo de espera de la instancia inactiva

En App Engine, las instancias inactivas permanecen activas durante un máximo de 15 minutos después de que termina de procesarse la última solicitud. Cloud Run te permite configurar este comportamiento mediante la asignación de CPU. Para obtener el mismo comportamiento que App Engine, establece la asignación de CPU en La CPU siempre está asignada. Como alternativa, puedes usar la CPU asignada solo durante el procesamiento de solicitudes para que las instancias inactivas se apaguen de inmediato (si no hay solicitudes pendientes).

Solicitudes de preparación

Cloud Run prepara las instancias de forma automática mediante el comando entrypoint del contenedor, por lo que no necesitas habilitar las solicitudes de preparación de forma manual ni configurar un controlador /_ah/warmup. Si tienes un código que deseas ejecutar al inicio de la instancia, antes de que se procese cualquier solicitud, puedes hacer lo siguiente:

Contenido estático

En el entorno estándar de App Engine, puedes entregar contenido estático sin usar recursos de procesamiento mediante la entrega desde Cloud Storage o la configuración de controladores. Cloud Run no tiene la opción de controladores para entregar contenido estático, por lo que puedes entregar el contenido desde el servicio de Cloud Run (igual que el contenido dinámico), o desde Cloud Storage.

Rol de invocador de Cloud Run

Cloud Run también ofrece la capacidad de controlar el acceso al servicio con Identity and Access Management (IAM). Las vinculaciones de políticas de IAM para un servicio se pueden configurar mediante la CLI de gcloud, la consola o Terraform.

Para replicar el comportamiento de App Engine, puedes hacer público el servicio si permites las solicitudes no autenticadas. Esto se puede configurar en la implementación o mediante la actualización de las vinculaciones de políticas de IAM en un servicio existente.

Implementación

Usa la marca de implementación --allow-unauthenticated:

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

Servicio existente

Usa el comando gcloud run services add-iam-policy-binding:

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

En el ejemplo anterior, SERVICE_NAME es el nombre del servicio de Cloud Run.

Como alternativa, puedes elegir controlar quién tiene acceso al servicio si otorgas el rol de IAM de Invocador de Cloud Run que se puede configurar por servicio.

Implementación

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

En el ejemplo anterior, SERVICE_NAME es el nombre del servicio y MEMBER_TYPE es el tipo de principal. Por ejemplo, user:email@domain.com

A fin de obtener una lista de valores aceptables para MEMBER_TYPE, consulta la página de conceptos de IAM.

Servicio existente

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

En el ejemplo anterior, SERVICE_NAME es el nombre del servicio y MEMBER_TYPE es el tipo de principal. Por ejemplo, user:email@domain.com

A fin de obtener una lista de valores aceptables para MEMBER_TYPE, consulta la página de conceptos de IAM.

Variables de entorno y metadatos

App Engine y Cloud Run tienen ciertas variables de entorno que se configuran automáticamente. En la siguiente tabla, se muestran las variables de entorno de App Engine, junto con sus equivalentes de Cloud Run. Cloud Run solo implementa algunas variables de entorno, en comparación con App Engine, pero los datos disponibles del servidor de metadatos son, en su mayoría, equivalentes.

Variables de entorno predeterminadas

Nombre en App Engine Nombre en Cloud Run Descripción
GAE_SERVICE K_SERVICE Es el nombre del servicio actual. En App Engine, se establece como “predeterminado” si no se especifica.
GAE_VERSION K_REVISION Etiqueta de la versión actual de tu servicio.
PORT PORT Puerto que recibe las solicitudes HTTP.
N/A K_CONFIGURATION El nombre de la configuración de Cloud Run que creó la revisión.
GOOGLE_CLOUD_PROJECT N/A ID del proyecto de Cloud asociado a tu aplicación.
GAE_APPLICATION ID de tu aplicación de App Engine. Este ID tiene el prefijo “código regional~”, como “e~”, para aplicaciones implementadas en Europa.
GAE_DEPLOYMENT_ID ID de la implementación actual.
GAE_ENV Entorno de App Engine. Se establece como “standard” si se encuentra en el entorno estándar.
GAE_INSTANCE ID de la instancia en la que se está ejecutando tu servicio.
GAE_MEMORY_MB Cantidad de memoria disponible para el proceso de la aplicación, en MB.
NODE_ENV (solo disponible en el entorno de ejecución de Node.js) Se establece como “production” cuando se implementa tu servicio.
GAE_RUNTIME Es el entorno de ejecución especificado en tu archivo app.yaml.

Rutas de acceso comunes del servidor de metadatos

Ruta Descripción Ejemplo
/computeMetadata/v1/project/project-id ID del proyecto al que pertenece el servicio test_project
/computeMetadata/v1/project/numeric-project-id Número del proyecto al que pertenece el servicio 12345678912
/computeMetadata/v1/instance/id Identificador único de la instancia de contenedor (también disponible en registros). 16a61494692b7432806a16
(cadena de caracteres alfanuméricos)
/computeMetadata/v1/instance/region
** No se encuentra disponible para el entorno flexible de App Engine 		En la región de este servicio se muestra projects/PROJECT_NUMBER/regions/REGION projects/12345678912/regions/us-central1
/computeMetadata/v1/instance/service-accounts/default/email Es el correo electrónico de la cuenta de servicio del entorno de ejecución de este servicio. service_account@test_project.iam.gserviceaccount.com
/computeMetadata/v1/instance/service-accounts/default/token Genera un token de acceso de OAuth2 para la cuenta de servicio de este servicio. En este extremo se mostrará una respuesta JSON con un atributo access_token. {
"access_token":"<TOKEN>",
"expires_in":1799,
"token_type":"Portador"
}

¿Qué sigue?