AWS Transform peut désormais convertir le code SDK Azure des applications .NET en code SDK AWS
AWS indique que son agent de modernisation .NET réécrit désormais les appels à une sélection de services Azure vers leurs équivalents AWS, en couvrant le code applicatif mais pas l'infrastructure.

Points clés
- 1AWS a mis en disponibilité générale dans AWS Transform la conversion de code du SDK Azure vers le SDK AWS, annoncée le 16 octobre.
- 2Chemins pris en charge selon AWS : Azure Functions vers Lambda, Blob Storage vers S3, Queue Storage vers SQS ; Cosmos DB vers DynamoDB est en préversion.
- 3La fonctionnalité convertit uniquement le code applicatif et ne migre pas l'infrastructure cloud, selon le guide de l'utilisateur.
- 4Les options de conversion figurent dans le rapport d'évaluation et le plan de modernisation et peuvent être personnalisées ou désactivées.
- 5Le code non convertible est signalé dans des commentaires TODO, du code stub ou un fichier Next Steps généré, indique AWS.
L'article complet
AWS a mis en disponibilité générale, dans AWS Transform, la conversion de code du SDK Azure vers le SDK AWS, selon une annonce publiée le 16 octobre. L'entreprise présente cette fonctionnalité comme un moyen plus rapide de déplacer vers AWS des applications .NET cloud-native conçues pour Microsoft Azure. Selon AWS, l'agent de modernisation .NET d'AWS Transform repère le code qui appelle des services Azure et le réécrit pour utiliser les services AWS correspondants.
AWS répertorie quatre conversions prises en charge : les Azure Functions sont réécrites en fonctions AWS Lambda, le code Azure Blob Storage est déplacé vers Amazon S3 et le code Azure Queue Storage est déplacé vers Amazon SQS, tandis que la conversion du code Azure Cosmos DB vers Amazon DynamoDB est proposée en préversion. Le guide de l'utilisateur précise que seuls ces services répertoriés sont convertis et suggère AWS Transform custom ou un assistant de codage à IA tel que Kiro pour les autres services. AWS note également que la fonctionnalité traite uniquement le code applicatif et ne migre pas l'infrastructure cloud.
Selon AWS, le service détecte le SDK Azure dans le code source soumis et présente les options de conversion dans son rapport d'évaluation et son plan de modernisation, que les utilisateurs peuvent accepter ou ajuster avant l'exécution de la modernisation. AWS indique qu'il vérifie ensuite que les modifications sont intégrées dans le code transformé. La documentation décrit la conversion comme automatique pour les applications .NET modernes éligibles, le comportement pouvant être ajusté via le chat avec l'agent, des modifications du plan ou un document d'orientation, par exemple pour ignorer une partie ou la totalité des conversions, définir des conventions de nommage, modifier le niveau de détail des commentaires ou diriger le code Blob Storage vers DynamoDB plutôt que vers S3.
Le code qui n'a pas d'équivalent sur AWS est signalé plutôt que converti : le guide de l'utilisateur indique qu'il est marqué par des commentaires TODO, laissé sous forme de code stub (code de substitution) ou consigné dans un fichier markdown Next Steps produit par AWS Transform. AWS indique qu'AWS Transform est proposé dans huit régions AWS, à savoir Francfort et Londres en Europe, Mumbai, Tokyo, Séoul et Sydney en Asie-Pacifique, ainsi que Canada (Centre) et USA Est (Virginie du Nord).
Pourquoi c’est important
La réécriture des appels SDK propres à chaque service représente une part importante du travail nécessaire pour retirer des applications .NET de Microsoft Azure. AWS automatise une partie de ce travail pour un petit ensemble de services, mais les équipes doivent toujours migrer l'infrastructure séparément et traiter tout code que l'outil signale comme non converti.
Chronologie
· Publié
Sujets#AWS Transform#Microsoft Azure#.NET#migration cloud#AWS Lambda#modernisation du code
Sources
Cet article s'appuie sur les sources suivantes. Consultez-les pour le contexte complet.



