Migrar de AWS a Google Cloud: migrar de AWS Lambda a Cloud Run

Last reviewed 2024-10-21 UTC

Google Cloud ofrece herramientas, productos, guías y servicios profesionales para ayudar a migrar cargas de trabajo sin servidor de Amazon Web Services (AWS) Lambda a Google Cloud. Aunque Google Cloud proporciona varios servicios en los que puedes desarrollar y desplegar aplicaciones sin servidor, este documento se centra en la migración a Cloud Run, un entorno de ejecución sin servidor. Tanto AWS Lambda como Cloud Run comparten similitudes, como el aprovisionamiento automático de recursos, el escalado por parte del proveedor de 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 servidor de AWS Lambda a Cloud Run. Además, ofrece orientación a quienes estén evaluando las posibles ventajas y el proceso de una migración de este tipo.

Este documento forma parte de una serie de artículos 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 tiempo de ejecución sin servidor adecuado para tu lógica empresarial, consulta Seleccionar un entorno de tiempo de ejecución de contenedor gestionado. Para ver una asignación completa entre los servicios de AWS y Google Cloud , consulta la comparación de los servicios de AWS y Azure con los servicios de Google Cloud .

Para llevar a cabo esta migración a Google Cloud, te recomendamos que sigas el framework de migración descrito en el artículo Migrar a Google Cloud: primeros pasos.

En el siguiente diagrama se muestra el 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 adelante. En cada iteración de migración independiente, debes seguir las fases del marco de migración general:

  1. Evalúa e identifica tus cargas de trabajo y datos.
  2. Planifica y construye una base sobre 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 marco, consulta el artículo Migrar a Google Cloud: primeros pasos.

Para diseñar un plan de migración eficaz, te recomendamos que valides cada paso del plan y que tengas una estrategia de restauración. Para validar tu plan de migración, consulta el artículo Migrar a Google Cloud: prácticas recomendadas para validar un plan de migración.

La migración de cargas de trabajo sin servidor suele ir más allá de mover funciones de un proveedor de servicios en la nube a otro. Como las aplicaciones basadas en la nube dependen de una red interconectada de servicios, migrar de AWS a Google Cloud puede requerir la sustitución de los servicios de AWS dependientes por servicios de Google Cloud . Por ejemplo, supongamos que tu función Lambda interactúa con Amazon SQS y Amazon SNS. Para migrar esta función, probablemente tengas que adoptar Pub/Sub y Cloud Tasks para conseguir una funcionalidad similar.

La migración también te ofrece una oportunidad valiosa para revisar a fondo la arquitectura y las decisiones de diseño de tu aplicación sin servidor. Gracias a esta revisión, puede descubrir oportunidades para hacer lo siguiente:

  • Optimiza con Google Cloud funciones integradas: descubre si losGoogle Cloud servicios ofrecen ventajas únicas o se ajustan mejor a los requisitos de tu aplicación.
  • Simplifica tu arquitectura: evalúa si es posible optimizarla consolidando funciones o usando los servicios de forma diferente enGoogle Cloud.
  • Mejorar la rentabilidad: evalúa las posibles diferencias de costes de ejecutar tu aplicación refactorizada en la infraestructura que se proporciona en Google Cloud.
  • Mejorar la eficiencia del código: refactoriza el código durante el proceso de migración.

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

Evaluar el entorno de origen

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

La fase de evaluación es fundamental para que la migración se lleve a cabo correctamente. Debes conocer en profundidad las cargas de trabajo que quieres migrar, sus requisitos, sus dependencias y tu entorno actual. Para planificar y llevar a cabo una migración correctamente, debes conocer tu punto de partida. Google Cloud

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

  1. Crea un inventario completo de tus cargas de trabajo.
  2. Cataloga tus cargas de trabajo según sus propiedades y dependencias.
  3. Forma y educa a tus equipos sobre Google Cloud.
  4. Crea experimentos y pruebas de concepto en Google Cloud.
  5. Calcula el coste total de propiedad (CTP) del entorno de destino.
  6. Elige la estrategia de migración de tus cargas de trabajo.
  7. Elige las herramientas de migración.
  8. Define el plan y la cronología de la 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 el artículo Migración a Google Cloud: evaluar e identificar cargas de trabajo. Las siguientes secciones se basan en la información de ese documento.

Crear un inventario de tus cargas de trabajo de AWS Lambda

Para definir el ámbito de la migración, crea un inventario y recoge 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 recogida de datos basado en las APIs de AWS, las herramientas para desarrolladores de AWS y la interfaz de línea de comandos de AWS.

Una vez que haya creado su inventario, le recomendamos que recopile información sobre cada carga de trabajo de AWS Lambda del inventario. En cada carga de trabajo, céntrate en los aspectos que te ayuden a anticipar posibles problemas. Además, analiza esa carga de trabajo para saber cómo tendrás que modificarla y sus dependencias antes de migrar a Cloud Run. Te recomendamos que empieces recogiendo datos sobre los siguientes aspectos de cada carga de trabajo de AWS Lambda:

  • El caso práctico y el diseño
  • El repositorio de código fuente
  • Los artefactos de implementación
  • La invocación, los activadores y las salidas
  • Entornos de ejecución y de tiempo de ejecución
  • La configuración de la carga de trabajo
  • Los controles y permisos de acceso
  • Los requisitos normativos y de cumplimiento
  • Los procesos de implementación y operativos

Caso práctico y diseño

Recopilar información sobre el caso práctico 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 determinar si tienes que 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 información valiosa sobre el caso práctico específico al que sirve la carga de trabajo e 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 de código fuente

Hacer un inventario del código fuente de tus funciones de AWS Lambda te ayudará si necesitas refactorizar tus cargas de trabajo de AWS Lambda para que sean compatibles con Cloud Run. Para crear este inventario, se debe hacer un seguimiento de la base de código, que suele almacenarse en sistemas de control de versiones 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 los flujos de procesamiento 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 despliegue

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

  • El tipo de paquete de implementación para desplegar 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 cualificadores que ha configurado para especificar versiones y alias.
  • Versión de la carga de trabajo desplegada.

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 asíncrona. En 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 origen de eventos que invocan la carga de trabajo.
  • Indica si la carga de trabajo admite invocaciones síncronas y asíncronas.
  • Las URLs de la carga de trabajo y los endpoints 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 lo hacen. Esta información te ayuda a determinar si tienes que modificar algo que pueda depender de esos resultados, como otros sistemas o cargas de trabajo. En 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 puede enviar eventos la carga de trabajo.
  • Los destinos que reciben registros de información de invocaciones asíncronas.
  • 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 u otras APIs de AWS.

Para funcionar, es posible que tus cargas de trabajo de AWS Lambda almacenen datos persistentes e interactúen con otros servicios de AWS. En el caso de 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 (VPCs) u otras redes privadas.
  • Cómo almacena datos persistentes la carga de trabajo, por ejemplo, mediante el almacenamiento de datos efímeros y Amazon Elastic File System (EFS).

Entornos 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 del ordenador en el 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 de un 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 tiempo de ejecución específico del idioma.
  • Cualquier modificación que hayas aplicado al entorno de ejecución.

Configuración de 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 has configurado cada carga de trabajo de AWS Lambda.

Para cada carga de trabajo de AWS Lambda, recopila información sobre los siguientes ajustes de simultaneidad y escalabilidad:

  • Los controles de simultaneidad.
  • Los ajustes 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, concurrencia reservada o concurrencia aprovisionada para reducir la latencia.
  • Las variables de entorno que has configurado, 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 estados para gestionar condiciones excepcionales.
  • Las imágenes base y los archivos de configuración (como Dockerfile) de los paquetes de implementación que usan imágenes de contenedor.

Controles y permisos de acceso

Como parte de la evaluación, le recomendamos que evalúe los requisitos de seguridad de sus cargas de trabajo de AWS Lambda y su configuración en términos de controles de acceso y gestión. Esta información es fundamental si necesitas implementar controles similares en tu entorno de Google Cloud . En cada carga de trabajo, ten en cuenta lo siguiente:

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

En cada carga de trabajo de AWS Lambda, asegúrate de que conoces sus requisitos de cumplimiento y normativos haciendo lo siguiente:

  • Evalúa los requisitos de cumplimiento y normativos que debe cumplir la carga de trabajo.
  • Determina si la carga de trabajo cumple estos requisitos.
  • Determina si hay requisitos futuros que deban cumplirse.

Los requisitos de cumplimiento y normativos pueden ser independientes del proveedor de la nube que utilices, y estos requisitos también pueden afectar a la migración. Por ejemplo, puede que tengas que asegurarte de que los datos y el tráfico de red permanezcan dentro de los límites de determinadas zonas geográficas, como la Unión Europea (UE).

Evalúa tus procesos de implementación y operativos

Es importante que tengas claro cómo funcionan tus procesos de implementación y operativos. Estos procesos 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 en él.

Tus procesos de implementación y operativos pueden crear los artefactos que necesitan tus cargas de trabajo para funcionar. Por lo tanto, debes recoger información sobre cada tipo de artefacto. Por ejemplo, un artefacto puede ser un paquete de sistema operativo, un paquete de despliegue de aplicaciones, una imagen de sistema operativo, una imagen de contenedor u otro elemento.

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

  • Desarrolla tus cargas de trabajo. Evalúa los procesos que tienen los equipos de desarrollo para crear tus cargas de trabajo. Por ejemplo, ¿cómo diseñan, codifican y prueban tus equipos de desarrollo las cargas de trabajo?
  • Genera los artefactos que vas a implementar en tu entorno de origen. Para implementar tus cargas de trabajo en el entorno de origen, puedes generar artefactos implementables, como imágenes de contenedor o imágenes de sistema operativo, o personalizar artefactos, como imágenes de sistema operativo de terceros, instalando y configurando software. Recopilar información sobre cómo generas estos artefactos te ayuda a asegurarte de que sean adecuados para implementarlos enGoogle Cloud.

  • Almacena los artefactos. Si produces artefactos que almacenas en un registro de artefactos de tu entorno de origen, debes hacer que estén disponibles en tu entorno de destino. 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 de destino.Google Cloud
    • Refactorizar 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 facilita la migración, ya que crea una infraestructura, como un repositorio de artefactos, antes de que tengas que implementar procesos de compilación de artefactos en el entorno de destino Google Cloud. Puedes implementar este enfoque directamente o basarte en el enfoque anterior de establecer primero un canal de comunicación.

    Si los artefactos están disponibles tanto en el entorno de origen como en el de destino, puedes centrarte 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 código. Como parte de los procesos de compilación de artefactos, puedes usar el análisis de código para protegerte frente a vulnerabilidades comunes y exposiciones de red no deseadas, así como la firma de código para asegurarte de que solo se ejecute código de confianza en tus entornos.

  • Despliega 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 asegurar que tus procesos de implementación sean compatibles con Google Cloud. También te ayuda a entender el esfuerzo que será necesario para refactorizar los procesos. Por ejemplo, si tus procesos de implementación solo funcionan con tu entorno de origen, es posible que tengas que refactorizarlos para que se dirijan a tu entorno de Google Cloud .

  • Inyectar configuración de tiempo de ejecución. Puede que estés insertando una configuración de tiempo de ejecución para clústeres, entornos de tiempo 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 asegurarte de que los procesos de inyección de configuración de tiempo de ejecución funcionan en Google Cloud, te recomendamos que evalúes cómo configuras las cargas de trabajo que se ejecutan en tu entorno de origen.

  • Registro, monitorización y creación de perfiles. Evalúa los procesos de registro, monitorización y creación de perfiles que tienes implementados para monitorizar el estado de tu entorno de origen, las métricas de interés y cómo consumes los datos proporcionados por 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 gestión de la configuración para aprovisionar y configurar recursos en tu entorno de origen.

Completa la evaluación

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

Planifica y construye tu base

En la fase de planificación y creación, aprovisionas y configuras la infraestructura para hacer lo siguiente:

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

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

  1. Crea una jerarquía de recursos.
  2. Configura la gestión de identidades y accesos (IAM) de Google Cloud.
  3. Configura la facturación
  4. Configura la conectividad de red.
  5. Refuerza tu seguridad.
  6. Configura el almacenamiento de registros, la monitorización y las alertas.

Para obtener más información sobre cada una de estas tareas, consulta el artículo Migrar a Google Cloud: planificar y crear la base.

Migrar 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 de implementación y operativos para desplegar 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 coste.

Para ayudarte a evitar problemas durante la migración y a estimar el esfuerzo que requiere, 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 tu migración de AWS Lambda a Cloud Run. Estas diferencias pueden influir tanto en el diseño como en las decisiones de refactorización, tal como se destaca en las siguientes secciones.

Diseñar, aprovisionar y configurar 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 vas a migrar desde AWS Lambda.

Para diseñar correctamente tu entorno de Cloud Run, usa los datos que has recogido 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 desplegar 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.

Elegir 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 desplegar tus cargas de trabajo. Cloud Run admite los siguientes recursos principales:

  • Servicios de Cloud Run: un recurso que aloja un entorno de ejecución en contenedores, expone un punto final único y escala automáticamente la infraestructura subyacente según la demanda.
  • Tareas de Cloud Run: un recurso que ejecuta uno o varios contenedores hasta que se completan.

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 mediante un evento, como los que se usan en sitios web y aplicaciones web, APIs y microservicios, procesamiento de datos de streaming y arquitecturas basadas en eventos. Servicio de Cloud Run que puedes invocar con activadores.
Función de AWS Lambda que se ha programado para ejecutarse, como las de tareas en segundo plano y trabajos por lotes. Trabajo de Cloud Run que se ejecuta hasta completarse.

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

Diseñar la configuración de los 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 a las opciones de configuración 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 a 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 al migrar tus cargas de trabajo de AWS Lambda. Cloud Run ofrece varias opciones para activar y ejecutar las cargas de trabajo basadas en eventos que se usan en AWS Lambda. Además, Cloud Run ofrece opciones que puedes usar para cargas de trabajo de streaming y tareas programadas.

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

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

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

Para saber qué mecanismos de invocación o ejecución de Cloud Run son comparables a 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 adecuado.

Función AWS Lambda Función de Cloud Run
Activador HTTPS (URLs de funciones) Invocación de HTTPS
Activador HTTP/2 (parcialmente compatible mediante una API externa gateway) Invocación de HTTP/2 (compatible de forma nativa)
WebSockets (compatible con una pasarela de API externa) WebSockets (compatible de forma nativa)
N/A (no se admiten conexiones gRPC) Conexiones gRPC
Invocación asíncrona Integración de Cloud Tasks
Invocación programada Integración con Cloud Scheduler
Activador basado en eventos en un formato de evento propietario Invocación basada en eventos en formato CloudEvents
Integración de Amazon SQS y Amazon SNS Integración de Pub/Sub
Funciones de paso de AWS Lambda Integración de flujos de trabajo
Configuración de recursos de Cloud Run

Para complementar las decisiones de diseño que has tomado 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 constan de servicios de recursos y tareas.

Como hemos mencionado antes, puedes entender mejor cómo funciona Cloud Run si primero te familiarizas con todas las opciones de configuración disponibles en Cloud Run. De esta forma, podrás comparar las funciones de AWS Lambda con las de Cloud Run y determinar cómo refactorizar tus cargas de trabajo.

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

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

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

Función AWS Lambda Función de Cloud Run
Simultaneidad aprovisionada Número mínimo de instancias
Simultaneidad reservada por instancia
(El grupo de simultaneidad se comparte entre las funciones de AWS Lambda de tu cuenta de AWS).		 Número máximo 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
Ajustes de escalabilidad Autoescalado 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 las solicitudes de servicios
Tiempo de espera de las tareas
AWS Lambda SnapStart Aumento de la CPU al inicio
Variables de entorno Variables de entorno
Almacenamiento de datos efímeros Montajes de volúmenes en memoria
Conexiones de Amazon Elastic File System Montajes de volúmenes NFS
No se admiten los montajes de volúmenes de S3 Montajes de volúmenes de Cloud Storage
AWS Secrets Manager en cargas de trabajo de AWS Lambda Secretos
URLs de cargas de trabajo y endpoints HTTP(S) URLs asignadas automáticamente
Integraciones de Cloud Run con Google Cloud productos
Sesiones fijas (con un balanceador de carga externo) Afinidad de sesión
Clasificatorios Revisiones

Además de las funciones que se indican en la tabla anterior, también debe tener en cuenta las diferencias entre cómo aprovisionan instancias del entorno de ejecución AWS Lambda y Cloud Run. AWS Lambda aprovisiona una sola instancia para cada solicitud simultánea. Sin embargo, Cloud Run te permite definir el número de solicitudes simultáneas que puede atender una instancia. Es decir, el comportamiento de aprovisionamiento de AWS Lambda equivale a definir el número máximo de solicitudes simultáneas por instancia en 1 en Cloud Run. Si se define el número máximo de solicitudes simultáneas en un valor superior a 1, se pueden reducir los costes de forma 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 gestionar solicitudes en paralelo.

Seguridad y control de acceso de Cloud Run

Cuando diseñes tus recursos de Cloud Run, también tendrás que 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 para definir 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 os ayudará a entender cómo funcionarán las cargas de trabajo migradas en Cloud Run y a identificar las opciones de Cloud Run que podríais necesitar si refactorizáis 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 ofrece Cloud Run, consulta los siguientes recursos:

Para ayudarte a entender qué controles de seguridad y acceso de Cloud Run son comparables a los que están disponibles en AWS Lambda, consulta 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 AWS Lambda Función de Cloud Run
Control de acceso con la gestión de identidades y accesos de AWS Control de acceso con la gestión de identidades y accesos de Google Cloud
Rol de ejecución Google Cloud's rol de gestión de identidades y accesos
Límites de permisos Google Cloud's IAM permissions and custom audiences
Controles de gobernanza Servicio de política de organización
Firma de código Autorización binaria
Acceso completo a la VPC Controles de acceso de salida de VPC detallados

Aprovisionar y configurar recursos de Cloud Run

Después de elegir los recursos de Cloud Run para desplegar tus cargas de trabajo, aprovisiona y configura esos recursos. Para obtener más información sobre el aprovisionamiento de recursos de Cloud Run, consulta los siguientes artículos:

Refactorizar cargas de trabajo de AWS Lambda

Para migrar tus cargas de trabajo de AWS Lambda a Cloud Run, es posible que tengas que refactorizarlas. Por ejemplo, si una carga de trabajo basada en eventos acepta activadores que contienen eventos de Amazon CloudWatch, es posible que tengas que refactorizar esa carga de trabajo para que acepte eventos en el formato 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. Ten en cuenta cómo se ha diseñado la carga de trabajo en términos de arquitectura. Por ejemplo, las cargas de trabajo de AWS Lambda que tienen claramente separada la lógica empresarial de la lógica para acceder a las APIs específicas de AWS pueden requerir menos refactorización en comparación con las cargas de trabajo en las que se mezclan las dos lógicas.
  • Idempotencia. Determina si la carga de trabajo es idempotente en relación con sus entradas. Una carga de trabajo que sea idempotente a las entradas puede requerir menos refactorización que las cargas de trabajo que necesiten mantener el estado de las entradas que ya han procesado.
  • Estado. Comprueba si la carga de trabajo no tiene estado. Una carga de trabajo sin estado puede requerir menos refactorización que 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 las opciones de almacenamiento de Cloud Run.
  • Entorno de tiempo de ejecución. Ten en cuenta si la carga de trabajo hace alguna suposición sobre su entorno de tiempo de ejecución. Para estos tipos de cargas de trabajo, es posible que tengas que cumplir los mismos requisitos en el entorno de ejecución de Cloud Run o refactorizar la carga de trabajo si no puedes asumir lo mismo en el entorno de ejecución de Cloud Run. Por ejemplo, si una carga de trabajo requiere que haya disponibles determinados paquetes o bibliotecas, debes instalarlos en el entorno de ejecución de Cloud Run que va a alojar esa carga de trabajo.
  • Inyección de configuración. Comprueba si la carga de trabajo admite el uso de variables de entorno y secretos para insertar (definir) su configuración. Una carga de trabajo que admita este tipo de inyección puede requerir menos refactorización que las cargas de trabajo que admitan otros mecanismos de inyección de configuración.
  • APIs. Ten en cuenta si la carga de trabajo interactúa con las APIs de AWS Lambda. Es posible que haya que refactorizar una carga de trabajo que interactúe con estas APIs para que use APIs de Cloud y APIs de Cloud Run.
  • Informes de errores. Comprueba si la carga de trabajo informa de los errores mediante flujos de salida y de error estándar. Una carga de trabajo que haga este tipo de informes de errores puede requerir menos refactorización en comparación con cargas de trabajo que informen de errores mediante otros mecanismos.

Para obtener más información sobre cómo desarrollar y optimizar cargas de trabajo de Cloud Run, consulta los siguientes recursos:

Refactorizar los procesos de implementación y operativos

Después de refactorizar tus cargas de trabajo, refactoriza tus procesos de implementación y operativos para hacer lo siguiente:

  • Aprovisiona y configura recursos en tu Google Cloud entorno en lugar de aprovisionar recursos en tu entorno de origen.
  • Crea y configura cargas de trabajo, e impleméntalas en tu Google Cloud en lugar de hacerlo en tu entorno de origen.

Ha recogido información sobre estos procesos durante la fase de evaluación, que se ha llevado a cabo anteriormente en este proceso.

El tipo de refactorización que debes tener en cuenta para estos procesos depende de cómo los hayas diseñado e implementado. La refactorización también depende del estado final que quieras conseguir en cada proceso. Por ejemplo, plantéate lo siguiente:

  • Es posible que hayas implementado estos procesos en tu entorno de origen y que tengas la intención de diseñar e implementar procesos similares en Google Cloud. Por ejemplo, puedes refactorizar estos procesos para usar Cloud Build, Cloud Deploy e 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 que se dirijan a tu entorno de Google Cloud en lugar de a tu entorno de origen.
  • Una combinación de los enfoques anteriores.

Refactorizar los procesos de implementación y operativos puede ser complejo y requerir un esfuerzo considerable. 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 de implementación y operativos, probablemente tengas una idea de su diseño y complejidad. Si crees que necesitas dedicar mucho tiempo a refactorizar tu implementación y tus procesos operativos, te recomendamos que lo hagas en un proyecto independiente.

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

Este documento se centra en los procesos de implementación que generan los artefactos que se van a implementar y en cómo 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 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 de destinoGoogle Cloud . Por ejemplo, puedes empezar desplegando un pequeño subconjunto de tus cargas de trabajo en Google Cloudcon artefactos almacenados en Artifact Registry. Después, aumenta gradualmente el número de cargas de trabajo implementadas en Google Cloudhasta que todas las cargas de trabajo que quieras migrar se ejecuten enGoogle Cloud.
  4. Refactoriza tus procesos de compilación para almacenar artefactos solo en Artifact Registry.
  5. Si es necesario, migra versiones anteriores de los artefactos para implementarlos desde los repositorios de tu entorno de origen a Artifact Registry. Por ejemplo, puedes copiar imágenes de contenedor en Artifact Registry.
  6. Retira los repositorios de tu entorno de origen cuando ya no los necesites.

Para facilitar las reversiones que puedan ser necesarias debido a problemas imprevistos durante la migración, puedes almacenar imágenes de contenedor tanto en tus repositorios de artefactos actuales en Google Cloud mientras se lleva a cabo la migración a Google Cloud . Por último, como parte de la retirada del servicio 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 que la migración se lleve a cabo correctamente, es posible que tengas que migrar las versiones anteriores de tus artefactos del entorno de origen a tus repositorios de artefactos en Google Cloud. Por ejemplo, para admitir la restauración de tus cargas de trabajo a puntos arbitrarios en el tiempo, es posible que tengas que migrar versiones anteriores de tus artefactos a Artifact Registry. Para obtener más información, consulta 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 la exfiltración de datos, el análisis de vulnerabilidades y Binary Authorization. Para obtener más información, consulta Controlar el acceso y proteger los artefactos.

Refactorizar procesos operativos

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

Cloud Run se integra con los siguientes servicios operativos:

Migrar datos

En la fase de evaluación anterior de este proceso, deberías haber determinado si las cargas de trabajo de AWS Lambda que vas a migrar dependen de datos que residen en tu entorno de AWS o si generan datos que residen en él. Por ejemplo, puede 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 a Google Cloud, consulta el artículo sobre cómo migrar de AWS a Google Cloud: primeros pasos.

Al igual que con la refactorización de los procesos de implementación y operativos, migrar datos de AWS a Google Cloud puede ser complejo y requerir un esfuerzo considerable. 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 quieres migrar, probablemente te harás una idea del tamaño y la complejidad de los datos. Si crees que necesitas mucho tiempo para migrar estos datos, te recomendamos que lo hagas en un proyecto independiente.

Validar los resultados de la migración

La validación de la migración de cargas de trabajo no es un evento puntual, sino un proceso continuo. Debes centrarte en las pruebas y la validación antes, durante y después de migrar de AWS Lambda a Cloud Run.

Para que la migración se lleve a cabo correctamente, con un rendimiento óptimo y las mínimas interrupciones posibles, te recomendamos que sigas este proceso para validar las cargas de trabajo que vas a migrar de AWS Lambda a Cloud Run:

  • Antes de empezar la fase de migración, refactoriza los casos de prueba para tener en cuenta el entorno de destino. Google Cloud
  • 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, haga las siguientes pruebas:
    • Pruebas de referencia: establece métricas 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 las discrepancias que puedan indicar problemas de migración o de configuración.
    • Pruebas funcionales: asegúrese de que la lógica principal de sus cargas de trabajo se mantiene coherente creando y ejecutando casos de prueba que cubran varios escenarios de entrada y salida esperados en ambos entornos.
    • Pruebas de carga: aumenta el tráfico gradualmente para evaluar el rendimiento y la escalabilidad de Cloud Run en condiciones reales. Para que la migración se realice sin problemas, soluciona las discrepancias, como los errores y las limitaciones de recursos.

Optimizar tu Google Cloud entorno

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

  1. Evalúa tu entorno, tus equipos y tu bucle de optimización actuales.
  2. Establezca sus requisitos y objetivos de optimización.
  3. Optimiza tu entorno y tus equipos.
  4. Ajusta 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, consulta los artículos Migrar a Google Cloud: optimizar tu entorno y Google Cloud Well-Architected Framework: optimización del rendimiento. Google Cloud

Siguientes pasos

Colaboradores

Autores:

Otros colaboradores: