Migra de AWS a Google Cloud: Migra de AWS Lambda a Cloud Run

Last reviewed 2024-10-21 UTC

Google Cloud proporciona herramientas, productos, orientación y servicios profesionales para ayudar a migrar cargas de trabajo sin servidores de AWS Lambda de Amazon Web Services (AWS) a Google Cloud. Si bien Google Cloud proporciona varios servicios en los que puedes desarrollar e implementar aplicaciones sin servidores, este documento se enfoca en la migración aCloud Run, un entorno de ejecución sin servidores. Tanto AWS Lambda como Cloud Run comparten similitudes, como el aprovisionamiento automático de recursos, el ajuste de escala por parte del proveedor de servicios en la nube y un modelo de precios de pago por uso.

Este documento te ayuda a diseñar, implementar y validar un plan para migrar cargas de trabajo sin servidores de AWS Lambda a Cloud Run. Además, ofrece orientación para quienes evalúan los posibles beneficios y el proceso de una migración de este tipo.

Este documento pertenece a una serie de varias partes sobre la migración de AWS aGoogle Cloud que incluye los siguientes documentos:

Para obtener más información sobre cómo elegir el entorno de ejecución sin servidores adecuado para tu lógica de negocios, consulta Selecciona un entorno de ejecución de contenedor administrado. Para obtener un mapeo completo entre los servicios de AWS y Google Cloud , consulta Compara los servicios de AWS y Azure con los servicios de Google Cloud .

Para esta migración a Google Cloud, te recomendamos que sigas el framework de migración que se describe en Migra a Google Cloud: Comienza ahora.

En el siguiente diagrama, se ilustra la ruta del recorrido de tu migración.

Ruta de migración con cuatro fases

Puedes migrar de tu entorno de origen a Google Cloud en una serie de iteraciones. Por ejemplo, puedes migrar algunas cargas de trabajo primero y otras más tarde. Para cada iteración de migración independiente, debes seguir las fases del framework de migración general:

  1. Evalúa y descubre las cargas de trabajo y los datos.
  2. Planifica y compila una base en Google Cloud.
  3. Migra tus cargas de trabajo y datos a Google Cloud.
  4. Optimiza tu entorno de Google Cloud .

Para obtener más información sobre las fases de este framework, consulta Migra a Google Cloud: Comienza ahora.

Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y te asegures de tener una estrategia de reversión. Para ayudarte a validar tu plan de migración, consulta Migra a Google Cloud: Prácticas recomendadas para validar un plan de migración.

La migración de cargas de trabajo sin servidores suele ir más allá de solo trasladar funciones de un proveedor de servicios en la nube a otro. Dado que las aplicaciones basadas en la nube dependen de una red interconectada de servicios, la migración de AWS a Google Cloud podría requerir el reemplazo de los servicios dependientes de AWS por servicios de Google Cloud . Por ejemplo, considera una situación en la que tu función de Lambda interactúa con Amazon SQS y Amazon SNS. Para migrar esta función, es probable que debas adoptar Pub/Sub y Cloud Tasks para lograr una funcionalidad similar.

La migración también te brinda una valiosa oportunidad para revisar a fondo la arquitectura y las decisiones de diseño de tu aplicación sin servidor. A través de esta revisión, es posible que descubras oportunidades para hacer lo siguiente:

  • Optimiza con Google Cloud funciones integradas: Explora si los servicios ofrecen ventajas únicas o se alinean mejor con los requisitos de tu aplicación.Google Cloud
  • Simplifica tu arquitectura: Evalúa si es posible optimizarla consolidando la funcionalidad o usando los servicios de manera diferente dentro deGoogle Cloud.
  • Mejora la eficiencia en los costos: Evalúa las posibles diferencias de costos de ejecutar tu aplicación refactorizada en la infraestructura que se proporciona en Google Cloud.
  • Mejora la eficiencia del código: Refactoriza tu código junto con el proceso de migración.

Planifica tu migración de forma estratégica. No veas la migración como un ejercicio de cambio de host (lift and shift). Aprovecha la migración para mejorar el diseño general y la calidad del código de tu aplicación sin servidores.

Evalúa el entorno de origen|

En la fase de evaluación, determinarás los requisitos y las dependencias para migrar tu entorno de origen a Google Cloud.

La fase de evaluación es fundamental para el éxito de la migración. Debes obtener un conocimiento profundo sobre las cargas de trabajo que deseas migrar, sus requisitos, sus dependencias y tu entorno actual. Debes saber cuál es tu punto de partida para planificar y ejecutar de forma correcta una migración de Google Cloud.

La fase de evaluación consta de las siguientes tareas:

  1. Crea un inventario completo de tus aplicaciones.
  2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
  3. Capacita y educa a tus equipos en Google Cloud.
  4. Crea experimentos y pruebas de concepto en Google Cloud.
  5. Calcula el costo total de propiedad (TCO) del entorno de destino.
  6. Elige la estrategia de migración para tus cargas de trabajo.
  7. Elige tus herramientas de migración.
  8. Define el plan y el cronograma de migración.
  9. Valida tu plan de migración.

Para obtener más información sobre la fase de evaluación y estas tareas, consulta Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo. Las siguientes secciones se basan en la información de ese documento.

Crea un inventario de tus cargas de trabajo de AWS Lambda

Para definir el alcance de la migración, crea un inventario y recopila información sobre tus cargas de trabajo de AWS Lambda.

Para crear el inventario de tus cargas de trabajo de AWS Lambda, te recomendamos que implementes un mecanismo de recopilación de datos basado en las APIs, las herramientas para desarrolladores y la interfaz de línea de comandos de AWS.

Después de compilar tu inventario, te recomendamos que recopiles información sobre cada carga de trabajo de AWS Lambda en el inventario. Para cada carga de trabajo, enfócate en los aspectos que te ayuden a anticipar posibles inconvenientes. Además, analiza esa carga de trabajo para comprender cómo es posible que debas modificarla y sus dependencias antes de migrar a Cloud Run. Te recomendamos que comiences por recopilar datos sobre los siguientes aspectos de cada carga de trabajo de AWS Lambda:

  • El caso de uso y el diseño
  • El repositorio de código fuente
  • Los artefactos de implementación
  • La invocación, los activadores y los resultados
  • Los entornos de ejecución
  • Es la configuración de la carga de trabajo.
  • Los controles y permisos de acceso
  • Los requisitos reglamentarios y de cumplimiento
  • Los procesos operativos y de implementación

Caso de uso y diseño

Recopilar información sobre el caso de uso y el diseño de las cargas de trabajo ayuda a identificar una estrategia de migración adecuada. Esta información también te ayuda a comprender si necesitas modificar tus cargas de trabajo y sus dependencias antes de la migración. Para cada carga de trabajo, te recomendamos que hagas lo siguiente:

  • Obtén estadísticas sobre el caso de uso específico al que sirve la carga de trabajo y, luego, identifica las dependencias con otros sistemas, recursos o procesos.
  • Analiza el diseño y la arquitectura de la carga de trabajo.
  • Evalúa los requisitos de latencia de la carga de trabajo.

Repositorio del código fuente

Inventariar el código fuente de tus funciones de AWS Lambda es útil si necesitas refactorizar tus cargas de trabajo de AWS Lambda para que sean compatibles con Cloud Run. La creación de este inventario implica hacer un seguimiento de la base de código, que suele almacenarse en sistemas de control de versión como Git o en plataformas de desarrollo como GitHub o GitLab. El inventario de tu código fuente es fundamental para tus procesos de DevOps, como las canalizaciones de integración continua y desarrollo continuo (CI/CD), ya que estos procesos también deberán actualizarse cuando migres a Cloud Run.

Artefactos de implementación

Saber qué artefactos de implementación necesita la carga de trabajo es otro componente que te ayuda a comprender si es posible que debas refactorizar tus cargas de trabajo de AWS Lambda. Para identificar qué artefactos de implementación necesita la carga de trabajo, recopila la siguiente información:

  • Es el tipo de paquete de implementación para implementar la carga de trabajo.
  • Cualquier capa de AWS Lambda que contenga código adicional, como bibliotecas y otras dependencias.
  • Son las extensiones de AWS Lambda de las que depende la carga de trabajo.
  • Los calificadores que configuraste para especificar versiones y alias.
  • Es la versión de la carga de trabajo implementada.

Invocación, activadores y resultados

AWS Lambda admite varios mecanismos de invocación, como los activadores, y diferentes modelos de invocación, como la invocación síncrona y la invocación asíncrona. Para cada carga de trabajo de AWS Lambda, te recomendamos que recopiles la siguiente información relacionada con los activadores y las invocaciones:

  • Son los activadores y las asignaciones de origen de eventos que invocan la carga de trabajo.
  • Indica si la carga de trabajo admite invocaciones síncronas y asíncronas.
  • Son las URLs y los extremos HTTP(S) de la carga de trabajo.

Tus cargas de trabajo de AWS Lambda pueden interactuar con otros recursos y sistemas. Debes saber qué recursos consumen los resultados de tus cargas de trabajo de AWS Lambda y cómo lo hacen. Este conocimiento te ayuda a determinar si necesitas modificar algo que pueda depender de esos resultados, como otros sistemas o cargas de trabajo. Para cada carga de trabajo de AWS Lambda, te recomendamos que recopiles la siguiente información sobre otros recursos y sistemas:

  • Son los recursos de destino a los que la carga de trabajo podría enviar eventos.
  • Son los destinos que reciben registros de información para las invocaciones asíncronas.
  • Es el formato de los eventos que procesa la carga de trabajo.
  • Cómo interactúan tu carga de trabajo de AWS Lambda y sus extensiones con las APIs de AWS Lambda o con otras APIs de AWS

Para funcionar, es posible que tus cargas de trabajo de AWS Lambda almacenen datos persistentes y que interactúen con otros servicios de AWS. Para cada carga de trabajo de AWS Lambda, te recomendamos que recopiles la siguiente información sobre los datos y otros servicios:

  • Indica si la carga de trabajo accede a nubes privadas virtuales (VPC) o a otras redes privadas.
  • Cómo la carga de trabajo almacena datos persistentes, por ejemplo, con el uso de almacenamiento de datos efímeros y Amazon Elastic File System (EFS).

Entornos de ejecución y de tiempo de ejecución

AWS Lambda admite varios entornos de ejecución para tus cargas de trabajo. Para asignar correctamente los entornos de ejecución de AWS Lambda a los entornos de ejecución de Cloud Run, te recomendamos que evalúes lo siguiente para cada carga de trabajo de AWS Lambda:

  • Es el entorno de ejecución de la carga de trabajo.
  • Es la arquitectura del conjunto de instrucciones del procesador de la computadora en la que se ejecuta la carga de trabajo.

Si tus cargas de trabajo de AWS Lambda se ejecutan en entornos de ejecución específicos del lenguaje, ten en cuenta lo siguiente para cada carga de trabajo de AWS Lambda:

  • Tipo, versión y el identificador único del entorno de ejecución específico del idioma.
  • Son las modificaciones que aplicaste al entorno de ejecución.

Configuración de las cargas de trabajo

Para configurar tus cargas de trabajo a medida que las migras de AWS Lambda a Cloud Run, te recomendamos que evalúes cómo configuraste cada carga de trabajo de AWS Lambda.

Para cada carga de trabajo de AWS Lambda, recopila información sobre los siguientes parámetros de configuración de simultaneidad y escalabilidad:

  • Son los controles de simultaneidad.
  • Es la configuración de escalabilidad.
  • Es la configuración de las instancias de la carga de trabajo, en términos de la cantidad de memoria disponible y el tiempo de ejecución máximo permitido.
  • Indica si la carga de trabajo usa AWS Lambda SnapStart, simultaneidad reservada o simultaneidad aprovisionada para reducir la latencia.
  • Las variables de entorno que configuraste, así como las que configura AWS Lambda y de las que depende la carga de trabajo.
  • Las etiquetas y el control de acceso basado en atributos
  • Es la máquina de estados que controla las condiciones excepcionales.
  • Son las imágenes base y los archivos de configuración (como el Dockerfile) para los paquetes de implementación que usan imágenes de contenedor.

Controles y permisos de acceso

Como parte de tu evaluación, te recomendamos que evalúes los requisitos de seguridad de tus cargas de trabajo de AWS Lambda y su configuración en términos de controles y administración de acceso. Esta información es fundamental si necesitas implementar controles similares en tu entorno de Google Cloud . Para cada carga de trabajo, considera lo siguiente:

  • Rol y permisos de ejecución.
  • Es la configuración de administración de identidades y accesos que la carga de trabajo y sus capas usan para acceder a otros recursos.
  • Es la configuración de administración de identidades y accesos que usan otras cuentas y servicios para acceder a la carga de trabajo.
  • Los controles de administración

Requisitos reglamentarios y de cumplimiento

Para cada carga de trabajo de AWS Lambda, asegúrate de comprender sus requisitos reglamentarios y de cumplimiento realizando las siguientes acciones:

  • Evalúa los requisitos normativos y de cumplimiento que debe satisfacer la carga de trabajo.
  • Determina si la carga de trabajo cumple actualmente con estos requisitos.
  • Determina si hay requisitos futuros que se deberán cumplir.

Los requisitos reglamentarios y de cumplimiento pueden ser independientes del proveedor de servicios en la nube que uses, y estos requisitos también pueden tener un impacto en la migración. Por ejemplo, es posible que debas asegurarte de que el tráfico de datos y de red permanezca dentro de los límites de ciertas ubicaciones geográficas, como la Unión Europea (UE).

Evalúa los procesos operativos y de implementación

Es fundamental comprender claramente cómo funcionan los procesos operativos y de implementación. Estas son una parte fundamental de las prácticas que preparan y mantienen tu entorno de producción y las cargas de trabajo que se ejecutan allí.

Tus procesos operativos y de implementación pueden compilar los artefactos que tus cargas de trabajo necesitan para funcionar. Por lo tanto, debes recopilar información sobre cada tipo de artefacto. Por ejemplo, un artefacto puede ser un paquete de sistema operativo, un paquete de implementación de aplicación, una imagen de sistema operativo, una imagen de contenedor o algo más.

Además del tipo de artefacto, considera cómo completar las siguientes tareas:

  • Desarrolla tus cargas de trabajo. Evalúa los procesos que tienen implementados los equipos de desarrollo para compilar tus cargas de trabajo. Por ejemplo, ¿cómo diseñan, codifican y prueban tus cargas de trabajo tus equipos de desarrollo?
  • Genera los artefactos que implementes en tu entorno de origen. Para implementar tus cargas de trabajo en tu entorno de origen, es posible que generes artefactos implementables, como imágenes de contenedores o imágenes de sistemas operativos, o que personalices artefactos existentes, como imágenes de sistemas operativos de terceros, instalando y configurando software. La recopilación de información sobre cómo generas estos artefactos te ayuda a garantizar que los artefactos generados sean adecuados para la implementación enGoogle Cloud.

  • Almacena los artefactos. Si produces artefactos que almacenas en un registro de artefactos en tu entorno de origen, debes hacer que los artefactos estén disponibles en tu entorno de Google Cloud . Para ello, puedes emplear estrategias como las siguientes:

    • Establece un canal de comunicación entre los entornos: Haz que los artefactos de tu entorno de origen sean accesibles desde el entorno deGoogle Cloud destino.
    • Refactoriza el proceso de compilación de artefactos: Completa una refactorización menor de tu entorno de origen para que puedas almacenar artefactos tanto en el entorno de origen como en el de destino. Este enfoque respalda tu migración, ya que compila la infraestructura, como un repositorio de artefactos, antes de que debas implementar procesos de compilación de artefactos en el entorno de Google Clouddestino. Puedes implementar este enfoque directamente o basarte en el enfoque anterior de establecer primero un canal de comunicación.

    Tener artefactos disponibles en los entornos de origen y destino te permite enfocarte en la migración sin tener que implementar procesos de compilación de artefactos en el entorno de destino Google Cloud como parte de la migración.

  • Escanear y firmar el código Como parte de los procesos de compilación de artefactos, es posible que uses el análisis de código para protegerte contra vulnerabilidades comunes y la exposición no deseada a la red, y la firma de código para asegurarte de que solo se ejecute código de confianza en tus entornos.

  • Implementa artefactos en tu entorno de origen. Después de generar artefactos implementables, es posible que los implementes en tu entorno de origen. Te recomendamos que evalúes cada proceso de implementación. La evaluación ayuda a garantizar que tus procesos de implementación sean compatibles con Google Cloud. También te ayuda a comprender el esfuerzo que se necesitará para refactorizar los procesos con el tiempo. Por ejemplo, si tus procesos de implementación solo funcionan con tu entorno de origen, es posible que debas refactorizarlos para que se orienten a tu entorno de Google Cloud .

  • Incorpora la configuración del entorno de ejecución. Es posible que estés insertando una configuración del entorno de ejecución para clústeres, entornos de ejecución o implementaciones de cargas de trabajo específicos. La configuración puede inicializar variables de entorno y otros valores de configuración, como secretos, credenciales y claves. Para garantizar que los procesos de inserción de configuración del entorno de ejecución funcionen en Google Cloud, te recomendamos que evalúes cómo estás configurando las cargas de trabajo que se ejecutan en tu entorno de origen.

  • Registro, supervisión y generación de perfiles. Evalúa los procesos de registro, supervisión y generación de perfiles que tienes implementados para supervisar el estado de tu entorno de origen, las métricas de interés y cómo consumes los datos que proporcionan estos procesos.

  • Autenticación. Evalúa cómo te autenticas en tu entorno de origen.

  • Aprovisiona y configura tus recursos. Para preparar tu entorno de origen, es posible que hayas diseñado e implementado procesos que aprovisionen y configuren recursos. Por ejemplo, puedes usar Terraform junto con herramientas de administración de configuración para aprovisionar y configurar recursos en tu entorno de origen.

Completa la evaluación

Después de compilar los inventarios de tu entorno de AWS Lambda, completa el resto de las actividades de la fase de evaluación como se describe en Migra a Google Cloud: Evalúa y descubre tus cargas de trabajo.

Planifica y compila tu base

En la fase de planificación y compilación, aprovisionarás y configurarás la infraestructura para hacer lo siguiente:

  • Admitir tus cargas de trabajo en tu entorno de Google Cloud
  • Conecta tu entorno de origen y tu entorno de Google Cloud para completar la migración.

La fase de planificación y compilación se compone de las siguientes tareas:

  1. Compila una jerarquía de recursos.
  2. Configura Identity and Access Management (IAM) de Google Cloud.
  3. Configura la facturación.
  4. Configura la conectividad de red.
  5. Endurece tu seguridad.
  6. Configurar el registro, la supervisión y las alertas

Para obtener más información sobre cada una de estas tareas, consulta Migra a Google Cloud: Planifica y compila tu base.

Migra tus cargas de trabajo de AWS Lambda

Para migrar tus cargas de trabajo de AWS Lambda a Cloud Run, haz lo siguiente:

  1. Diseña, aprovisiona y configura tu entorno de Cloud Run.
  2. Si es necesario, refactoriza tus cargas de trabajo de AWS Lambda para que sean compatibles con Cloud Run.
  3. Refactoriza tus procesos operativos y de implementación para implementar y observar tus cargas de trabajo en Cloud Run.
  4. Migra los datos que necesitan tus cargas de trabajo de AWS Lambda.
  5. Valida los resultados de la migración en términos de funcionalidad, rendimiento y costo.

Para ayudarte a evitar problemas durante la migración y estimar el esfuerzo necesario para la migración, te recomendamos que evalúes cómo se comparan las funciones de AWS Lambda con las funciones similares de Cloud Run. Las funciones de AWS Lambda y Cloud Run pueden parecer similares cuando las comparas. Sin embargo, las diferencias en el diseño y la implementación de las funciones de los dos proveedores de servicios en la nube pueden tener efectos significativos en la migración de AWS Lambda a Cloud Run. Estas diferencias pueden influir en tus decisiones de diseño y refactorización, como se destaca en las siguientes secciones.

Diseña, aprovisiona y configura tu entorno de Cloud Run

El primer paso de la fase de migración es diseñar tu entorno de Cloud Run para que pueda admitir las cargas de trabajo que migras desde AWS Lambda.

Para diseñar correctamente tu entorno de Cloud Run, usa los datos que recopilaste durante la fase de evaluación sobre cada carga de trabajo de AWS Lambda. Estos datos te ayudan a hacer lo siguiente:

  1. Elige los recursos de Cloud Run adecuados para implementar tu carga de trabajo.
  2. Diseña la configuración de tus recursos de Cloud Run.
  3. Aprovisiona y configura los recursos de Cloud Run.

Elige los recursos de Cloud Run adecuados

Para cada carga de trabajo de AWS Lambda que desees migrar, elige el recurso de Cloud Run adecuado para implementar tus cargas de trabajo. Cloud Run admite los siguientes recursos principales:

  • Servicios de Cloud Run: Recurso que aloja un entorno de ejecución en contenedores, expone un extremo único y ajusta automáticamente la escala de la infraestructura subyacente según la demanda.
  • Trabajos de Cloud Run: Recurso que ejecuta uno o más contenedores hasta su finalización.

En la siguiente tabla, se resume cómo se asignan los recursos de AWS Lambda a estos recursos principales de Cloud Run:

Recurso de AWS Lambda Recurso de Cloud Run
Función de AWS Lambda que se activa por un evento, como los que se usan para sitios web y aplicaciones web, APIs y microservicios, procesamiento de datos de transmisión y arquitecturas controladas por eventos. Servicio de Cloud Run que puedes invocar con activadores.
Función de AWS Lambda que se programó para ejecutarse, como las de tareas en segundo plano y trabajos por lotes. Es un trabajo de Cloud Run que se ejecuta hasta su finalización.

Además de los servicios y los trabajos, Cloud Run proporciona recursos adicionales que extienden estos recursos principales. Para obtener más información sobre todos los recursos disponibles de Cloud Run, consulta el modelo de recursos de Cloud Run.

Diseña la configuración de tus recursos de Cloud Run

Antes de aprovisionar y configurar tus recursos de Cloud Run, debes diseñar su configuración. Algunas opciones de configuración de AWS Lambda, como los límites de recursos y los tiempos de espera de solicitudes, son comparables con opciones de configuración similares de Cloud Run. En las siguientes secciones, se describen las opciones de configuración disponibles en Cloud Run para los activadores de servicios y la ejecución de trabajos, la configuración de recursos y la seguridad. En estas secciones, también se destacan las opciones de configuración de AWS Lambda que son comparables con las de Cloud Run.

Activadores de servicios de Cloud Run y ejecución de trabajos

Los activadores de servicios y la ejecución de trabajos son las principales decisiones de diseño que debes tener en cuenta cuando migras tus cargas de trabajo de AWS Lambda. Cloud Run proporciona una variedad de opciones para activar y ejecutar las cargas de trabajo basadas en eventos que se usan en AWS Lambda. Además, Cloud Run proporciona opciones que puedes usar para cargas de trabajo de transmisión y trabajos programados.

Cuando migras tus cargas de trabajo, suele ser útil comprender primero qué activadores y mecanismos están disponibles en Cloud Run. Esta información te ayudará a comprender cómo funciona Cloud Run. Luego, puedes usar esta comprensión para determinar qué funciones de Cloud Run son comparables a las de AWS Lambda y cuáles se podrían usar cuando refactorices esas cargas de trabajo.

Para obtener más información sobre los activadores de servicios que proporciona Cloud Run, consulta los siguientes recursos:

Para obtener más información sobre los mecanismos de ejecución de trabajos que proporciona Cloud Run, consulta los siguientes recursos:

Para ayudarte a comprender qué mecanismos de invocación o ejecución de Cloud Run son comparables con los mecanismos de invocación de AWS Lambda, consulta la siguiente tabla. Para cada recurso de Cloud Run que necesites aprovisionar, asegúrate de elegir el mecanismo de invocación o ejecución correcto.

Función de AWS Lambda Función de Cloud Run
Activador HTTPS (URLs de funciones) Invocación HTTPS
Activador de HTTP/2 (parcialmente compatible con una puerta de enlace de API externa) Invocación de HTTP/2 (admite de forma nativa)
WebSockets (compatible con la puerta de enlace de API externa) WebSockets (compatible de forma nativa)
N/A (no se admiten las conexiones de gRPC) Conexiones de gRPC
Invocación asíncrona Integración en Cloud Tasks
Invocación programada Integración en Cloud Scheduler
Activador basado en eventos en un formato de evento propietario Invocación basada en eventos en formato de CloudEvents
Integración de Amazon SQS y Amazon SNS Integración en Pub/Sub
AWS Lambda Step Functions Integración de Workflows
Configuración de recursos de Cloud Run

Para complementar las decisiones de diseño que tomaste para activar y ejecutar tus cargas de trabajo migradas, Cloud Run admite varias opciones de configuración que te permiten ajustar varios aspectos del entorno de ejecución. Estas opciones de configuración constan de servicios y trabajos de recursos.

Como se mencionó anteriormente, puedes comprender mejor cómo funciona Cloud Run si primero entiendes todas las opciones de configuración disponibles en Cloud Run. Este conocimiento te ayudará a comparar las funciones de AWS Lambda con las funciones similares de Cloud Run y a determinar cómo refactorizar tus cargas de trabajo.

Para obtener más información sobre las configuraciones que proporcionan los servicios de Cloud Run, consulta los siguientes recursos:

Para obtener más información sobre los trabajos que proporciona Cloud Run, usa los siguientes recursos:

Para ayudarte a comprender qué opciones de configuración de Cloud Run son comparables con las de AWS Lambda, usa la siguiente tabla. Para cada recurso de Cloud Run que necesites aprovisionar, asegúrate de elegir las opciones de configuración correctas.

Función de AWS Lambda Función de Cloud Run
Simultaneidad aprovisionada Cantidad mínima de instancias
Simultaneidad reservada por instancia
(El grupo de simultaneidad se comparte entre las funciones de AWS Lambda en tu cuenta de AWS).		 Cantidad máxima de instancias por servicio
N/A (no admitido, una solicitud se asigna a una instancia) Solicitudes simultáneas por instancia
N/A (depende de la asignación de memoria) Asignación de CPU
Configuración de escalabilidad Ajuste de escala automático de instancias para servicios
Paralelismo para trabajos
Configuración de la instancia (CPU, memoria) Límites de CPU y memoria
Tiempo máximo de ejecución Tiempo de espera de la solicitud para los servicios
Tiempo de espera de la tarea para los trabajos
AWS Lambda SnapStart Aumento de CPU de inicio
Variables de entorno Variables de entorno
Almacenamiento de datos efímeros Activaciones de volúmenes en memoria
Conexiones de Amazon Elastic File System Activaciones de volúmenes de NFS
No se admiten las activaciones de volúmenes de S3 Activaciones de volúmenes de Cloud Storage
AWS Secrets Manager en cargas de trabajo de AWS Lambda Secrets
URLs de cargas de trabajo y extremos HTTP(S) URLs asignadas automáticamente
Integraciones de Cloud Run con Google Cloud productos
Sesiones persistentes (con un balanceador de cargas externo) Afinidad de sesión
Calificadores Revisiones

Además de las funciones que se enumeran en la tabla anterior, también debes tener en cuenta las diferencias entre la forma en que AWS Lambda y Cloud Run aprovisionan instancias del entorno de ejecución. AWS Lambda aprovisiona una sola instancia para cada solicitud simultánea. Sin embargo, Cloud Run te permite establecer la cantidad de solicitudes simultáneas que puede entregar una instancia. Es decir, el comportamiento de aprovisionamiento de AWS Lambda equivale a establecer la cantidad máxima de solicitudes simultáneas por instancia en 1 en Cloud Run. Establecer la cantidad máxima de solicitudes simultáneas en más de 1 puede ahorrar costos de manera significativa, ya que las solicitudes simultáneas comparten la CPU y la memoria de la instancia, pero solo se facturan una vez. La mayoría de los frameworks HTTP están diseñados para controlar solicitudes en paralelo.

Seguridad y control de acceso de Cloud Run

Cuando diseñes tus recursos de Cloud Run, también deberás decidir qué controles de seguridad y acceso necesitas para tus cargas de trabajo migradas. Cloud Run admite varias opciones de configuración para ayudarte a proteger tu entorno y establecer roles y permisos para tus cargas de trabajo de Cloud Run.

En esta sección, se destacan los controles de seguridad y acceso disponibles en Cloud Run. Esta información te ayuda a comprender cómo funcionarán tus cargas de trabajo migradas en Cloud Run y a identificar las opciones de Cloud Run que podrías necesitar si refactorizas esas cargas de trabajo.

Para obtener más información sobre los mecanismos de autenticación que proporciona Cloud Run, consulta los siguientes recursos:

Para obtener más información sobre las funciones de seguridad que proporciona Cloud Run, consulta los siguientes recursos:

Para ayudarte a comprender qué controles de seguridad y acceso de Cloud Run son comparables con los que están disponibles en AWS Lambda, usa la siguiente tabla. Para cada recurso de Cloud Run que necesites aprovisionar, asegúrate de elegir los controles de acceso y las funciones de seguridad adecuados.

Función de AWS Lambda Función de Cloud Run
Control de acceso con la administración de identidades y acceso de AWS Control de acceso con la IAM de Google Cloud
Rol de ejecución Rol de IAM deGoogle Cloud
Límites de permisos Google Cloud's permisos de IAM y públicos personalizados
Controles de administración Servicio de políticas de la organización
Firma de código Autorización binaria
Acceso completo a la VPC Controles detallados de acceso de salida de VPC

Aprovisiona y configura recursos de Cloud Run

Después de elegir los recursos de Cloud Run para implementar tus cargas de trabajo, debes aprovisionar y configurar esos recursos. Para obtener más información sobre el aprovisionamiento de recursos de Cloud Run, consulta lo siguiente:

Refactoriza las cargas de trabajo de AWS Lambda

Para migrar tus cargas de trabajo de AWS Lambda a Cloud Run, es posible que debas refactorizarlas. Por ejemplo, si una carga de trabajo basada en eventos acepta activadores que contienen eventos de Amazon CloudWatch, es posible que debas refactorizar esa carga de trabajo para que acepte eventos en el formato de CloudEvents.

Hay varios factores que pueden influir en la cantidad de refactorización que necesitas para cada carga de trabajo de AWS Lambda, como los siguientes:

  • Arquitectura. Considera cómo se diseñó la carga de trabajo en términos de arquitectura. Por ejemplo, las cargas de trabajo de AWS Lambda que separaron claramente la lógica empresarial de la lógica para acceder a las APIs específicas de AWS podrían requerir menos refactorización en comparación con las cargas de trabajo en las que se mezclan las dos lógicas.
  • Idempotencia. Considera si la carga de trabajo es idempotente en relación con sus entradas. Una carga de trabajo que es idempotente para las entradas podría requerir menos refactorización en comparación con las cargas de trabajo que necesitan mantener el estado sobre qué entradas ya procesaron.
  • Estado. Considera si la carga de trabajo no tiene estado. Una carga de trabajo sin estado podría requerir menos refactorización en comparación con las cargas de trabajo que mantienen el estado. Para obtener más información sobre los servicios que admite Cloud Run para almacenar datos, consulta Opciones de almacenamiento de Cloud Run.
  • Entorno de ejecución Considera si la carga de trabajo hace alguna suposición sobre su entorno de ejecución. Para estos tipos de cargas de trabajo, es posible que debas satisfacer los mismos supuestos en el entorno de ejecución de Cloud Run o refactorizar la carga de trabajo si no puedes suponer lo mismo para el entorno de ejecución de Cloud Run. Por ejemplo, si una carga de trabajo requiere que ciertos paquetes o bibliotecas estén disponibles, debes instalarlos en el entorno de ejecución de Cloud Run que alojará esa carga de trabajo.
  • Inyección de configuración. Considera si la carga de trabajo admite el uso de variables de entorno y secretos para insertar (establecer) su configuración. Una carga de trabajo que admite este tipo de inserción podría requerir menos refactorización en comparación con las cargas de trabajo que admiten otros mecanismos de inserción de configuración.
  • APIs. Considera si la carga de trabajo interactúa con las APIs de AWS Lambda. Es posible que se deba refactorizar una carga de trabajo que interactúa con estas APIs para usar las API de Cloud y las APIs de Cloud Run.
  • Error Reporting Considera si la carga de trabajo informa errores con flujos de salida y error estándar. Una carga de trabajo que realiza este tipo de informes de errores puede requerir menos refactorización en comparación con las cargas de trabajo que informan errores con otros mecanismos.

Para obtener más información sobre el desarrollo y la optimización de cargas de trabajo de Cloud Run, consulta los siguientes recursos:

Refactoriza los procesos operativos y de implementación

Después de refactorizar tus cargas de trabajo, refactoriza tus procesos operativos y de implementación para que realicen las siguientes acciones:

  • Aprovisiona y configura recursos en tu entorno de Google Cloud en lugar de aprovisionar recursos en tu entorno de origen.
  • Compila y configura cargas de trabajo, y luego impleméntalas en tu Google Clouden lugar de implementarlas en tu entorno de origen.

Recopilaste información sobre estos procesos durante la fase de evaluación antes en este proceso.

El tipo de refactorización que debes considerar para estos procesos depende de cómo los diseñaste y cómo los implementaste. La refactorización también depende de cuál sea el estado final de cada proceso. Por ejemplo, considera lo siguiente:

  • Es posible que hayas implementado estos procesos en tu entorno de origen y quieras diseñar e implementar procesos similares en Google Cloud. Por ejemplo, puedes refactorizar estos procesos para usar Cloud Build, Cloud Deploy y Infrastructure Manager.
  • Es posible que hayas implementado estos procesos en otro entorno de terceros fuera de tu entorno de origen. En este caso, debes refactorizar estos procesos para orientar tu entorno de Google Cloud en lugar de tu entorno de origen.
  • Una combinación de los enfoques anteriores.

La refactorización de los procesos operativos y de implementación puede ser complejo y puede requerir un esfuerzo significativo. Si intentas realizar estas tareas como parte de la migración de tu carga de trabajo, la migración puede volverse más compleja y exponerte a riesgos. Después de evaluar los procesos operativos y de implementación, es probable que comprendas el diseño y la complejidad. Si estimas que necesitas un esfuerzo sustancial para refactorizar tus procesos operativos y de implementación, te recomendamos que consideres la refactorización de estos procesos como parte de un proyecto independiente y dedicado.

Para obtener más información sobre cómo diseñar e implementar procesos de implementación en Google Cloud, consulta los siguientes recursos:

Este documento se enfoca en los procesos de implementación que producen los artefactos para implementar y los implementan en el entorno de ejecución de destino. La estrategia de refactorización depende en gran medida de la complejidad de estos procesos. En la siguiente lista, se describe una posible estrategia general de refactorización:

  1. Aprovisiona repositorios de artefactos en Google Cloud. Por ejemplo, puedes usar Artifact Registry para almacenar artefactos y compilar dependencias.
  2. Refactoriza tus procesos de compilación para almacenar artefactos tanto en tu entorno de origen como en Artifact Registry.
  3. Refactoriza tus procesos de implementación para implementar tus cargas de trabajo en tu entorno deGoogle Cloud destino. Por ejemplo, puedes comenzar por implementar un pequeño subconjunto de tus cargas de trabajo en Google Cloud, usando artefactos almacenados en Artifact Registry. Luego, aumenta gradualmente la cantidad de cargas de trabajo implementadas en Google Cloudhasta que todas las cargas de trabajo que se migrarán se ejecuten enGoogle Cloud.
  4. Refactoriza tus procesos de compilación para almacenar artefactos solo en Artifact Registry.
  5. Si es necesario, migra las versiones anteriores de los artefactos que se implementarán desde los repositorios de tu entorno de origen a Artifact Registry. Por ejemplo, puedes copiar imágenes de contenedor en Artifact Registry.
  6. Inhabilita los repositorios en tu entorno de origen cuando ya no los necesites.

Para facilitar las reversiones eventuales debido a problemas imprevistos durante la migración, puedes almacenar imágenes de contenedor en tus repositorios de artefactos actuales en Google Cloud mientras la migración a Google Cloud está en curso. Por último, como parte de la baja de tu entorno de origen, puedes refactorizar tus procesos de compilación de imágenes de contenedor para almacenar artefactos solo enGoogle Cloud .

Aunque no sea crucial para el éxito de una migración, es posible que debas migrar las versiones anteriores de tus artefactos desde tu entorno de origen a tus repositorios de artefactos en Google Cloud. Por ejemplo, para admitir la reversión de tus cargas de trabajo a puntos arbitrarios en el tiempo, es posible que debas migrar versiones anteriores de tus artefactos a Artifact Registry. Para obtener más información, consulta Cómo migrar imágenes desde un registro de terceros.

Si usas Artifact Registry para almacenar tus artefactos, te recomendamos que configures controles para proteger tus repositorios de artefactos, como el control de acceso, la prevención de robo de datos, el análisis de vulnerabilidades y la autorización binaria. Para obtener más información, consulta Controla el acceso y protege los artefactos.

Refactoriza los procesos operativos

Como parte de la migración a Cloud Run, te recomendamos que refactorices tus procesos operativos para supervisar de forma constante y eficaz tu entorno de Cloud Run.

Cloud Run se integra con los siguientes servicios operativos:

Migrar datos

La fase de evaluación que se realizó anteriormente en este proceso debería haberte ayudado a determinar si las cargas de trabajo de AWS Lambda que migras dependen de los datos que residen en tu entorno de AWS o los producen. Por ejemplo, es posible que hayas determinado que necesitas migrar datos de AWS S3 a Cloud Storage, o de Amazon RDS y Aurora a Cloud SQL y AlloyDB para PostgreSQL. Para obtener más información sobre la migración de datos de AWS aGoogle Cloud, consulta Migra de AWS a Google Cloud: Comienza ahora.

Al igual que con la refactorización de los procesos operativos y de implementación, la migración de datos de AWS a Google Cloud puede ser compleja y requerir un esfuerzo significativo. Si intentas realizar estas tareas de migración de datos como parte de la migración de tus cargas de trabajo de AWS Lambda, la migración puede volverse compleja y exponerte a riesgos. Después de analizar los datos que se migrarán, es probable que comprendas el tamaño y la complejidad de los datos. Si estimas que necesitas un esfuerzo sustancial para migrar estos datos, te recomendamos que consideres la migración de datos como parte de un proyecto independiente y dedicado.

Valida los resultados de la migración

La validación de la migración de tu carga de trabajo no es un evento único, sino un proceso continuo. Debes mantener el enfoque en las pruebas y la validación antes, durante y después de migrar de AWS Lambda a Cloud Run.

Para garantizar una migración exitosa con un rendimiento óptimo y la menor cantidad de interrupciones posible, te recomendamos que uses el siguiente proceso para validar las cargas de trabajo que migrarás de AWS Lambda a Cloud Run:

  • Antes de comenzar la fase de migración, refactoriza tus casos de prueba existentes para tener en cuenta el entorno de Google Cloud destino.
  • Durante la migración, valida los resultados de las pruebas en cada hito de migración y realiza pruebas de integración exhaustivas.
  • Después de las migraciones, realiza las siguientes pruebas:
    • Pruebas de referencia: Establece comparativas de rendimiento de la carga de trabajo original en AWS Lambda, como el tiempo de ejecución, el uso de recursos y los porcentajes de errores con diferentes cargas. Replica estas pruebas en Cloud Run para identificar discrepancias que podrían indicar problemas de migración o configuración.
    • Pruebas funcionales: Asegúrate de que la lógica principal de tus cargas de trabajo siga siendo coherente creando y ejecutando casos de prueba que abarquen diversas situaciones de entrada y salida esperadas en ambos entornos.
    • Pruebas de carga: Aumenta el tráfico de forma gradual para evaluar el rendimiento y la escalabilidad de Cloud Run en condiciones reales. Para garantizar una migración sin inconvenientes, aborda las discrepancias, como los errores y las limitaciones de recursos.

Optimiza tu entorno de Google Cloud

La optimización es la última fase de la migración. En esta fase, iteras en tareas de optimización hasta que tu entorno de destino cumpla con tus requisitos de optimización. Los pasos de cada iteración son los siguientes:

  1. Evalúa tu entorno actual, los equipos y el ciclo de optimización.
  2. Establece tus requisitos y objetivos de optimización.
  3. Optimiza el entorno y los equipos.
  4. Ajustar el bucle de optimización

Repite esta secuencia hasta que hayas alcanzado tus objetivos de optimización.

Para obtener más información sobre la optimización de tu entorno de Google Cloud , consulta Migra a Google Cloud: Optimiza tu entorno y Google Cloud Well-Architected Framework: Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: