Nella prima settimana di agosto AWS Transform ha rilasciato tre lanci che insieme coprono una migrazione dallo schema che non hai ancora convertito al debito tecnico che troverai un anno dopo il cutover. Il 3 agosto l'agente di modernizzazione Windows ha guadagnato la trasformazione offline dello schema da SQL Server ad Aurora PostgreSQL e la continuous modernization è passata in disponibilità generale; il 6 agosto il workflow di migrazione ha imparato a eseguire post-launch action tramite Systems Manager. Intorno a questo, Lambda ha ottenuto fino a 3.000 Mbps di banda di rete, Aurora Serverless ha imparato a saltare a 12 ACU in un secondo, e i load balancer hanno ricevuto policy TLS di livello NSA.

La tesi della settimana: AWS non vende più Transform come uno strumento di rehost con un'etichetta AI. Sta riempiendo le parti di una migrazione che prima erano il foglio di calcolo di un partner, e questo cambia cosa dovresti aspettarti di fare a mano.

AWS Transform: schema, cutover e l'anno dopo

Prendi i tre in ordine di migrazione. La trasformazione offline dello schema accetta file DDL di SQL Server, quindi non ti serve una connessione live alla sorgente. Valuta la complessità del database e delle stored procedure, ti permette di modificare il piano generato, poi converte tabelle, schemi, stored procedure e funzioni, valida l'equivalenza funzionale e fa il deploy del risultato su Aurora PostgreSQL. La conversione degli oggetti di storage è alimentata da AWS DMS sotto il cofano. Per ora è solo US East (N. Virginia). La parte offline conta più di quanto sembri: i team che non riescono a far partire una migrazione di database sono di solito quelli i cui DBA non apriranno una porta a uno strumento di conversione. Un dump DDL è una conversazione più facile.

Le post-launch action chiudono il divario tra "il server si è avviato in AWS" e "il server è davvero nostro". Definisci le azioni una volta a livello di account, e Transform le applica a ogni server sorgente, attraverso gli account di destinazione in una migrazione multi-account, eseguendole tramite AWS Systems Manager subito dopo un lancio di test o di cutover. Azioni predefinite o il tuo documento SSM. Anche il file di inventario della migrazione ottiene una struttura per la revisione per server. Se hai gestito MGN su larga scala, conosci la modalità di guasto che questo rimuove: una wave di 80 server atterra e qualcuno installa l'agent CloudWatch a mano su 79 di essi.

La continuous modernization è il pezzo rivolto a quello che succede dopo. Si connette a organizzazioni GitHub, gruppi GitLab e workspace Bitbucket, gira on demand o su pianificazione, classifica i finding per debito tecnico, sicurezza, prontezza agentica e prontezza alla modernizzazione, e per i finding con una correzione apre pull o merge request con modifiche validate. L'analisi gira nel tuo account con le tue credenziali, e puoi pilotarla dalla web app, dalla CLI, da Kiro o come plugin per agenti. Il compromesso è lo stesso di ogni strumento che apre PR in automatico: la capacità di review. Uno scanner pianificato che apre PR più velocemente di quanto il team riesca a leggerle diventa rumore entro un trimestre. Parti con un solo gruppo di repository e un filtro di rank severo.

Banda Lambda: 3.000 Mbps, se non sei in una VPC

La banda di rete di Lambda ora scala con la memoria per le funzioni da 2 GB in su, da 625 Mbps a 2 GB fino a 3.000 Mbps a 10 GB, sostituendo il tetto fisso di 625 Mbps. Nessun costo aggiuntivo, tutte le Region commerciali. Due avvertenze accompagnano il lancio. Primo, è opt-in tramite una richiesta in Service Quotas sulla quota "Network bandwidth per execution environment", dopo la quale ogni funzione non-VPC nell'account scala automaticamente. Secondo, e più importante, si applica solo alle funzioni fuori da una VPC. La maggior parte delle funzioni enterprise che spostano oggetti grandi sta dentro una VPC, perché è lì che vivono l'istanza RDS e l'endpoint privato di S3. Se le tue trasformazioni pesanti da S3 a S3 girano in una VPC, questa settimana non ha cambiato nulla per te. Controlla con aws lambda get-function-configuration --function-name X --query VpcConfig prima di inviare la richiesta di quota.

Aurora Serverless: 12 ACU in un secondo

Aurora Serverless ora raggiunge fino a 12 ACU entro un secondo durante lo scale-up, continua fino a 256, e scala ancora a zero dopo. È attivo di default per i cluster su platform version 3 o 4; le versioni 1 e 2 possono passare direttamente alla 4. Controlla la tua con il campo ServerlessV2PlatformVersion di describe-db-clusters. AWS lo inquadra attorno ai workload agentici, il che è corretto: un fan-out di agenti è esattamente il burst che prima passava i suoi primi 30 secondi ad aspettare capacità. La modalità di guasto è il costo. Un cluster che prima saliva gradualmente ora arriva a 12 ACU su un picco che sarebbe stato assorbito a 2. Metti un allarme CloudWatch su ServerlessDatabaseCapacity prima di aggiornare la platform version, non dopo la prima fattura.

Anche questa settimana

Il filo conduttore

Leggi i lanci di Transform accanto a quelli di Lambda e Aurora e il pattern riguarda dove si nascondeva il lavoro manuale. La conversione di schema si nascondeva dietro una regola firewall che nessuno avrebbe approvato. La configurazione post-lancio si nascondeva in un runbook. Il debito tecnico si nascondeva nel backlog. Il tetto di banda di Lambda si nascondeva dietro una quota, e la rampa di Aurora si nascondeva nei primi 30 secondi di ogni picco. AWS ha passato la settimana a eliminare nascondigli. Il costo è ogni volta lo stesso: i default diventano più aggressivi, e il team di piattaforma deve decidere, in anticipo, quali di quei default vuole davvero.

Leggi questo dopo

Per la lettura AI e agenti della stessa settimana, le field notes vivono su ercan.ai. Per consulenza su AWS, cloud, pipeline CI/CD, Linux, GitHub/GitLab e altro, parti da ercanermis.com.

Riferimenti