A semana de 7 de setembro foi aquela em que o AWS Transform for .NET deixou de ser uma ferramenta em que você clica e virou um passo que você coloca em um pipeline. Uma CLI de uma linha entrou em disponibilidade geral, a mesma transformação começou a gerar testes unitários para o código que reescreve, e o AWS Transform chegou ao GovCloud (US-West) para migração de servidores. Em volta disso, as Lambda Managed Instances ganharam timeout de 90 minutos e Graviton5, os EBS Volume Clones aprenderam a cruzar fronteiras de conta com re-criptografia, e um Outposts de rack único de 42U entrou em GA.

AWS Transform for .NET: CLI, testes, GovCloud

Três lançamentos, uma direção. Em 9 de setembro o AWS Transform for .NET modernization entrou em disponibilidade geral via CLI: um único comando dispara uma transformação gerenciada pela AWS no AWS Transform custom, e você pode rodá-lo interativamente ou colocá-lo em script dentro de um pipeline existente para rodar sem supervisão. A transformação inclui 50.000 minutos de agente gratuitos por mês e está disponível em oito Regiões: N. Virginia, Mumbai, Tokyo, Seoul, Sydney, Canada (Central), Frankfurt e London.

Em 10 de setembro o AWS Transform for .NET começou a gerar testes unitários para o código modernizado. Ele avalia a testabilidade da aplicação em paralelo com a avaliação padrão de .NET, planeja quais classes e métodos cobrir (lógica de negócio, controllers) e emite o código de teste como parte do mesmo job. Opt-in, habilitado no início do job ou depois que a transformação termina, atualmente pelo AWS Toolkit for Visual Studio.

E em 8 de setembro o AWS Transform chegou ao AWS GovCloud (US-West). O escopo importa: esta é a capacidade de migração de servidores (VMware, bare metal, Hyper-V, cargas de banco de dados, replicação e cutover para qualquer das Regiões GovCloud). Modernização, transformação custom e avaliação ficam nas Regiões comerciais por enquanto.

A CLI é a que importa: uma modernização que vive em uma IDE é um projeto, uma modernização que roda no CI é um processo. Você pode rodar a transformação em um branch toda noite, fazer diff da saída contra a de ontem e tratar o agente como qualquer outro passo de build que passa ou não passa. É assim que se modernizam 80 serviços em vez de 8.

O modo de falha para planejar são os testes. Uma suíte de testes gerada a partir do código transformado codifica o comportamento do código transformado. É uma rede de regressão para tudo que você mudar depois da migração, o que é valioso, mas não prova que a migração preservou o comportamento do original em .NET Framework. Para isso você ainda precisa da suíte antiga, ou de testes de caracterização escritos contra o binário antigo, rodados contra o novo. Use os testes gerados como piso, não como aprovação final.

Lambda Managed Instances: 90 minutos e Graviton5

Em 9 de setembro o Lambda adicionou um timeout de função de 90 minutos nas Lambda Managed Instances para invocações assíncronas e de event source mapping, seis vezes o teto de 15 minutos que definiu a arquitetura Lambda por uma década. Invocações síncronas mantêm 15 minutos. O limite maior também se aplica a passos dentro de Lambda durable functions. No mesmo dia, as Managed Instances ganharam instâncias C9g, C9gd, M9g e M9gd movidas por Graviton5, que a AWS classifica com até 25% mais desempenho de computação que o Graviton4.

As Managed Instances já tinham mudado o modelo de preço (economia de instância EC2, múltiplas requisições concorrentes por instância) e esta mudança completa o raciocínio: é uma frota de computação gerenciada com um modelo de programação no formato de função. Transcodificações de mídia, execuções de Monte Carlo e inferência em lote deixam de precisar de uma cadeia de Step Functions ou de uma task do ECS só para passar do minuto quinze.

O que não muda: invocações assíncronas são at-least-once. Um job de 90 minutos que é repetido depois de uma falha parcial te custa 90 minutos duas vezes e, se escreve conforme avança, deixa um resultado pela metade. Chaves de idempotência e checkpointing importam mais em 90 minutos, não menos. E como as Managed Instances são cobradas como capacidade EC2, faça a comparação de custo contra uma task do Fargate ou um job do AWS Batch explicitamente antes de mover uma carga de longa duração; o ganho é operacional, não automaticamente financeiro.

EBS Volume Clones cruzam contas, com chaves novas

Em 9 de setembro os EBS Volume Clones passaram a suportar cópias entre contas AWS, re-criptografando com uma chave KMS na conta de destino. O fluxo: compartilhe o volume de origem pelo AWS RAM, depois a conta de destino cria uma cópia na mesma Availability Zone. Funciona para todos os tipos de volume, incluindo volumes não criptografados e volumes sob chaves gerenciadas pelo cliente.

O caso de uso que a AWS destaca é o certo: uma cópia fresca de um volume de banco de produção em uma conta de desenvolvimento isolada. O jeito antigo era snapshot, compartilhar snapshot, copiar snapshot com uma chave nova, criar volume, quatro passos e muita espera. O jeito novo é uma cópia com separação de chaves embutida, que é o que a regra "chaves de prod nunca saem de prod" de uma landing zone de fato exige.

Duas coisas que um time de plataforma deveria anotar. Primeiro, "mesma Availability Zone" significa a mesma zona física, e nomes de zona (eu-west-1a) mapeiam de forma diferente por conta. Use AZ IDs (euw1-az1) em qualquer automação, ou a cópia cai em uma zona que suas subnets de dev não cobrem. Segundo, clonar dados de produção para dev é um evento de governança de dados, não de storage. Coloque o compartilhamento RAM atrás de uma aprovação e registre quem copiou o quê; mecanismos fáceis precisam de controles explícitos.

Também nesta semana

O fio condutor

Toda manchete desta semana moveu algo de "uma pessoa faz" para "um pipeline faz". O Transform roda da CLI e escreve seus próprios testes. O Lambda segura um job por 90 minutos para você parar de montar orquestração à mão em volta do minuto quinze. O EBS copia um volume de prod para dev com a chave certa em uma única operação. O Systems Manager diz por que a instância está unmanaged em vez de te fazer adivinhar. Cada um remove um passo humano de um processo que costumava precisar de um. O trabalho de um time de plataforma é decidir quais desses passos estavam lá por um motivo (a aprovação antes de dados de prod saírem de prod) e mantê-los, deliberadamente, agora que o ferramental não te obriga mais.

Leia isto a seguir

Para a leitura de IA e agentes da mesma semana, veja ercan.ai. Se o seu time precisa de ajuda prática com AWS, arquitetura de nuvem, pipelines de CI/CD, Linux, GitHub ou GitLab e o trabalho de plataforma em volta deles, o lado de consultoria vive em ercanermis.com.

Referências