La settimana del 7 settembre è stata quella in cui AWS Transform per .NET ha smesso di essere uno strumento in cui clicchi ed è diventato un passo che metti in una pipeline. Una CLI da una riga è andata in general availability, la stessa trasformazione ha iniziato a generare unit test per il codice che riscrive, e AWS Transform ha raggiunto GovCloud (US-West) per la migrazione dei server. Intorno, Lambda Managed Instances ha ottenuto un timeout di 90 minuti e Graviton5, gli EBS Volume Clones hanno imparato ad attraversare i confini tra account con ricrittografia, e un Outposts a singolo rack da 42U è andato in GA.

AWS Transform per .NET: CLI, test, GovCloud

Tre lanci, una direzione. Il 9 settembre la modernizzazione .NET di AWS Transform è diventata disponibile in GA via CLI: un singolo comando avvia una trasformazione gestita da AWS in AWS Transform custom, e puoi eseguirla in modo interattivo o inserirla in una pipeline esistente perché giri senza presidio. La trasformazione include 50.000 minuti agente gratuiti al mese ed è disponibile in otto Region: N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt e London.

Il 10 settembre AWS Transform per .NET ha iniziato a generare unit test per il codice modernizzato. Valuta la testabilità dell'applicazione in parallelo con l'assessment .NET standard, pianifica quali classi e metodi coprire (logica di business, controller) ed emette il codice dei test come parte dello stesso job. Opt-in, attivabile all'avvio del job o dopo che la trasformazione è completata, al momento tramite AWS Toolkit for Visual Studio.

E l'8 settembre AWS Transform è arrivato in AWS GovCloud (US-West). Il perimetro conta: si tratta della capacità di migrazione server (VMware, bare metal, Hyper-V, workload database, replica e cutover in una delle due Region GovCloud). Modernizzazione, trasformazione custom e assessment restano per ora nelle Region commerciali.

La CLI è quella che conta: una modernizzazione che vive in un IDE è un progetto, una modernizzazione che gira in CI è un processo. Puoi eseguire la trasformazione su un branch ogni notte, fare il diff dell'output con quello di ieri e trattare l'agente come qualsiasi altro passo di build che passa o non passa. È così che modernizzi 80 servizi invece di 8.

La modalità di guasto per cui pianificare sono i test. Una suite di test generata dal codice trasformato codifica il comportamento del codice trasformato. È una rete di regressione per tutto ciò che cambierai dopo la migrazione, il che ha valore, ma non dimostra che la migrazione abbia preservato il comportamento dell'originale .NET Framework. Per quello ti serve ancora la vecchia suite, oppure test di caratterizzazione scritti contro il vecchio binario ed eseguiti contro il nuovo. Usa i test generati come pavimento, non come firma di approvazione.

Lambda Managed Instances: 90 minuti e Graviton5

Il 9 settembre Lambda ha aggiunto un timeout di funzione di 90 minuti su Lambda Managed Instances per le invocazioni asincrone e da event source mapping, sei volte il tetto di 15 minuti che ha definito l'architettura Lambda per un decennio. Le invocazioni sincrone restano a 15 minuti. Il limite più lungo si applica anche agli step dentro le Lambda durable functions. Lo stesso giorno, Managed Instances ha ottenuto le istanze C9g, C9gd, M9g e M9gd basate su Graviton5, che AWS valuta fino al 25% di prestazioni di compute in più rispetto a Graviton4.

Managed Instances aveva già cambiato il modello di prezzo (economia delle istanze EC2, più richieste concorrenti per istanza) e questo cambiamento completa il ragionamento: è una flotta di compute gestita con un modello di programmazione a forma di funzione. Transcodifiche media, simulazioni Monte Carlo e inferenza batch smettono di aver bisogno di una catena Step Functions o di un task ECS solo per superare il quindicesimo minuto.

Quello che non cambia: le invocazioni asincrone sono at-least-once. Un job di 90 minuti che viene ritentato dopo un fallimento parziale ti costa 90 minuti due volte e, se scrive man mano, lascia un risultato scritto a metà. Chiavi di idempotenza e checkpointing contano di più a 90 minuti, non di meno. E poiché Managed Instances si fattura come capacità EC2, fai esplicitamente il confronto di costo con un task Fargate o un job AWS Batch prima di spostare un workload di lunga durata; il vantaggio è operativo, non automaticamente economico.

Gli EBS Volume Clones attraversano gli account, con chiavi nuove

Il 9 settembre gli EBS Volume Clones hanno iniziato a supportare copie tra account AWS, ricrittografando con una chiave KMS nell'account di destinazione. Il flusso: condividi il volume sorgente tramite AWS RAM, poi l'account di destinazione crea una copia nella stessa Availability Zone. Funziona per tutti i tipi di volume, inclusi i volumi non cifrati e quelli sotto chiavi gestite dal cliente.

Il caso d'uso con cui AWS apre è quello giusto: una copia fresca del volume di un database di produzione in un account di sviluppo isolato. Il vecchio modo era snapshot, condividi snapshot, copia snapshot con una nuova chiave, crea volume: quattro passi e molta attesa. Il nuovo modo è una copia sola con la separazione delle chiavi incorporata, che è ciò che la regola "le chiavi di prod non lasciano mai prod" di una landing zone richiede davvero.

Due cose che un team di piattaforma dovrebbe mettere per iscritto. Primo, "stessa Availability Zone" significa la stessa zona fisica, e i nomi di zona (eu-west-1a) mappano in modo diverso per ogni account. Usa gli AZ ID (euw1-az1) in qualsiasi automazione, altrimenti la copia atterra in una zona che le tue subnet di dev non coprono. Secondo, clonare dati di produzione in dev è un evento di data governance, non un evento di storage. Metti la condivisione RAM dietro un'approvazione e registra chi ha copiato cosa; i meccanismi facili richiedono controlli espliciti.

Anche questa settimana

Il filo conduttore

Ogni titolo di questa settimana ha spostato qualcosa da "lo fa una persona" a "lo fa una pipeline". Transform gira dalla CLI e scrive i propri test. Lambda tiene un job per 90 minuti così smetti di costruirti a mano l'orchestrazione intorno al quindicesimo minuto. EBS copia un volume di prod in dev con la chiave giusta in una sola operazione. Systems Manager ti dice perché l'istanza non è gestita invece di farti indovinare. Ognuno rimuove un passo umano da un processo che prima ne aveva bisogno. Il lavoro per un team di piattaforma è decidere quali di quei passi erano lì per un motivo (l'approvazione prima che i dati di prod lascino prod) e mantenerli, deliberatamente, ora che gli strumenti non te li impongono più.

Leggi questo dopo

Per la lettura AI e agenti della stessa settimana, vedi ercan.ai. Per consulenza su AWS, architettura cloud, pipeline CI/CD, Linux, GitHub o GitLab e il lavoro di piattaforma intorno a loro, parti da ercanermis.com.

Riferimenti