Refactoriser les limites propres au fournisseur

Préservez la logique métier tout en remplaçant le code d'intégration propre à AWS.

Pour refactoriser les limites propres au fournisseur, procédez comme suit :

  1. Extraire la logique métier dans des modules neutres pour les fournisseurs. Ajoutez un analyseur d'événements AWS uniquement pour la réexécution des événements source capturés lors des tests de comparaison.
  2. Créez un adaptateur OCI pour le modèle d'appel cible : demande/réponse, CloudEvent, message de file d'attente, enregistrement de flux, événement d'objet, notification ou demande d'intégration.
  3. Remplacez les appels directs du kit SDK AWS par des interfaces et implémentez les appels de service OCI derrière ces interfaces. Faites de même pour la configuration, l'accès à la clé secrète, la journalisation, les mesures et la gestion des nouvelles tentatives.
  4. Réexécutez les événements Lambda capturés et comparez les codes de statut, les en-têtes, les corps de réponse, les métadonnées d'objet, les écritures en aval, les effets secondaires, les messages d'erreur et le comportement d'idempotence.

Recherchez la logique métier à séparer de l'analyse des événements, des appels SDK, des hypothèses IAM, de la journalisation, du packaging et de la gestion des nouvelles tentatives.

Remarques : Evitez de réécrire la logique métier en même temps que l'intégration du fournisseur. La modification des deux rend les tests d'équivalence plus difficiles.

Comprendre ce qu'offre OCI

Identifiez les étapes de migration qui utilisent la configuration OCI standard et qui nécessitent un code personnalisé.

Oracle Cloud Infrastructure fournit des services pour l'exécution des fonctions, la gestion des API, les événements, les files d'attente, la programmation, l'identité, la mise en réseau, l'observabilité et le déploiement. Toutefois, la migration peut toujours nécessiter des modifications propres à la charge globale, notamment :

  • Conversion des charges utiles d'événement AWS en entrée attendue par l'application
  • Remplacement des appels de kit SDK AWS par des appels de kit SDK OCI
  • Recréer le comportement des déclencheurs, des nouvelles tentatives, des commandes et des échecs
  • Traduction des droits d'accès IAM et de l'accès réseau
  • Mise à jour des pipelines CI/CD et des procédures opérationnelles

Avant l'implémentation, identifiez les étapes qui utilisent la configuration OCI standard et celles qui nécessitent un code personnalisé. Validez cette distinction en utilisant une charge globale représentative avant d'estimer la migration plus large.

Packagez et déployez la fonction OCI

Créez la fonction migrée en tant qu'image de conteneur et déployez-la vers OCI Functions.

Pour packager et déployer une fonction, procédez comme suit :

  1. Créez ou mettez à jour le projet de fonction et func.yaml. Définissez la mémoire et le délai d'expiration à partir du comportement de la source mesurée, et non à partir des valeurs par défaut.
  2. Déplacez les anciens contenus de la couche Lambda, les dépendances natives, les dépendances d'exécution, les certificats et les packages système vers l'image ou une image de base partagée, le cas échéant.
  3. Suivre la taille de l'image, les versions de dépendance, la compatibilité de la bibliothèque native, le comportement de démarrage, le travail d'initialisation et le comportement d'exécution dans l'image du conteneur.
  4. Créez, propagez, déployez et appelez la fonction avec des charges utiles représentatives de réussite et d'échec avant de connecter des déclencheurs de production.

Vérifiez que l'image génère, propage, déploie, appelle et consigne la sortie attendue sans divulguer de clés secrètes.

Considérations : Le packaging de dépendance est souvent l'endroit où apparaissent les hypothèses Lambda cachées, en particulier avec les couches, les bibliothèques natives, les extensions et les versions de SDK intégrées.

Utiliser un modèle de transmission reproductible

Une migration de production doit utiliser un processus de transmission géré par version.

Pour utiliser un modèle de transmission reproductible, procédez comme suit :

  1. Stockez ensemble le code de fonction, la configuration, les tests et les définitions d'infrastructure.
  2. Créez et testez un artefact de fonction avec numéro de version.
  3. Analysez l'artefact et ses dépendances.
  4. Promouvez le même artefact testé dans les environnements.
  5. Provisionner ou mettre à jour les ressources OCI via Infrastructure as Code.
  6. Exécuter des tests de fumée et d'intégration après le déploiement.
  7. Conservez l'artefact de production et la configuration précédents pour l'annulation.

Utilisez la plate-forme d'intégration continue et de déploiement continu existante lorsque cela est possible. Vous ne devez pas modifier les outils, sauf si cela est nécessaire pour l'architecture OCI Functions.

Migrer des déclencheurs et des intégrations

Recréez le comportement d'appel requis dans OCI.

Pour migrer des déclencheurs et des intégrations, procédez comme suit :

  1. Pour les charges globales HTTP, comparez l'authentification, la méthode, le chemin, les en-têtes, les chaînes de requête, le schéma de corps, les codes de statut, le corps de l'erreur, la taille de la charge utile, le délai d'expiration, la latence et le comportement des tentatives de l'appelant.
  2. Pour les événements d'objet, comparez le schéma d'événement, les métadonnées d'objet, l'espace de noms, le filtrage de bucket et de préfixe, le comportement de création/mise à jour/suppression, le comportement des nouvelles tentatives, les événements en double, l'idempotence et la prévention des boucles entre les chemins d'entrée et de sortie.
  3. Pour les files d'attente et les flux, concevez une gestion explicite de la taille des lots, du tri, des défaillances partielles, du comportement en matière de visibilité ou de nouvelle tentative, de la DLQ ou de la destination des défaillances, des messages empoisonnés, de la contre-pression, des doublons, du débit et de la réexécution.
  4. Pour les programmations, les notifications, les journaux et les flux d'intégration, vérifiez le type d'appel, la latence, le nombre de nouvelles tentatives, le routage des pannes, le comportement de ventilation, le filtrage et l'observabilité.

Vérifiez que chaque déclencheur a un modèle de cible OCI documenté et réussit les tests pour les scénarios normaux, d'échec, de nouvelle tentative et de livraison en double.

Remarques : Ne présumez pas qu'un mappage de source d'événement AWS a une substitution OCI directe. Conservez le comportement requis, et non le nom de contrôle AWS.

Modèles de déclencheur lambda courants

Les mappings suivants démarrent des modèles pour une migration OCI Functions.

Validez le comportement requis avant l'implémentation :

Modèle AWS Modèle de début OCI Functions Articles à valider
Passerelle API vers Lambda Passerelle API OCI vers Fonctions OCI Routages, méthodes, authentification, formats de demande et de réponse, limites de charge utile, délais d'attente, codes de statut et comportement d'erreur synchrone
EventBridge à Lambda Evénements OCI à OCI Functions pour les événements de service OCI ; utilisez le service de routage d'événements OCI applicable pour des exigences de routage plus larges Exigences en matière de couverture des événements, de filtres, de schémas, de comportement de livraison, de nouvelles tentatives et de réexécution
SQS à Lambda Oracle Cloud Infrastructure Queue via OCI Connector Hub vers OCI Functions Taille du lot, délai de visibilité, livraison au moins une fois, commande, traitement des doublons, messages empoisonnés et récupération après défaillance
Evénements S3 à Lambda Evénements OCI Object Storage via des événements OCI vers OCI Functions Schéma d'événement, filtres, livraison en double, droits d'accès aux objets, comportement des nouvelles tentatives et effets secondaires en aval
Evénements programmés à Lambda Planificateur de ressources OCI vers OCI Functions Expression de programmation, fuseau horaire, charge utile d'entrée, délai d'expiration, exécutions en chevauchement et destinations de réussite ou d'échec

Ne présumez pas que les services AWS et OCI ont un comportement identique. Validez le comportement requis par chaque charge globale avant l'implémentation.

Conserver le comportement du déclencheur et de l'échec

Documentez et testez le comportement requis pour chaque déclencheur migré.

Pour préserver le comportement des déclencheurs et des défaillances, procédez comme suit :

  1. Documentez et testez les éléments suivants pour chaque déclencheur migré :
    • Indique si la livraison est synchrone ou asynchrone
    • Réessayer le propriétaire, l'intervalle entre les nouvelles tentatives et le nombre maximum de tentatives
    • Garanties de livraison et éventuels événements en double
    • Prescriptions de commande
    • Comportement d'idempotence
    • Comportement en cas d'échec partiel et de batch
    • Délai d'expiration de visibilité ou comportement d'accusé de réception
    • Gestion des messages empoisonnés
    • Défaillance ou destination des lettres mortes
    • Procédure de réexécution et de récupération
  2. Ne présumez pas que des services AWS et OCI similaires ont un comportement de livraison ou d'échec identique.
  3. Lorsque la livraison en double est possible, concevez la fonction pour traiter les événements répétés en toute sécurité.

Pour les appels OCI Functions détachés, les enregistrements de réussite et d'échec peuvent être envoyés vers les destinations OCI Queue, OCI Streaming ou OCI Notifications. Ce comportement est spécifique aux appels détachés et ne doit pas être décrit comme un remplacement universel pour chaque modèle de file d'attente de lettres mortes AWS.

Configuration d'IAM, des clés secrètes et de la mise en réseau

Convertissez le comportement d'exécution en accès OCI avec le moins de privilèges possible et en accessibilité réseau approuvée.

Pour configurer OCI Identity and Access Management (IAM), les clés secrètes et les fonctions de réseau, procédez comme suit :

  1. Mappez chaque action source avec une action, une ressource et un compartiment OCI. Evitez les stratégies générales à moins que la charge de travail ne les exige réellement et que les réviseurs ne les approuvent.
  2. Utilisez des groupes dynamiques et des principaux de ressource pour l'accès d'exécution aux ressources OCI. Testez les chemins autorisés et refusés, y compris le mauvais compartiment, le mauvais bucket, la mauvaise clé secrète et les cas de stratégie manquants.
  3. Déplacez les clés secrètes vers OCI Vault ou un modèle approuvé. Vérifiez qu'aucune valeur de clé secrète n'apparaît dans le code source, les images, les journaux, les vidages d'environnement, la sortie d'intégration continue, les traces de pile ou les messages d'erreur.
  4. Validez les règles de routage, les règles de sécurité, la passerelle de service ou le comportement NAT, les adresses privées, le DNS, la sécurisation TLS, les listes d'autorisation externes et les limites de connexion en aval.

Vérifiez que les appels de service autorisés réussissent, que les chemins refusés échouent en toute sécurité et que les chemins réseau requis sont accessibles sans exposer de chemins non autorisés.

Remarques : La traduction IAM doit partir du comportement d'exécution observé, et non des noms de stratégie AWS ou des stratégies gérées générales.

Recréer l'observabilité et les opérations

S'assurer que les responsables de production peuvent détecter, diagnostiquer et récupérer les pannes.

Pour recréer l'observabilité et les opérations, procédez comme suit :

  1. Emettre les journaux avec l'ID de corrélation, l'ID de demande, l'ID de déclencheur, l'identifiant d'objet ou de message, le statut, la durée, le nombre de nouvelles tentatives, les détails d'erreur nettoyés et le résultat de dépendance en aval.
  2. Confirmer les mesures et les alarmes pour le nombre d'appels, la durée, le taux d'erreur, le nombre d'expirations, les symptômes de ralentissement ou de capacité, le nombre d'échecs DLQ ou d'échecs, l'âge de la file d'attente ou le carnet de commandes, les résultats de distribution détachés et les échecs en aval.
  3. Créez des tableaux de bord ou des vues approuvées pour l'état, la latence, les erreurs, la capacité, le carnet de déclencheurs et le statut des dépendances.
  4. Mettez à jour les classeurs d'exécution avec des tests d'appel, des requêtes de journal, une réponse d'alarme, des contacts d'escalade, un déclencheur d'annulation, des étapes d'annulation et le temps de récupération attendu.

Vérifiez que les opérateurs de production peuvent observer et dépanner la fonction migrée avant le déplacement du trafic.

Remarques : Une migration n'est pas prête pour la production si seule la fonction fonctionne. Les opérateurs doivent être en mesure de détecter et de récupérer à partir d'un déclencheur, d'une clé secrète, d'un chemin réseau ou d'une dépendance en aval ayant échoué.