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 servidor de Amazon Web Services (AWS) Lambda 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 migrar a Cloud Run, un entorno de tiempo de ejecución sin servidores. AWS Lambda y Cloud Run comparten similitudes, como el aprovisionamiento automático de recursos, el escalamiento del proveedor de servicios en la nube y un modelo de precios de pago por uso.

En este documento, encontrarás ayuda para diseñar, implementar y validar un plan para migrar cargas de trabajo sin servidor 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 es parte de 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 servidor adecuado para tu lógica empresarial, consulta Selecciona un entorno de ejecución de contenedor administrado. Para obtener un mapeo integral entre los servicios de AWS y Google Cloud , consulta compara los servicios de AWS y Azure con los Google Cloud servicios.

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 Google Cloud entorno.

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 a menudo se extiende más allá de simplemente mover funciones de un proveedor de servicios en la nube a otro. Debido a que las aplicaciones basadas en la nube dependen de una red de servicios interconectados, migrar de AWS a Google Cloud podría requerir reemplazar los servicios de AWS dependientes 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 adaptar Pub/Sub y Cloud Tasks para lograr una funcionalidad similar.

La migración también te brinda una oportunidad valiosa para revisar en detalle 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 de Google Cloud ofrecen ventajas únicas o se alinean mejor con los requisitos de tu aplicación.
  • Simplifica tu arquitectura: Evalúa si es posible optimizar la consolidación de la funcionalidad o el uso de servicios de manera diferente dentro deGoogle Cloud.
  • Mejora la eficiencia de 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 rehosting (lift and shift). Aprovecha la migración como una oportunidad 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 sobre 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 compilar 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 fricciones. Además, analiza esa carga de trabajo para comprender cómo podrías necesitar 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 las salidas
  • El entorno de ejecución y los entornos de ejecución
  • La configuración de la carga de trabajo
  • Los controles de acceso y los permisos
  • Los requisitos de cumplimiento y reglamentarios
  • 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 que entrega la carga de trabajo y 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

Hacer un inventario del 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. Crear 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 esencial para tus procesos de DevOps, como las canalizaciones de integración y desarrollo continuos (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 ayudará 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
  • Cualquier extensión de AWS Lambda de la que dependa la carga de trabajo
  • Los calificadores que configuraste para especificar versiones y alias
  • La versión de la carga de trabajo implementada

Invocación, activadores y salidas

AWS Lambda admite varios mecanismos de invocación, como 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:

  • Los activadores y las asignaciones de fuentes de eventos que invocan la carga de trabajo
  • Si la carga de trabajo admite invocaciones síncronas y asíncronas.
  • Las URLs de la carga de trabajo y los extremos HTTP(S)

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 esos recursos consumen esos resultados. 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:

  • Los recursos de destino a los que la carga de trabajo podría enviar eventos.
  • Los destinos que reciben registros de información para invocaciones asíncronas
  • Es el formato de los eventos que procesa la carga de trabajo.
  • Cómo tu carga de trabajo de AWS Lambda y sus extensiones interactúan 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:

  • 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, como el uso de almacenamiento de datos efímeros y Amazon Elastic File System (EFS).

Entornos de ejecución y 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:

  • El entorno de ejecución de la carga de trabajo.
  • 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 tiempo de ejecución específicos del lenguaje, ten en cuenta lo siguiente para cada carga de trabajo de AWS Lambda:

  • El tipo, la versión y el identificador único del entorno de ejecución específico del lenguaje
  • Cualquier modificación que hayas aplicado 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 la siguiente configuración de escalabilidad y simultaneidad:

  • Los controles de simultaneidad
  • La configuración de escalabilidad
  • 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.
  • 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
  • La máquina de estado para controlar condiciones excepcionales
  • 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 de acceso y permisos

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 administración y controles 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:

  • El rol de ejecución y los permisos
  • La configuración de administración de identidades y accesos que la carga de trabajo y sus capas usan para acceder a otros recursos.
  • 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 gobernanza

Requisitos de cumplimiento y reglamentarios

Para cada carga de trabajo de AWS Lambda, asegúrate de comprender sus requisitos de cumplimiento y regulatorios. Para ello, haz lo siguiente:

  • Evalúa los requisitos normativos y de cumplimiento que debe cumplir la carga de trabajo.
  • Determina si la carga de trabajo cumple con estos requisitos en la actualidad.
  • Determina si hay algún requisito futuro que se deba cumplir.

Los requisitos de cumplimiento y reglamentarios pueden ser independientes del proveedor de servicios en la nube que usas, 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 geografías, 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 podrían 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 cualquier otro elemento.

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

  • Desarrolla tus cargas de trabajo. Evalúa los procesos que los equipos de desarrollo tienen implementados 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 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 en el entorno de origen y en el de destino. Este enfoque admite tu migración, ya que compila la infraestructura como un repositorio de artefactos antes de que tengas que implementar procesos de compilación de artefactos en el entorno Google Cloudde destino. Puedes implementar este enfoque directamente o basarte en el enfoque anterior de establecer un canal de comunicación primero.

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

  • Escanea y firma 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 de red no deseada, y la firma de código para garantizar 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 orientarlos 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:

  • Admite tus cargas de trabajo en tu entorno de Google Cloud .
  • Conectar 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 la administración de identidades y accesos (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 construye 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 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 admita las cargas de trabajo que migrarás 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 correctos 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 quieras migrar, elige el recurso de Cloud Run adecuado para implementarlas. Cloud Run admite los siguientes recursos principales:

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

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

Recurso de AWS Lambda Recurso de Cloud Run
Es una función de AWS Lambda que se activa a través de un evento, como los que se usan para sitios web y aplicaciones web, APIs y microservicios, procesamiento de datos de transmisión continua y arquitecturas basadas en eventos. Es un servicio de Cloud Run que puedes invocar con activadores.
Una función de AWS Lambda que se programó para ejecutarse, como las de tareas en segundo plano y trabajos por lotes 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 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 las solicitudes, son comparables con opciones de configuración similares de Cloud Run. En las siguientes secciones, se describen las opciones de configuración que está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 y ejecución de trabajos de Cloud Run

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 transmitir cargas de trabajo y trabajos programados.

Cuando migras tus cargas de trabajo, a menudo es ú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 información para determinar qué funciones de Cloud Run son comparables con 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 servicio que proporciona Cloud Run, usa los siguientes recursos:

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

Para ayudarte a comprender qué mecanismos de invocación o ejecución de Cloud Run son comparables a los mecanismos de invocación de AWS Lambda, usa 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 Atributo de Cloud Run
Activador HTTPS (URLs de la función) Invocación HTTPS
Activador HTTP/2 (se admite de forma parcial con una puerta de enlace de API externa) Invocación de HTTP/2 (compatible de forma nativa)
WebSockets (compatibles con la puerta de enlace de API externa) WebSockets (compatibles de forma nativa)
N/A (no se admiten conexiones de gRPC) Conexiones de gRPC
Invocación asíncrona Integración de Cloud Tasks
Invocación programada Integración de 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 Step Functions de AWS Lambda Integración de flujos de trabajo
Configuración de recursos de Cloud Run

Para complementar las decisiones de diseño que tomaste para activar y ejecutar las 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 consisten en servicios y trabajos de recursos.

Como se mencionó anteriormente, para comprender mejor cómo funciona Cloud Run, primero debes comprender todas las opciones de configuración que están disponibles en Cloud Run. Esta comprensión te ayudará a comparar las funciones de AWS Lambda con 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, usa 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 provisionar, asegúrate de elegir las opciones de configuración correctas.

Función de AWS Lambda Atributo 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 se admite, 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 y 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 volumen de S3. Activaciones de volúmenes de Cloud Storage
AWS Secrets Manager en cargas de trabajo de AWS Lambda Secrets
URLs de la carga 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 considerar 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 configurar 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. Configurar 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 los controles de seguridad y acceso que 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 que están 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, usa los siguientes recursos:

Para obtener más información sobre las funciones de seguridad que proporciona Cloud Run, usa 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 correctos.

Función de AWS Lambda Atributo de Cloud Run
Control de acceso con el acceso y la administración de identidades de AWS Control de acceso con la IAM de Google Cloud
Rol de ejecución Rol de IAM deGoogle Cloud
Límites de permisos Permisos de IAM y públicos personalizados deGoogle Cloud
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 los recursos de Cloud Run

Después de elegir los recursos de Cloud Run para implementar tus cargas de trabajo, debes aprovisionarlos y configurarlos. Para obtener más información sobre el aprovisionamiento de recursos de Cloud Run, consulta los siguientes vínculos:

Refactoriza las cargas de trabajo de AWS Lambda

Para migrar tus cargas de trabajo de AWS Lambda a Cloud Run, es posible que necesites 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.

Existen 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 idempotente para las entradas podría requerir menos refactorización en comparación con las cargas de trabajo que necesitan mantener el estado sobre las entradas que ya procesaron.
  • Estado. Considera si la carga de trabajo es sin 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 las mismas suposiciones 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 (configurar) su configuración. Una carga de trabajo que admita 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 una carga de trabajo que interactúa con estas APIs deba refactorizarse para usar las APIs de Cloud y las APIs de Cloud Run.
  • Informe de errores. Considera si la carga de trabajo informa errores con flujos de salida y error estándar. Una carga de trabajo que genera ese 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 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 hacerlo 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 del 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 vínculos:

En este documento, se enfocan los procesos de implementación que producen los artefactos para implementarlos y, luego, implementarlos 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 en tu ambiente de origen y en Artifact Registry.
  3. Refactorizar tus procesos de implementación para implementar tus cargas de trabajo en tu entorno deGoogle Cloud de destino Por ejemplo, puedes comenzar por implementar un subconjunto pequeño de tus cargas de trabajo en Google Cloud, con artefactos almacenados en Artifact Registry. Luego, aumentas gradualmente la cantidad de cargas de trabajo implementadas en Google Cloud, hasta que todas las cargas de trabajo que se migrarán se ejecuten en Google 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 para implementarlos desde los repositorios de tu entorno de origen a Artifact Registry. Por ejemplo, puedes kopy las imágenes de contenedor a Artifact Registry.
  6. Inhabilita los repositorios de tu entorno de origen cuando ya no los necesites.

Para facilitar las posibles reversiones debido a problemas imprevistos durante la migración, puedes almacenar imágenes de contenedores 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 los procesos de compilación de imágenes de contenedor para almacenar artefactos solo en Google Cloud .

Aunque es posible que no sea fundamental 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 las 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 ayudarte a 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 en los siguientes servicios operativos:

Migrar datos

La fase de evaluación anterior en este proceso debería haberte ayudado a determinar si las cargas de trabajo de AWS Lambda que migras dependen de datos que residen en tu entorno de AWS o si producen datos que residen en tu entorno de AWS. 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 cómo migrar datos de AWS aGoogle Cloud, consulta Cómo migrar de AWS a Google Cloud: Comienza ahora.

Al igual que con la refactorización de los procesos operativos y de implementación, migrar datos de AWS a Google Cloud puede ser complejo 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 deseas migrar, 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 migrar los 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 que la migración se complete correctamente con un rendimiento óptimo y mínimas interrupciones, 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 Google Cloud de destino.
  • Durante la migración, valida los resultados de las pruebas en cada hito de la 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 las tasas de error en 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. Para ello, crea y ejecuta casos de prueba que abarquen varias situaciones de entrada y salida esperadas en ambos entornos.
    • Pruebas de carga: Aumenta gradualmente el tráfico para evaluar el rendimiento y la escalabilidad de Cloud Run en condiciones reales. Para garantizar una migración sin inconvenientes, aborda las discrepancias, como errores y limitaciones de recursos.

Optimiza tu Google Cloud entorno

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 cómo optimizar tu entorno de Google Cloud , consulta Migra a Google Cloud: Optimiza tu entorno y Marco de trabajo de la arquitectura deGoogle Cloud : Optimización del rendimiento.

¿Qué sigue?

Colaboradores

Autores:

Otros colaboradores: