La semaine du 7 septembre est celle où AWS Transform for .NET a cessé d'être un outil dans lequel on clique pour devenir une étape que l'on place dans un pipeline. Une CLI d'une seule ligne est passée en disponibilité générale, la même transformation a commencé à générer des tests unitaires pour le code qu'elle réécrit, et AWS Transform a atteint GovCloud (US-West) pour la migration de serveurs. Autour, Lambda Managed Instances a reçu un timeout de 90 minutes et Graviton5, EBS Volume Clones a appris à franchir les frontières de compte avec re-chiffrement, et un Outposts mono-rack de 42U est passé en GA.

AWS Transform for .NET : CLI, tests, GovCloud

Trois lancements, une seule direction. Le 9 septembre, la modernisation AWS Transform for .NET est devenue disponible en disponibilité générale via CLI : une seule commande déclenche une transformation gérée par AWS dans AWS Transform custom, et vous pouvez la lancer en interactif ou la scripter dans un pipeline existant pour qu'elle tourne sans surveillance. La transformation inclut 50 000 minutes d'agent gratuites par mois et est disponible dans huit Régions : N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt et London.

Le 10 septembre, AWS Transform for .NET a commencé à générer des tests unitaires pour le code modernisé. Il évalue la testabilité de l'application en parallèle de l'évaluation .NET standard, planifie quelles classes et méthodes couvrir (logique métier, controllers) et émet le code de test dans le même job. Opt-in, activable au démarrage du job ou après la fin de la transformation, pour l'instant via l'AWS Toolkit for Visual Studio.

Et le 8 septembre, AWS Transform est arrivé dans AWS GovCloud (US-West). Le périmètre compte : il s'agit de la capacité de migration de serveurs (VMware, bare metal, Hyper-V, charges base de données, réplication et cutover vers l'une ou l'autre Région GovCloud). La modernisation, la transformation custom et l'évaluation restent pour l'instant dans les Régions commerciales.

La CLI est le lancement qui compte : une modernisation qui vit dans un IDE est un projet, une modernisation qui tourne dans la CI est un processus. Vous pouvez lancer la transformation sur une branche chaque nuit, differ la sortie avec celle de la veille, et traiter l'agent comme n'importe quelle autre étape de build qui passe ou ne passe pas. C'est ainsi qu'on modernise 80 services au lieu de 8.

Le mode de défaillance à anticiper, ce sont les tests. Une suite de tests générée à partir du code transformé encode le comportement du code transformé. C'est un filet de régression pour tout ce que vous changerez après la migration, ce qui a de la valeur, mais cela ne prouve pas que la migration a préservé le comportement de l'original .NET Framework. Pour cela, il vous faut toujours l'ancienne suite, ou des tests de caractérisation écrits contre l'ancien binaire et exécutés contre le nouveau. Utilisez les tests générés comme plancher, pas comme validation finale.

Lambda Managed Instances : 90 minutes et Graviton5

Le 9 septembre, Lambda a ajouté un timeout de fonction de 90 minutes sur Lambda Managed Instances pour les invocations asynchrones et celles par event source mapping, six fois le plafond de 15 minutes qui a défini l'architecture Lambda pendant une décennie. Les invocations synchrones gardent 15 minutes. La limite plus longue s'applique aussi aux étapes à l'intérieur des Lambda durable functions. Le même jour, Managed Instances a gagné les instances C9g, C9gd, M9g et M9gd propulsées par Graviton5, qu'AWS annonce jusqu'à 25% plus performantes en calcul que Graviton4.

Managed Instances avait déjà changé le modèle de tarification (économie d'instance EC2, plusieurs requêtes concurrentes par instance) et ce changement termine la pensée : c'est une flotte de calcul managée avec un modèle de programmation en forme de fonction. Les transcodages média, les simulations Monte Carlo et l'inférence par lots n'ont plus besoin d'une chaîne Step Functions ou d'une tâche ECS juste pour dépasser la quinzième minute.

Ce qui ne change pas : les invocations asynchrones sont at-least-once. Un job de 90 minutes rejoué après une défaillance partielle vous coûte 90 minutes deux fois et, s'il écrit au fil de l'eau, laisse un résultat à moitié écrit. Les clés d'idempotence et le checkpointing comptent davantage à 90 minutes, pas moins. Et comme Managed Instances se facture en capacité EC2, faites explicitement la comparaison de coût avec une tâche Fargate ou un job AWS Batch avant de déplacer une charge longue ; le gain est opérationnel, pas automatiquement financier.

EBS Volume Clones franchit les comptes, avec de nouvelles clés

Le 9 septembre, EBS Volume Clones a commencé à prendre en charge les copies entre comptes AWS, avec re-chiffrement par une clé KMS du compte cible. Le flux : partager le volume source via AWS RAM, puis le compte cible crée une copie dans la même Availability Zone. Cela fonctionne pour tous les types de volume, y compris les volumes non chiffrés et ceux sous clés gérées par le client.

Le cas d'usage qu'AWS met en avant est le bon : une copie fraîche d'un volume de base de données de production dans un compte de développement isolé. L'ancienne méthode était snapshot, partage du snapshot, copie du snapshot avec une nouvelle clé, création du volume, quatre étapes et beaucoup d'attente. La nouvelle méthode est une seule copie avec séparation des clés intégrée, ce qu'exige réellement la règle « les clés de prod ne quittent jamais la prod » d'une landing zone.

Deux choses qu'une équipe plateforme devrait noter. Premièrement, « même Availability Zone » signifie la même zone physique, et les noms de zone (eu-west-1a) correspondent différemment selon le compte. Utilisez les AZ ID (euw1-az1) dans toute automatisation, sinon la copie atterrit dans une zone que vos sous-réseaux de dev ne couvrent pas. Deuxièmement, cloner des données de production vers le dev est un événement de gouvernance des données, pas un événement de stockage. Placez le partage RAM derrière une approbation et journalisez qui a copié quoi ; les mécanismes faciles exigent des contrôles explicites.

Également cette semaine

Le fil conducteur

Chaque annonce de la semaine a fait passer quelque chose de « une personne le fait » à « un pipeline le fait ». Transform tourne depuis la CLI et écrit ses propres tests. Lambda tient un job pendant 90 minutes pour que vous cessiez de bricoler une orchestration autour de la quinzième minute. EBS copie un volume de prod vers le dev avec la bonne clé en une seule opération. Systems Manager vous dit pourquoi l'instance est non gérée au lieu de vous laisser deviner. Chacune retire une étape humaine d'un processus qui en avait besoin. Le travail d'une équipe plateforme est de décider lesquelles de ces étapes étaient là pour une raison (l'approbation avant que des données de prod ne quittent la prod) et de les garder, délibérément, maintenant que l'outillage ne vous y oblige plus.

À lire ensuite

Pour la lecture IA et agents de la même semaine, voir ercan.ai. Si votre équipe a besoin d'aide concrète sur AWS, l'architecture cloud, les pipelines CI/CD, Linux, GitHub ou GitLab et le travail de plateforme qui les entoure, le volet conseil se trouve sur ercanermis.com.

Références