Refactorización de límites específicos del proveedor

Conserve la lógica de negocio al reemplazar el código de integración específico de AWS.

Para refactorizar los límites específicos del proveedor, siga estos pasos:

1. Extrae la lógica de negocio a módulos neutros para proveedores. Agregue un analizador de eventos de AWS solo para reproducir los eventos de origen capturados durante las pruebas de comparación.
2. Cree un adaptador de OCI para el patrón de llamada de destino: solicitud/respuesta, CloudEvent, mensaje de cola, registro de flujo, evento de objeto, notificación o solicitud de integración.
3. Sustituya las llamadas directas de AWS SDK por interfaces e implemente las llamadas de servicio de OCI detrás de esas interfaces. Haga lo mismo con la configuración, el acceso secreto, el registro, las métricas y el manejo de reintentos.
4. Reproduzca los eventos Lambda capturados y compare los códigos de estado, las cabeceras, los cuerpos de respuesta, los metadatos de objetos, las escrituras descendentes, los efectos secundarios, los mensajes de error y el comportamiento de idempotencia.

Busque que la lógica de negocio esté separada del análisis de eventos, las llamadas SDK, las suposiciones de IAM, el registro, el empaquetado y el manejo de reintentos.

Consideraciones: Evite reescribir la lógica de negocio al mismo tiempo que la integración de proveedores. Cambiar ambos hace que las pruebas de equivalencia sean más difíciles.

Descubre qué proporciona OCI

Identificar qué pasos de migración utilizan la configuración estándar de OCI y cuáles requieren código personalizado.

Oracle Cloud Infrastructure proporciona servicios para la ejecución de funciones, la gestión de API, los eventos, las colas, la programación, la identidad, las redes, la observabilidad y el despliegue. Sin embargo, es posible que la migración aún requiera cambios específicos de la carga de trabajo, incluidos:

• Conversión de cargas útiles de eventos de AWS en la entrada esperada por la aplicación
• Sustitución de llamadas de AWS SDK por llamadas de OCI SDK
• Recreación del comportamiento de disparador, reintento, ordenación y fallo
• Traducción de permisos de IAM y acceso a la red
• Actualización de pipelines de integración y despliegue continuos y procedimientos operativos

Antes de la implantación, identifique qué pasos utilizan la configuración estándar de OCI y cuáles requieren código personalizado. Valide esa distinción mediante una carga de trabajo representativa antes de estimar la migración más amplia.

Empaquetado y despliegue de la función OCI

Cree la función migrada como imagen de contenedor y despliéguela en OCI Functions.

Para empaquetar y desplegar una función, siga estos pasos:

1. Cree o actualice el proyecto de función y func.yaml. Defina la memoria y el timeout a partir del comportamiento de origen medido, no a partir de los valores predeterminados.
2. Mueva el contenido de la capa Lambda anterior, las dependencias nativas, las dependencias de tiempo de ejecución, los certificados y los paquetes del sistema a la imagen o a una imagen base compartida según corresponda.
3. Realizar un seguimiento del tamaño de la imagen, las versiones de dependencia, la compatibilidad de la biblioteca nativa, el comportamiento de inicio, el trabajo de inicialización y el comportamiento en tiempo de ejecución dentro de la imagen de contenedor.
4. Cree, transfiera, despliegue y llame a la función con cargas útiles de éxito y fallo representativas antes de conectar los disparadores de producción.

Verifique que la imagen crea, transfiere, despliega, llama correctamente y registra la salida esperada sin filtrar secretos.

Consideraciones: El empaquetado de dependencia suele ser donde aparecen suposiciones Lambda ocultas, especialmente con capas, bibliotecas nativas, extensiones y versiones de SDK incrustadas.

Uso de Patrones de Entrega Repetibles

Una migración de producción debe utilizar un proceso de entrega controlado por versión.

Para utilizar un patrón de entrega repetible, siga estos pasos:

1. Almacene conjuntamente el código de función, la configuración, las pruebas y las definiciones de infraestructura.
2. Cree y pruebe un artefacto de función con versiones.
3. Analice el artefacto y sus dependencias.
4. Promocione el mismo artefacto probado en todos los entornos.
5. Aprovisione o actualice recursos de OCI mediante Infrastructure as Code.
6. Ejecute pruebas de humo e integración después del despliegue.
7. Conservar el artefacto de producción y la configuración anteriores para el rollback.

Utilice la plataforma de integración y despliegue continuos existente cuando sea práctico. No necesita un cambio de herramientas a menos que sea necesario para la arquitectura de OCI Functions.

Migración de disparadores e integraciones

Vuelva a crear el comportamiento de llamada necesario en OCI.

Para migrar disparadores e integraciones, siga estos pasos:

1. Para cargas de trabajo HTTP, compare la autenticación, el método, la ruta, las cabeceras, las cadenas de consulta, el esquema de cuerpo, los códigos de estado, el cuerpo del error, el tamaño de carga útil, el timeout, la latencia y el comportamiento de reintento del emisor de llamada.
2. Para los eventos de objeto, compare el esquema de eventos, los metadatos de objetos, el espacio de nombres, el filtrado de cubos y prefijos, el comportamiento de creación/actualización/supresión, el comportamiento de reintento, los eventos duplicados, la idempotencia y la prevención de bucles entre las rutas de entrada y salida.
3. Para colas y flujos, diseñe la manipulación explícita para el tamaño de lote, el orden, el fallo parcial, la visibilidad o el comportamiento de reintento, la DLQ o el destino de fallo, los mensajes venenosos, la contrapresión, los duplicados, el rendimiento y la reproducción.
4. Para programas, notificaciones, logs y flujos de integración, verifique el tipo de llamada, la latencia, el recuento de reintentos, el enrutamiento de fallos, el comportamiento de despliegue, el filtrado y la observabilidad.

Valide que cada disparador tenga un patrón de destino de OCI documentado y que supere las pruebas para escenarios normales, de fallos, de reintentos y de entrega duplicada.

Consideraciones: No asuma que una asignación de origen de eventos de AWS tiene un sustituto directo de OCI. Conservar el comportamiento necesario, no el nombre de control de AWS.

Patrones de disparador Lambda comunes

Las siguientes asignaciones están iniciando patrones para una migración de OCI Functions.

Valide el comportamiento necesario antes de la implantación:

Patrón de AWS	Patrón de inicio de OCI Functions	Elementos para validar
Gateway de API a Lambda	Gateway de API de OCI a OCI Functions	Rutas, métodos, autenticación, formatos de solicitud y respuesta, límites de carga útil, timeouts, códigos de estado y comportamiento de error síncrono
EventBridge a Lambda	OCI Events a OCI Functions para eventos de servicio de OCI; utilice el servicio de enrutamiento de eventos de OCI aplicable para requisitos de enrutamiento más amplios	Cobertura de eventos, filtros, esquemas, comportamiento de entrega, reintentos y requisitos de reproducción
SQS a Lambda	Oracle Cloud Infrastructure Queue a través de OCI Connector Hub para OCI Functions	Tamaño de lote, tiempo de espera de visibilidad, entrega al menos una vez, pedidos, manejo de duplicados, mensajes venenosos y recuperación de fallos
Eventos de S3 a Lambda	Eventos de OCI Object Storage mediante OCI Events hasta OCI Functions	Esquema de evento, filtros, entrega duplicada, permisos de objeto, comportamiento de reintento y efectos secundarios descendentes
Eventos programados a Lambda	Programador de recursos de OCI para OCI Functions	Programar expresión, zona horaria, carga útil de entrada, timeout, ejecuciones solapadas y destinos de éxito o fallo

No asuma que los servicios de AWS y OCI tienen un comportamiento idéntico. Valide el comportamiento que requiere cada carga de trabajo antes de la implantación.

Conservación del comportamiento del disparador y del fallo

Documente y pruebe el comportamiento necesario para cada disparador migrado.

Para conservar el comportamiento de los disparadores y los fallos, siga estos pasos:

1. Documente y pruebe lo siguiente para cada disparador migrado:
   • Si la entrega es síncrona o asíncrona
   • Reintentar propietario, intervalo de reintento y máximo de intentos
   • Garantías de entrega y posibles eventos duplicados
   • Requisitos de orden
   • Comportamiento de la Idempotencia
   • Comportamiento de fallo parcial y por lotes
   • Timeout de visibilidad o comportamiento de confirmación
   • Manejo de mensajes venenosos
   • Destino de letra muerta o fallo
   • Procedimiento de reproducción y recuperación
2. No asuma que los servicios similares de AWS y OCI tienen un comportamiento de entrega o fallo idéntico.
3. Cuando sea posible la entrega duplicada, diseñe la función para procesar eventos repetidos de forma segura.

Para las llamadas a OCI Functions desasociadas, los registros de éxito y fallo se pueden enviar a los destinos OCI Queue, OCI Streaming o OCI Notifications. Este comportamiento es específico de las llamadas desasociadas y no se debe describir como un reemplazo universal para cada patrón de cola de mensajes con problemas de entrega de AWS.

Configuración de IAM, secretos y redes

Traduce el comportamiento del tiempo de ejecución al acceso de OCI con el mínimo privilegio y la accesibilidad de red aprobada.

Para configurar OCI Identity and Access Management (IAM), secretos y redes, siga estos pasos:

1. Asigne cada acción de origen a una acción, un recurso y un compartimento de OCI. Evite políticas amplias a menos que la carga de trabajo realmente las requiera y los revisores las aprueben.
2. Utilice grupos dinámicos y principales de recursos para el acceso en tiempo de ejecución a los recursos de OCI. Pruebe tanto las rutas permitidas como las denegadas, incluidos el compartimento incorrecto, el cubo incorrecto, el secreto incorrecto y los casos de política que faltan.
3. Mover secretos a OCI Vault o a un patrón aprobado. Confirme que no aparecen valores secretos en el código de origen, las imágenes, los logs, los volcados de entorno, la salida de CI, los rastreos de pila o los mensajes de error.
4. Valide reglas de ruta, reglas de seguridad, comportamiento de NAT o gateway de servicio, puntos finales privados, DNS, confianza de TLS, listas de permitidos externas y límites de conexión descendentes.

Valide que las llamadas de servicio permitidas se realicen correctamente, que las rutas denegadas fallen de forma segura y que se pueda acceder a las rutas de red necesarias sin exponer rutas no autorizadas.

Consideraciones: la traducción de IAM debe comenzar desde un comportamiento de tiempo de ejecución observado, no desde nombres de políticas de AWS ni políticas gestionadas amplias.

Recreación de Observability and Operations

Asegúrese de que los responsables de producción pueden detectar fallos, realizar diagnósticos y recuperarse de ellos.

Para volver a crear la observabilidad y las operaciones, siga estos pasos:

1. Emita logs con ID de correlación, ID de solicitud, ID de activador, identificador de objeto o mensaje, estado, duración, recuento de reintentos, detalle de error saneado y resultado de dependencia descendente.
2. Confirme las métricas y alarmas para el recuento de llamadas, la duración, el ratio de errores, el recuento de timeout, los síntomas de limitación o capacidad, el recuento de DLQ o fallos, la antigüedad o atrasos de cola, los resultados de entrega desasociados y los fallos descendentes.
3. Cree paneles de control o vistas aprobadas para el estado, la latencia, los errores, la capacidad, los atrasos de disparadores y el estado de dependencia.
4. Actualice los libros de ejecución con pruebas de llamada, consultas de log, respuesta de alarma, contactos de escalada, disparador de rollback, pasos de rollback y tiempo de recuperación esperado.

Verifique que los operadores de producción puedan observar y solucionar problemas de la función migrada antes de mover el tráfico.

Consideraciones: una migración no está lista para producción si solo funciona la función. Los operadores deben poder detectar y recuperarse de un disparador, secreto, ruta de red o dependencia descendente fallidos.