DEV Community: Ed Wantuil

Cloud Sem Falência: O mínimo que você precisa saber de FinOps

Ed Wantuil — Mon, 12 Jan 2026 12:35:44 +0000

Imagine a cena: você trabalha em uma empresa consolidada. Vocês têm aquele rack de servidores físicos robusto, piscando luzinhas em uma sala gelada, com piso elevado e controle biométrico (o famoso On-Premise). Tudo funciona. O banco de dados aguenta o tranco, a latência é zero na rede local. Mas a diretoria decide que é hora de "modernizar".

"Vamos migrar para a Nuvem!", dizem eles, com os olhos brilhando.

A promessa no PowerPoint é sedutora: flexibilidade infinita, segurança gerenciada e o mantra mágico: "pagar só pelo que usar". A migração acontece via Lift-and-Shift (pegar o que existe e jogar na nuvem sem refatorar). A equipe de Infra e Dev comemoram. O Deploy é um sucesso.

Três meses depois, chega a fatura da AWS.

O diretor financeiro (CFO) não apenas cai da cadeira; ele convoca uma reunião de emergência. O custo, que antes era uma linha fixa e previsível no balanço anual, triplicou e agora flutua violentamente.

O que deu errado? Simples: A engenharia tratou a Nuvem como um Data Center físico, apenas alugado.

Hoje, vamos falar sobre os riscos dessa mudança e como aplicar FinOps não como burocracia, mas como requisito de arquitetura.

(Nota: Usaremos a AWS nos exemplos por ser a stack padrão de mercado, mas a lógica se aplica integralmente ao Azure, GCP e OCI).

🦄 A Ilusão da Mágica: CAPEX vs. OPEX na Engenharia

Para entender a conta da AWS, você precisa entender como o dinheiro sai do cofre da empresa. A mudança da nuvem não é apenas sobre onde o servidor roda, é sobre quem assume o risco do desperdício.

1. CAPEX (Capital Expenditure): A Lógica do "PC Gamer"

CAPEX é Despesa de Capital. É comprar a "caixa". Imagine que você vai montar um PC Gamer High-End. Você gasta R$ 20.000,00 na loja. Doeu no bolso na hora, certo? Mas depois que o PC está na sua mesa:

Custo Marginal Zero: Se você jogar Paciência ou renderizar um vídeo em 8K a noite toda, não faz diferença financeira para o seu bolso (tirando a conta de luz, que é irrisória perto do hardware). O dinheiro já foi gasto (Sunk Cost).
O Comportamento do Engenheiro (On-Premise): Como o processo de compra é lento (meses de cotação e aprovação), você tem medo de faltar recurso.
- Mentalidade: "Vou pedir um servidor com 64 Cores, mesmo precisando de 16. Se sobrar, melhor. O hardware é nosso mesmo."
- Código: Eficiência não é prioridade financeira. Um código mal otimizado que consome 90% da CPU não gera uma fatura extra no fim do mês.

2. OPEX (Operational Expenditure): A Lógica do Uber

OPEX é Despesa Operacional. É o custo de funcionamento do dia a dia. Na nuvem, você não comprou o carro; você está rodando de Uber 24 horas por dia.

Custo Marginal Real: Cada minuto parado no sinal custa dinheiro. Cada desvio de rota custa dinheiro.
O Comportamento do Engenheiro (Cloud): Aqui, a ineficiência é taxada instantaneamente.
- Mentalidade: Aquele servidor de 64 cores e 512GB de ram parado esperando tráfego é como deixar o Uber te esperando na porta do escritório enquanto você trabalha. O taxímetro está rodando.
- Código: Um loop infinito ou uma query sem índice no banco de dados não deixa apenas o sistema lento; ele queima dinheiro vivo.

Comparativo para Desenvolvedores (Salve isso)

Feature	CAPEX (On-Premise / Hardware Próprio)	OPEX (Cloud / AWS / Azure)
Commit Financeiro	Você paga tudo antes de usar (Upfront).	Você paga depois de usar (Pay-as-you-go).
Latência de Aprovação	Alta. Precisa de reuniões, assinaturas e compras.	Zero. Um `terraform apply` gasta dinheiro instantaneamente.
Risco de Capacidade	Subutilização. Comprar um servidor monstro e usar 10%.	Conta Surpresa. Esquecer algo ligado ou escalar infinitamente.
Otimização de Código	Melhora performance, mas não reduz a fatura do hardware.	Reduz diretamente a fatura. Código limpo = Dinheiro no caixa.

Por que isso afeta a sua Arquitetura?

Se você desenha uma arquitetura pensando em CAPEX (Mundo Físico) e a implementa em OPEX (Nuvem), você cria um desastre financeiro.

No CAPEX, a estratégia de defesa é: "Superdimensionar para garantir estabilidade". (Compre o maior servidor possível).
No OPEX, a estratégia de defesa é: "Elasticidade". (Comece com o menor servidor possível e configure para crescer sozinho apenas se necessário).

💸 Os 8 Cavaleiros do Apocalipse Financeiro na AWS

Na nuvem, os maiores vilões raramente são tecnologias complexas de IA ou Big Data. Quase sempre são decisões arquiteturais preguiçosas e falta de governança.

1. Instâncias "Just in Case": O Custo do Seguro Psicológico

O sobredimensionamento é um vício comum: o desenvolvedor sobe uma instância m5.2xlarge (8 vCPUs, 32GB RAM) não porque a aplicação exige, mas porque ele "não quer ter dor de cabeça". É o provisionamento baseado no medo, criando uma margem de segurança gigantesca e cara para evitar qualquer risco hipotético de lentidão.

A realidade nua e crua aparece no CloudWatch: na maior parte do tempo, essa supermáquina opera com apenas 12% de CPU e usa uma fração da memória. Pagar por uma 2xlarge para rodar essa carga é como fretar um ônibus de 50 lugares para levar apenas 4 pessoas ao trabalho todos os dias. Você está pagando pelo "espaço vazio" e pelo motor potente do ônibus, enquanto um carro popular (t3.medium) faria o mesmo trajeto com o mesmo conforto e muito mais economia.

2. Ambientes Zumbis: A Torneira Aberta Fora do Expediente

"Ambientes Zumbis" são servidores de Desenvolvimento e Homologação que operam como cópias fiéis da Produção, mas sem a audiência dela. Eles permanecem ligados e faturando às 3 da manhã de um domingo, consumindo recursos de nuvem para processar absolutamente nada. Manter esses servidores ligados 24/7 é o equivalente digital de deixar o ar-condicionado de um escritório ligado no máximo durante todo o fim de semana, com o prédio completamente vazio.

O impacto financeiro atua como um multiplicador de desperdício. Se você mantém três ambientes (Dev, Staging e Produção) com arquiteturas similares ligados ininterruptamente, seu custo base é 300% do necessário. A matemática é cruel: uma semana tem 168 horas, mas seus desenvolvedores trabalham apenas 40. Você está pagando por 128 horas de ociosidade pura por máquina, todas as semanas.

A primeira cura para esse desperdício é o agendamento automático. Utilizando soluções como o AWS Instance Scheduler (ou Lambdas simples), configuramos os ambientes para "acordar" às 08:00 e "dormir" às 20:00, de segunda a sexta-feira. Apenas essa automação básica, sem alterar uma linha de código da aplicação, reduz a fatura desses ambientes não-produtivos em cerca de 70%.

3. O Esquecimento Crônico: O Custo do Limbo

Um dos "pegadinhas" mais comuns da nuvem acontece no momento de desligar as luzes: quando você termina uma instância EC2, o senso comum diz que a cobrança para. O erro está em assumir que a máquina e o disco são uma peça única. Por padrão, ao "matar" o servidor, o volume de armazenamento (EBS) acoplado a ele muitas vezes sobrevive, entrando num estado de limbo financeiro.

O resultado é o acúmulo de EBS Órfãos: centenas de discos no estado "Available" (não atrelados a ninguém), cheios de dados inúteis ou completamente vazios, pelos quais você paga o preço cheio do gigabyte provisionado. É comparável a vender seu carro, mas esquecer de cancelar o aluguel da vaga de garagem: o veículo não existe mais, mas a cobrança pelo espaço que ele ocupava continua chegando todo mês na fatura.

A situação piora com os Elastic IPs (EIPs), que possuem uma lógica de cobrança invertida e punitiva. Devido à escassez mundial de endereços IPv4, a AWS não cobra pelo IP enquanto você o utiliza, mas começa a cobrar assim que ele fica ocioso. É como uma "multa por não uso": se você reserva um endereço IP e não o atrela a uma instância em execução, você paga por estar "segurando" um recurso escasso sem necessidade.

4. O Cemitério de Dados no S3

Buckets S3 tendem a virar "cemitérios digitais" onde logs, backups e assets se acumulam indefinidamente. O erro crucial não é guardar os dados, mas a falta de estratégia: manter 100% desse volume na classe S3 Standard, pagando a tarifa mais alta da AWS por arquivos que ninguém acessa há meses.

Para entender o prejuízo, imagine o S3 Standard como uma loja no corredor principal de um shopping: o aluguel é caríssimo porque o acesso é imediato e fácil (baixa latência). Manter logs de 2022 nessa classe é como alugar essa vitrine premium apenas para estocar caixas de papelão velhas. Dados "frios", que raramente são consultados, não precisam estar à mão em milissegundos; eles podem ficar num armazém mais distante e barato.

A solução é o S3 Lifecycle, que automatiza a logística desse "estoque". Primeiro, ele atua na Transição: move automaticamente os dados que envelhecem da "vitrine" (Standard) para o "armazém" (S3 Glacier). No Glacier, você paga uma fração do preço, aceitando que o resgate do arquivo leve alguns minutos ou horas (maior latência), o que é aceitável para arquivos de auditoria ou backups antigos.

Por fim, o Lifecycle resolve o acúmulo de lixo através da Expiração. Além de mover dados, você configura regras para deletar objetos definitivamente após um período, como remover logs temporários após 7 dias. Isso garante a higiene do ambiente, impedindo que você pague aluguel (seja no shopping ou no armazém) por dados inúteis que não deveriam mais existir.

5. Snapshots: O Colecionador de Backups Fantasmas

Backups são a apólice de seguro da sua infraestrutura, mas a facilidade de criar snapshots na AWS gera um comportamento perigoso de acumulação. O erro clássico é configurar uma automação de snapshot diário e definir a retenção para "nunca" ou prazos absurdos como 5 anos. Embora os snapshots sejam incrementais (salvando apenas o que mudou), em bancos de dados transacionais com muita escrita, o volume de dados alterados cresce rápido, e a fatura acompanha.
Para visualizar o desperdício, imagine que você compra o jornal do dia para ler as notícias. É útil ter os jornais da última semana na mesa para referência rápida. Mas guardar uma pilha de jornais diários de três anos atrás na sua sala ocupa espaço valioso e custa dinheiro, sendo que a chance de você precisar saber a "cotação do dólar numa terça-feira específica de 2021" é praticamente nula. Você está pagando armazenamento premium por "jornais velhos" que não têm valor de negócio.

6. Licenciamento Comercial (O Custo Invisível)

Muitas empresas focam tanto em otimizar CPU e RAM que esquecem o elefante na sala: o custo de software. Ao rodar instâncias com Windows Server ou SQL Server Enterprise na AWS no modelo "License Included", você não paga apenas pela infraestrutura; você paga uma sobretaxa pesada pelo direito de uso do software proprietário. Esse custo é embutido na tarifa por hora e, em máquinas grandes, a licença pode custar mais caro que o próprio hardware.
Para ilustrar a desproporção, usar o SQL Server Enterprise para uma aplicação que não utiliza funcionalidades avançadas (como Always On complexo ou compressão de dados específica) é como fretar um jato executivo apenas para ir comprar pão na padaria. O objetivo (armazenar e recuperar dados) é cumprido, mas você está pagando por um veículo de luxo quando uma bicicleta ou um Uber resolveria o problema com a mesma eficiência e uma fração do custo.

A primeira camada de solução é a Otimização de Edição. É comum desenvolvedores solicitarem a versão Enterprise por "garantia" ou hábito, sem necessidade técnica real. Uma auditoria simples muitas vezes revela que a versão Standardatende a todos os requisitos da aplicação. Fazer esse downgrade reduz a fatura de licenciamento imediatamente, sem exigir mudanças drásticas na arquitetura ou no código.

7. Dilema Geográfico: Reduzindo a Fatura pela Metade

Hospedar aplicações na região sa-east-1 (São Paulo) carrega um ágio pesado: o "Custo Brasil" digital faz com que a infraestrutura local custe, cerca de 50% a mais do que na us-east-1 (N. Virgínia). Migrar workloads para os EUA é, frequentemente, a manobra de FinOps com maior retorno imediato (ROI): você corta a fatura desses recursos praticamente pela metade apenas alterando o CEP do servidor, acessando o mesmo hardware por uma fração do preço.

O principal bloqueador costuma ser o medo da LGPD, mas a crença de que a lei exige residência física dos dados no Brasil é um mito. O Artigo 33 permite a transferência internacional para países com proteção adequada (como os EUA), desde que coberto por contratos padrão. A legislação foca na segurança e privacidade do dado, não na sua latitude e longitude geográfica.

Quanto à técnica, a latência para a Virgínia (~120ms) é imperceptível para a maioria das aplicações web, sistemas internos e dashboards. A estratégia inteligente é adotar uma região como US East como padrão para maximizar a economia, reservando São Paulo apenas para exceções que realmente exigem resposta em tempo real (como High Frequency Trading), evitando pagar preço de "primeira classe" para cargas de trabalho que rodariam perfeitamente na econômica.

8. Serverless: A Faca de Dois Gumes

"Serverless" é computação sem gestão de infraestrutura (como AWS Lambda ou DynamoDB). Diferente de alugar um servidor fixo mensal, aqui você paga apenas pelos milissegundos que seu código executa ou pelo dado que você lê. É como a conta de luz: você só paga se o interruptor estiver ligado.

A Estratégia: Para uso esporádico, é imbatível. Mas e para uso constante? Também pode ser uma excelente escolha! Embora a fatura de infraestrutura possa vir mais alta do que em servidores tradicionais, você elimina o trabalho pesado de manutenção. Muitas vezes, é financeiramente mais inteligente pagar um pouco mais para a AWS do que custear horas de engenharia ou contratar uma equipe dedicada apenas para gerenciar servidores, aplicar patches de segurança e configurar escalas. O segredo é olhar para o Custo Total (TCO), e não apenas para a linha de processamento na fatura.

🕵️‍♂️ FinOps: Engenharia Financeira na Prática

FinOps não é apenas sobre "pedir desconto" ou cortar gastos; é a mudança cultural que descentraliza a responsabilidade do custo, empoderando engenheiros a tomar decisões baseadas em dados, não em palpites. Para que essa cultura saia do papel, ela precisa se apoiar em um tripé de governança robusto: a visibilidade granular garantida pelo tageamento correto (saber quem gasta), a segurança operacional monitorada pelo AWS Budgets (saber quando gasta) e a eficiência financeira obtida através dos Modelos de Compra inteligentes (saber como pagar). Sem integrar essas três frentes, a nuvem deixa de ser um acelerador de inovação para se tornar um passivo financeiro descontrolado.

1. TAGs: Sem Etiquetas, Sem Dados 🏷️

No AWS Cost Explorer, uma infraestrutura sem tags opera como uma "caixa preta" financeira: você encara uma fatura de $50.000, mas é incapaz de discernir se o rombo veio de um modelo crítico de Data Science ou de um cluster Kubernetes esquecido por um estagiário.
Utiliza tags como custo:centro, app:nome, env e dono no momento dos recursos transformara números genéricos em rastreáveis, permitindo que cada centavo gasto tenha um responsável atrelado, eliminando definitivamente a cultura de que "o custo da nuvem não é problema meu".

2. AWS Budgets e Detecção de Anomalias 🚨

Não espere o fim do mês. Configure o AWS Budgets para alertar quando o custo projetado (forecasted) ultrapassar o limite.

Dica: Ative o Cost Anomaly Detection. Ele usa Machine Learning para identificar picos anormais.
- Exemplo: Um deploy errado fez a cahamada para um Lambda entrar em loop infinito. O Anomaly Detection te avisa em horas, não no fim do mês.

3. Modelos de Compra: O Fim do On-Demand 💸

Operar 100% em On-Demand é pagar voluntariamente um "imposto sobre a falta de planejamento". A maturidade em FinOps exige abandonar o preço de varejo e adotar um mix estratégico: cubra sua carga de trabalho base (aquela que roda 24/7) com Savings Plans, que oferecem descontos de até 72% em troca de fidelidade, e mova cargas tolerantes a interrupções, como processamento de dados e pipelines de CI/CD, para Spot Instances, aproveitando a capacidade ociosa da AWS por até 10% do valor original.

Ignorar essa estratégia e manter tudo no On-Demand é uma decisão consciente de desperdiçar orçamento que poderia ser reinvestido em inovação.

🧠 Dev Assina o Código e o Cheque

No mundo On-Premise, um código ruim apenas deixava o sistema lento. Na Nuvem, código ineficiente gera uma fatura imediata. A barreira entre Engenharia e Financeiro desapareceu: cada linha de código é uma decisão de compra executada em tempo real. O desenvolvedor não consome apenas CPU, ele consome o orçamento da empresa.

Para entender o impacto, veja o preço das más práticas:

O Custo da Leitura: Uma query sem "WHERE" ou um Full Table Scan no DynamoDB não é apenas um problema de performance; você está pagando unidades de leitura para ler milhares de linhas inúteis. É como comprar a biblioteca inteira para ler uma única página.
O Custo da Ineficiência: Um código com vazamento de memória engana o Auto Scaling. O sistema provisiona 10 servidores para fazer o trabalho de 2, desperdiçando dinheiro para compensar código ruim.
O Custo do Ruído: Logs em modo VERBOSE esquecidos em produção são vilões. O CloudWatch cobra caro pela ingestão. Enviar gigabytes de "log de lixo" é literalmente pagar frete aéreo para transportar entulho.

A Cultura de Engenharia Consciente de Custos:

Estimativa no Refinamento: O custo deve ser debatido antes do código existir. Durante o Refinamento, ao definir a arquitetura, faça a pergunta: "Quais recursos vamos usar e quanto isso vai custar com a volumetria esperada?". Se a solução técnica custa $1.000 para economizar $50 de esforço manual, ela deve ser vetada ali mesmo.
Feedback Loop: O desenvolvedor precisa ver quanto o serviço dele custa. Painéis do Grafana ou Datadog devem mostrar não só a latência da API, mas o custo diário dela. Só existe responsabilidade quando existe consciência do preço.
Cerimônia de Custo (FinOps Review): Estabeleça uma reunião recorrente dedicada a olhar o "Extrato da Conta". O time analisa os custos atuais, investiga picos não planejados da semana anterior e discute ativamente: "Existe alguma oportunidade de desligar recursos ou otimizar este serviço agora?". É a higiene financeira mantendo o projeto saudável.

🌐 O Mundo Híbrido e Multicloud: Complexidade é Custo

Nem tudo precisa ir para a AWS, e nem tudo deve sair do seu Data Center local. A maturidade em nuvem não significa "desligar tudo o que é físico", mas sim saber onde cada peça do jogo custa menos. Empresas podem operam em modelos híbridos estratégicos:

O Lugar do Legado (On-Premise): Aquele banco de dados gigante ou mainframe que já está quitado, não cresce mais e roda de forma previsível? Deixe onde está. Migrar esses monstros para a nuvem apenas copiando e colando ("Lift-and-Shift") costuma ser um desastre financeiro. Na nuvem, você paga caro por performance de disco (IOPS) e memória que, no seu servidor físico, já são "gratuitos".
O Lugar da Inovação (Nuvem): Seu site, aplicativos móveis e APIs que precisam aguentar milhões de acessos num dia e zero no outro? Leve para a nuvem. Lá você paga pela elasticidade e pelo alcance global que o servidor físico não consegue entregar.

Cuidado com a Armadilha Multicloud
Muitos gestores caem na tentação de usar AWS, Azure e Google Cloud ao mesmo tempo sob o pretexto de "evitar ficar preso a um fornecedor" (Vendor Lock-in). Na prática, para a maioria das empresas, isso triplica o custo operacional. Você precisará de equipes especialistas em três plataformas diferentes, perderá descontos por volume (diluindo seu gasto) e pagará taxas altíssimas de transferência de dados (Egress) para fazer as nuvens conversarem entre si. Complexidade técnica é, invariavelmente, custo financeiro.

Como gerenciar essa infraestrutura sem perder o controle? O uso de ferramentas como Terraform ou OpenTofu. Com elas, criar um servidor não é mais clicar em botões numa tela, mas sim escrever um arquivo de texto (código).

Isso habilita a Revisão de Código Financeira:

Um desenvolvedor propõe uma mudança no código da infraestrutura.
Antes de aprovar, o time revisa num "Pull Request".
A pergunta muda de "O código está certo?" para "Por que você alterou a máquina de micro para extra-large?".

O Code Review de infraestrutura torna-se a primeira e mais barata linha de defesa do FinOps, barrando gastos desnecessários antes mesmo que eles sejam criados.

Conclusão: A Nuvem não é um Destino, é um Modelo Econômico

Migrar para a nuvem não é apenas trocar de servidor; é adotar um novo paradigma operacional e financeiro. Tratar a AWS como um "datacenter glorificado" é o caminho mais rápido para transformar a inovação em prejuízo: ao fazer isso, você acaba pagando a diária de um hotel cinco estrelas apenas para estocar caixas de papelão que poderiam estar num depósito simples.

A virada de chave acontece na cultura. Comece pelo básico bem feito: aplique Tags rigorosamente, automatize a limpeza de recursos e traga o custo para o centro das decisões de arquitetura. Lembre-se que, neste novo mundo, a excelência técnica é inseparável da eficiência financeira: o melhor código não é apenas o que funciona, é o que entrega valor máximo consumindo o mínimo de orçamento.

Java 25: tudo que mudou desde o Java 21 em um guia prático

Ed Wantuil — Sun, 28 Sep 2025 21:58:58 +0000

Setembro de 2025 está terminando e, com ele, o Java 25 (LTS), finalmente aquela versão “para levar pra produção sem dor de cabeça”. Confesso: eu quase não acompanho os releases não-LTS. Resultado? Um combo acumulado de Java 22, 23, 24 e 25 para digerir de uma vez só. Se você está igual, respira: este é o guia de sobrevivência pra entender o que realmente mudou desde a última LTS (Java 21) e decidir o que vale priorizar no seu ambiente.

Pra calibrar a expectativa: nesse período pintaram dezenas de JEPs, mas só uma parte virou funcionalidade definitiva. O resto ainda está em preview/incubation ou acabou descartado. Traduzindo: dá pra fechar esse “livro de pendências” sem precisar virar noite, aqui você encontra tudo resumido em blocos práticos.

O versionamento do Java

Quando a gente olha a linha do tempo do Java, dá pra ver as versões com suporte e até quando podemos contar com suas atualizações:

Versão	Fim do suporte
Java 25	Setembro de 2030
Java 21	Dezembro de 2029
Java 17	Outubro de 2027
Java 11	Outubro de 2027
Java 8	Novembro de 2026

O modelo de versionamento pode parecer meio esquisito. Por exemplo: o Java 22 foi aposentado no mesmo dia em que o 23 saiu da concessionária. É assim mesmo: versões não-LTS são como modelos especiais de carro, ficam pouco tempo no mercado, servem pra testar novos recursos, mas logo dão lugar ao próximo lançamento. Se você comprou um desses, logo precisa pensar em trocar.

Já as versões LTS (Long Term Support) são os modelos de linha, que a montadora garante peça e manutenção por anos. Na prática, isso significa receber atualizações de segurança e correções de bugs por muito mais tempo. É por isso que, em sistemas de produção, quase sempre se aposta no LTS: é como escolher um carro popular que qualquer oficina sabe arrumar, em vez de um protótipo cheio de tecnologia nova que pode te deixar parado no acostamento.

As atualizações acumulativas

Aqui vamos revisar o pacote de mudanças do Java 22 até o Java 25, mas com um filtro importante: só entram as funcionalidades que já são definitivas. Ou seja, vamos deixar de fora tudo que ainda está em preview ou incubation, porque não são recomendadas para uso em produção.

Mas antes, vale um parêntese: o que é uma JEP?
JEP significa JDK Enhancement Proposal (Proposta de Melhoria do JDK). É o documento oficial onde a comunidade do OpenJDK descreve e justifica uma mudança na linguagem ou na plataforma. Uma JEP pode ser:

Definitiva → já aprovada, implementada e pronta pra produção.
Preview/Incubation → disponível para testes, mas ainda sujeita a mudanças.
Rejeitada ou Retirada → proposta que não avançou.

Neste guia, vou focar apenas nas JEPs definitivas, porque são elas que realmente impactam quem precisa manter sistemas rodando em produção com segurança.

🧹 Garbage Collectors

O Garbage Collector (GC) é quem cuida da limpeza de memória na JVM. Ele identifica objetos que não têm mais uso e libera esse espaço, evitando os temidos memory leaks. Entre o Java 22 e o 25, várias melhorias chegaram para reduzir pausas, melhorar desempenho e evoluir coletores já existentes.

JEP 423: Fixação de Regiões para o G1 (Java 22)

O G1 ganhou a capacidade de “prender” (pin) regiões do heap enquanto código nativo (JNI) está em áreas críticas. Na prática, isso permite que o GC continue trabalhando normalmente nas outras regiões sem precisar parar tudo.

📖 Detalhes na JEP 423

JEP 474: ZGC - Modo geracional como padrão (Java 23)

O ZGC agora roda em modo geracional por padrão. O antigo modo não-geracional foi marcado como deprecado e deve ser removido em versões futuras.

Antes: quem usava -XX:+UseZGC ativava o ZGC clássico (não-geracional).
Agora: o mesmo comando já ativa o ZGC Geracional, que separa objetos novos dos de longa duração, otimizando coleta de lixo.

📖 Detalhes na JEP 474

JEP 475: Expansão tardia das barreiras do G1 (Java 24)

O G1 ganhou uma simplificação no jeito que lida com as suas barreiras (os pontos de anotação de acessos à memória). Agora, a expansão dessas barreiras no compilador C2 acontece apenas na fase final de emissão de código.

Antes: o compilador expandia essas instruções mais cedo, o que aumentava custo de compilação JIT em tempo e memória.
Agora: com a expansão adiada, o compilador gasta menos recursos no startup e durante o aquecimento da aplicação.

📖 Detalhes na JEP 475

JEP 490: ZGC: Remover o modo não-geracional (Java 24)

O ZGC completa a transição: o modo não-geracional foi removido de vez.

Antes: era possível escolher entre -XX:+ZGenerational e -XX:-ZGenerational para ligar ou desligar o modo.
Agora: ao usar apenas -XX:+UseZGC, você sempre roda o ZGC Geracional. As flags antigas continuam aceitas, mas só geram aviso de obsolescência.

📖 Detalhes na JEP 490

JEP 521: Shenandoah geracional (Java 25)

O Shenandoah também entrou na onda geracional. O modo, que antes era experimental, agora é promovido a recurso de produto.

Antes: precisava usar -XX:+UnlockExperimentalVMOptions para habilitar.
Agora: pode ser ativado diretamente, sem desbloquear flags experimentais.

Importante: o padrão ainda é o Shenandoah de uma geração. Para usar o geracional, é preciso habilitar explicitamente:

-XX:+UseShenandoahGC -XX:ShenandoahGCMode=generational

📖 Detalhes na JEP 521

💻 JVM

A JVM precisa carregar, ligar e otimizar classes o mais rápido possível. Isso reduz o tempo de inicialização (startup) e deixa a performance mais previsível em produção. Nos últimos releases, o foco foi acelerar esse arranque e também preparar terreno para otimizações antecipadas (AOT).

JEP 458: Executar Programas de Código-Fonte Multiarquivo (Java 22)

Agora é possível executar, diretamente com o comando java, um programa que tenha vários arquivos .java, sem precisar compilar antes com javac.

Antes: só era possível rodar scripts de um único arquivo.
Agora: você pode organizar seu código em múltiplos arquivos e ainda assim rodar de forma imediata.

Limite: esse recurso não resolve gerenciamento de dependências externas, a ideia aqui é acelerar o desenvolvimento inicial, não substituir ferramentas de build.

📖 Detalhes na JEP 458

JEP 491: Sincronizar threads virtuais sem fixação (Java 24)

Essa JEP elimina quase todos os casos em que threads virtuais ficavam “presas” (pinning) ao usar synchronized.

Antes: ao bloquear dentro de métodos/blocos sincronizados ou em Object.wait(), a thread virtual mantinha ocupada a thread de plataforma, limitando a escalabilidade.
Agora: nesses cenários, a thread virtual libera a thread de plataforma para que outras possam avançar.

Atenção: ainda pode haver fixação ao entrar ou voltar de código nativo (JNI/FFM).

📖 Detalhes na JEP 491

JEP 483: Carregamento e Vinculação de Classes Antecipados (AOT) (Java 24)

Essa JEP introduz um cache AOT (Ahead-of-Time) que guarda classes já lidas, analisadas, carregadas e vinculadas. Assim, em execuções seguintes, essas classes ficam “pré-prontas” logo no início.

Como funciona: você roda uma execução de treinamento para gerar o cache. Depois, a JVM reaproveita esse cache em execuções futuras.
Impacto prático: o tempo de startup melhora sensivelmente, sem precisar alterar código-fonte.

📖 Detalhes na JEP 483

JEP 484: API de Arquivos de Classe (Java 24)

Essa JEP traz uma API oficial para lidar com arquivos de classe. A ideia é permitir que ferramentas e frameworks acompanhem as mudanças no formato de bytecode a cada release do JDK sem depender de bibliotecas externas que precisam ser atualizadas separadamente.

Antes: cada ferramenta precisava de libs de terceiros (como ASM) para interpretar/gerar bytecode.
Agora: a própria API do JDK oferece suporte direto.

📖 Detalhes na JEP 484

JEP 493: Vinculação de imagens de tempo de execução sem JMODs (Java 24)

Essa JEP permite que o jlink crie imagens de runtime sem precisar dos arquivos JMOD do JDK.

Benefício direto: reduz em cerca de 25% o tamanho da distribuição do JDK quando essa opção é habilitada na construção.
Limitação: essa funcionalidade é ativada em tempo de build do JDK, então nem todos os fornecedores vão disponibilizar.

📖 Detalhes na JEP 493

JEP 514: Ergonomia de Linha de Comando para AOT (Java 25)

Essa JEP simplifica a criação de caches AOT (ahead-of-time), que ajudam a reduzir o tempo de startup das aplicações Java.

Antes (Java 24): era preciso seguir um fluxo em duas etapas para gerar e depois montar o cache AOT.
Agora (Java 25): você pode fazer tudo em uma única execução da JVM, por exemplo:

  java -XX:AOTCacheOutput=meu-cache.aot MinhaApp.java

📖 Detalhes na JEP 514

JEP 515: Ahead-of-Time Method Profiling (Java 25)

Essa JEP permite disponibilizar, já na inicialização da JVM, perfis de execução de métodos coletados em uma execução de treinamento e armazenados no cache AOT.

Antes: o compilador JIT precisava observar a execução em tempo real para decidir quais métodos valiam a pena otimizar, o que aumentava o tempo de aquecimento (warmup).
Agora: com os perfis já prontos no cache AOT, o JIT pode gerar código nativo desde o primeiro momento.

📖 Detalhes na JEP 515

JEP 518: JFR: Amostragem Cooperativa (Java 25)

Essa JEP torna o JDK Flight Recorder (JFR) mais estável e confiável ao coletar amostras de pilha.

Antes: o JFR podia andar na pilha de threads a qualquer momento, o que aumentava o risco de travamentos ou leituras inconsistentes, especialmente quando usado junto a GCs concorrentes como o ZGC.
Agora: a amostragem passa a acontecer em safepoints, reduzindo esses riscos.

📖 Detalhes na JEP 518

JEP 519: Cabeçalhos de Objetos Compactos (Java 25)

Essa JEP promove os Cabeçalhos de Objetos Compactos (introduzidos de forma experimental na JEP 450 / JDK 24) a recurso de produto.

O que muda: o tamanho do cabeçalho de cada objeto é reduzido.
Impacto prático: melhora a densidade de implantação e o uso de memória, especialmente em aplicações que lidam com muitos objetos pequenos.
Limite: não é o padrão; precisa ser habilitado via flag da JVM. Nenhuma API ou código da aplicação precisa ser alterado.

📖 Detalhes na JEP 519

JEP 520: JFR: Medição de Tempo e Rastreamento de Métodos (Java 25)

Essa JEP amplia o JDK Flight Recorder (JFR) com dois novos eventos:

jdk.MethodTiming → mede o tempo gasto por método.
jdk.MethodTrace → registra a sequência de chamadas entre métodos.

📖 Detalhes na JEP 520

📝 Linguagem

A linguagem Java também recebeu refinamentos para tornar o código mais conciso, expressivo e moderno. Essas melhorias ajudam a reduzir a verbosidade histórica e trazem novas formas de escrever programas.

JEP 454: API de Funções e Memória Externas (FFM) (Java 22)

Essa JEP entrega uma API oficial para:

Chamar funções nativas (fora da JVM).
Acessar memória externa com segurança.

Impacto prático: substitui em muitos cenários o frágil JNI, simplificando a integração com bibliotecas C/C++ e o trabalho com buffers off-heap. Isso melhora produtividade e desempenho em áreas como I/O, codecs, drivers e até ciência de dados.

💻 Exemplo de código

📖 Detalhes na JEP 454

JEP 456: Variáveis e Padrões Sem Nome (Java 22)

Essa JEP permite usar o sublinhado _ quando uma variável ou um componente de padrão é obrigatório pela sintaxe, mas você não vai usá-lo depois.

Onde usar: em catch, switch com padrões, for e lambdas.
Objetivo: reduzir “ruído” no código e deixar claro que aquela variável não tem utilidade real.
Detalhe importante: o _ passou a ser uma palavra-chave, ou seja, não pode mais ser usado como identificador comum.

Impacto prático: código mais limpo, com menos variáveis “descartáveis” fingindo que seriam usadas.

💻 Exemplos: Antes da JEP 456 | Depois da JEP 456

📖 Detalhes na JEP 456

JEP 467: Comentários de Documentação em Markdown (Java 23)

Agora o JavaDoc aceita comentários escritos em Markdown, além do tradicional HTML e das tags @.

Antes: a documentação precisava ser feita em HTML + tags, o que deixava tudo mais “engessado”.
Agora: dá para escrever listas, títulos e links de forma mais natural com Markdown.

Impacto prático:

Documentação mais legível direto no código.
Menos atrito para escrever e manter comentários.
Compatibilidade preservada: você pode misturar HTML, tags JavaDoc e Markdown sem problemas.

💻 Exemplos: Antes da JEP 467 | Depois da JEP 467

📖 Detalhes na JEP 467

JEP 485: Stream Gatherers (Java 24)

Essa JEP adiciona o método Stream.gather(Gatherer) e a classe utilitária Gatherers, permitindo criar operações intermediárias personalizadas em streams.

Antes: para casos como janelas, varreduras incrementais ou deduplicação por critério, era preciso fazer “malabarismos” com collect e listas temporárias.
Agora: dá pra implementar essas operações direto no pipeline, de forma clara e reutilizável.

Impacto prático:

Pipelines de stream mais legíveis e expressivos.
Menos código extra e menos estruturas temporárias.

💻 Exemplos: Antes da JEP 485 | Depois da JEP 485

📖 Detalhes na JEP 485

JEP 506: Valores de Escopo (Java 25)

Essa JEP introduz os valores de escopo, uma forma mais simples e segura de compartilhar dados imutáveis dentro da mesma thread e também com threads filhas (incluindo threads virtuais).

Antes: o recurso típico era o ThreadLocal, mas ele é difícil de raciocinar, tem custo maior e pode causar vazamentos de memória se não for bem gerenciado.
Agora: os valores de escopo oferecem uma alternativa mais clara e leve, funcionando muito bem em conjunto com concorrência estruturada.

Impacto prático:

Código mais fácil de entender e manter.
Menor custo para compartilhar dados entre chamadas e threads relacionadas.
Evita armadilhas comuns do ThreadLocal.

💻 Exemplos: Antes da JEP 506 | Depois da JEP 506

📖 Detalhes na JEP 506

JEP 511: Declarações de Importação de Módulo (Java 25)

Essa JEP permite importar, em uma única linha, todas as classes públicas dos pacotes exportados por um módulo, usando:

import module <nome>;

Antes: era necessário listar uma sequência longa de import, pacote por pacote.
Agora: basta importar o módulo inteiro, incluindo exportações transitivas.

Impacto prático:

Código mais limpo, sem listas enormes de imports.
Facilita o uso de APIs modulares, mesmo quando seu código não está dentro de um módulo, o import modulefunciona também em projetos não modularizados.

💻 Exemplos: Antes da JEP 511 | Depois da JEP 511

📖 Detalhes na JEP 511

JEP 512: Arquivos de Fonte Compactos e `main` de Instância (Java 25)

Essa JEP é uma das que mais simplificam o “Hello, World” em Java.

Antes: precisava declarar classe, método main estático, receber String[] args e importar explicitamente.
Agora:
- O main pode ser de instância (sem static e sem String[] args).
- Você pode usar arquivos de fonte compactos, sem declarar a classe explicitamente.
- Há a classe utilitária java.lang.IO para E/S simples.
- Os imports básicos do java.base vêm automáticos.

Impacto prático:

Muito menos cerimônia para escrever scripts e exemplos didáticos.
Ideal para ensino e prototipagem, sem criar um dialeto separado da linguagem: é Java de verdade, só que mais enxuto.

💻 Exemplos: Antes da JEP 512 | Depois da JEP 512

📖 Detalhes na JEP 512

JEP 513: Corpos de Construtores Flexíveis (Java 25)

Essa JEP permite escrever instruções antes de chamar super(...) ou this(...) dentro de um construtor.

Antes: qualquer lógica tinha que vir depois da chamada ao super(...) ou this(...).
Agora: você pode incluir um prólogo no construtor, útil para:
- validar argumentos,
- calcular variáveis locais,
- inicializar campos ainda não atribuídos.

Regras importantes:

No prólogo não é permitido usar this (não pode acessar campos nem chamar métodos de instância).
Também não dá pra chamar super, exceto para atribuir a campos declarados sem inicializador.
O restante da lógica continua no epílogo (após a chamada a super ou this).

💻 Exemplos: Antes da JEP 513 | Depois da JEP 513

📖 Detalhes na JEP 513

🔒 Segurança e Criptografia

Segurança continua sendo prioridade no JDK: desde remover mecanismos antigos até incluir algoritmos preparados para resistir até mesmo a ataques de computadores quânticos.

JEP 496: Mecanismo de Encapsulamento de Chaves baseado em reticulados modulares (ML-KEM) resistente a ataques quânticos (Java 24)

Essa JEP adiciona suporte ao ML-KEM (lattice-based, padronizado no FIPS 203) na API de KEM (Key Encapsulation Mechanism) do Java.

O que traz:
- Implementação do ML-KEM com parâmetros 512, 768 e 1024 (padrão: 768).
- Permite negociar chaves simétricas de forma resistente a ataques quânticos.
Impacto prático:
- Alternativa futura a ECDH ou RSA em cenários de troca de chaves.
- Ainda não há integração direta com TLS, pois isso depende da padronização externa.

Resultado: aplicações podem começar a experimentar algoritmos pós-quânticos sem depender de libs externas, preparando terreno para um futuro mais seguro.

💻 Exemplos: Antes da JEP 496 | Depois da JEP 496

📖 Detalhes na JEP 496

JEP 497: Algoritmo de Assinatura Digital baseado em Reticulados Modulares (ML-DSA) resistente a ataques quânticos (Java 24)

Essa JEP implementa o ML-DSA (FIPS 204), um algoritmo de assinatura digital resistente a ataques de computadores quânticos.

APIs suportadas: KeyPairGenerator, Signature e KeyFactory.
Parâmetros disponíveis: ML-DSA-44, 65 (padrão) e 87.

Impacto prático:

Permite assinar e verificar dados de forma segura mesmo em cenários futuros de computação quântica.
Coloca o Java na vanguarda de algoritmos pós-quânticos já padronizados.

Limitações atuais:

Ainda não há integração com JAR signing ou TLS, isso depende da evolução dos padrões externos.
Também não há suporte a pre-hash ou context strings.

💻 Exemplos: Antes da JEP 497 | Depois da JEP 497

📖 Detalhes na JEP 497

JEP 510: API de Funções de Derivação de Chaves (Java 25)

Essa JEP fornece uma API padrão (javax.crypto.KDF) para derivar chaves criptográficas.

O que traz:
- Suporte oficial a KDFs (ex.: HKDF) direto no JDK.
- Uso unificado em vez de depender de bibliotecas externas ou implementações caseiras.
Impacto prático:
- Facilita cenários como TLS, HPKE e integrações com HSM/PKCS#11.
- Reduz código duplicado e riscos de segurança de soluções ad-hoc.
- O PBKDF2 continua disponível via SecretKeyFactory.

💻 Exemplos: Antes da JEP 510 | Depois da JEP 510

📖 Detalhes na JEP 510

🗑️ Remoções e Depreciações

Parte da evolução do Java é também remover legados inseguros ou pouco usados, simplificando a base da JVM e incentivando o uso das APIs modernas.

JEP 471: Deprecar métodos de acesso à memória em `sun.misc.Unsafe` para remoção (Java 23)

Essa JEP marca como deprecados para remoção 79 métodos de acesso à memória da classe interna sun.misc.Unsafe.

Motivo: preparar o ecossistema para migrar de uma API interna e frágil para alternativas oficiais e seguras.
Substitutos recomendados:
- VarHandle para acesso em memória on-heap.
- API de Funções e Memória (FFM) para acesso off-heap.

Impacto prático:

Bibliotecas e frameworks que ainda usam Unsafe precisam migrar gradualmente para APIs suportadas.
A JVM introduz a opção --sun-misc-unsafe-memory-access={allow|warn|debug|deny} para ajudar a detectar esses usos em tempo de execução.
Em fases futuras, os métodos vão gerar avisos, exceções e, por fim, serão removidos.

📖 Detalhes na JEP 471

JEP 472: Preparação para Restringir o Uso de JNI (Java 24)

Essa JEP começa a apertar o cerco ao uso do JNI (Java Native Interface).

O que muda agora: a JVM passa a emitir avisos sempre que código carrega ou vincula bibliotecas nativas via JNI.
Alinhamento: o comportamento de avisos segue o mesmo padrão já adotado pela API de Funções e Memória (FFM).

Impacto prático:

Promove o conceito de “integridade por padrão”, incentivando devs a repensarem usos de JNI.
Prepara o caminho para uma mudança maior: em versões futuras, o acesso nativo deve ser restringido por padrão, exigindo habilitação explícita na inicialização da JVM.

📖 Detalhes na JEP 472

JEP 479: Remover a porta Windows 32-bit x86 (Java 24)

Essa JEP removeu do JDK todo o código e suporte de build para Windows 32-bit x86.

Motivo: essa arquitetura está em desuso, e manter o suporte gerava complexidade extra na base de código e na infraestrutura de build/testes.
Benefício: manutenção simplificada, menos código legado e foco em plataformas modernas (x64 e ARM).

Impacto prático:

Quem ainda depende de Windows 32-bit precisa permanecer em versões antigas do JDK ou migrar para 64-bit.
O time do OpenJDK concentra esforços em arquiteturas atuais, reduzindo risco de bugs em áreas pouco usadas.

📖 Detalhes na JEP 479

JEP 486: Desativar Permanentemente o Security Manager (Java 24)

Essa JEP remove de vez a possibilidade de habilitar o Security Manager.

O que muda:
- A flag -Djava.security.manager na inicialização não tem mais efeito.
- A chamada System.setSecurityManager(...) agora lança UnsupportedOperationException.
Motivação:
- O recurso tinha baixo uso real.
- Custava caro manter e evoluir, já que criava restrições profundas dentro da JVM.

Impacto prático:

Quem ainda tem dependências, flags de build ou parâmetros de runtime ligados ao Security Manager precisa remover ou atualizar essas referências.
A API restante deve ser removida em futuras versões do JDK.

📖 Detalhes na JEP 486

JEP 498: Aviso ao usar métodos de acesso à memória em sun.misc.Unsafe (Java 24)

Essa JEP dá mais um passo na transição para longe do sun.misc.Unsafe.

O que muda: na primeira chamada a métodos de acesso à memória em Unsafe, a JVM agora emite um aviso em tempo de execução.
Opção de controle: a flag

  --sun-misc-unsafe-memory-access={allow|warn|debug|deny}

define o comportamento (no JDK 24, o padrão é warn).

Impacto prático:

Facilita detectar usos de Unsafe durante a execução.
Prepara o ecossistema para a futura remoção definitiva desses métodos.
Alternativas modernas já disponíveis:
- VarHandle para acesso on-heap.
- API de Funções e Memória (FFM) para acesso off-heap.

📖 Detalhes na JEP 498

JEP 501: Deprecar a porta x86 32-bit para remoção (Java 24)

Essa JEP marca a porta x86 32-bit (ainda existente no Linux, já removida no Windows) como depreciada para remoção.

O que muda:
- Builds que tentarem habilitar essa porta exibem um aviso de depreciação.
- Só é possível prosseguir se usar a flag:
```
--enable-deprecated-ports=yes
```
Motivação:
- Reduzir o custo de manutenção.
- Focar os esforços em arquiteturas modernas (x64 e ARM).

Impacto prático:

Projetos que ainda dependem de Linux 32-bit devem planejar a migração para 64-bit.
A remoção definitiva está no horizonte, então esse é o último aviso antes da saída completa.

📖 Detalhes na JEP 501

JEP 503: Remover a porta x86 32-bit (Java 25)

Essa JEP remove do JDK todo o código e suporte de build para a porta x86 32-bit.

Contexto: no Java 24, a JEP 501 já havia marcado a porta como deprecada.
Agora: a remoção é definitiva, não há mais suporte nem para builds experimentais.

Impacto prático:

Simplificação da base de código e da infraestrutura de build/testes.
Desbloqueio de recursos que não precisam mais manter fallback para 32-bit.
Quem ainda depende de ambientes 32-bit precisa permanecer em versões antigas do JDK ou migrar para 64-bit.

📖 Detalhes na JEP 503

🚀 Fechando o pacote: do Java 21 ao 25

O Java 25 marca a chegada de uma nova versão LTS, quase dois anos depois do Java 21. Nesse período, muita coisa mudou: o GC ficou mais eficiente, a JVM ganhou recursos para inicializar mais rápido, a linguagem ficou mais expressiva e a segurança já está preparada para desafios futuros.

👉 Por que atualizar é importante?

Estabilidade: o Java 25 vai receber suporte até 2030, é nele que a comunidade e fornecedores vão concentrar seus esforços.
Performance: várias melhorias trazem ganhos diretos sem precisar reescrever sua aplicação.
Segurança: algoritmos modernos e pós-quânticos já fazem parte do JDK, reduzindo riscos.
Manutenção: quanto antes você atualizar, menor o salto acumulado na próxima migração.

No fim, atualizar não é só “ficar na moda”: é garantir suporte, segurança e eficiência pro seu sistema.

Quer ver tudo isso funcionando na prática?

Montei um playground com exemplos antes e depois de cada JEP relevante, do Java 22 ao 25. É só clonar e brincar com os códigos.

Seu Sistema Está Pronto pro Pico ou Vai Abandonar o Usuário Quando Mais Precisar?

Ed Wantuil — Sun, 21 Sep 2025 12:40:35 +0000

Quando grandes pontes são construídas, engenheiros não economizam em testes. Primeiro, simulam cargas extremas em projetos digitais e maquetes. Depois, com a estrutura pronta, realizam testes reais com caminhões pesados e sensores espalhados por toda a obra. 
Tudo isso não é só pra garantir que a ponte fique de pé, é pra ela aguentar o pior congestionamento possível.
 Agora pense: aviões, elevadores, pneus… Quase tudo que usamos no dia a dia passa por testes rigorosos.  Então por que, no desenvolvimento de software, tanta gente ainda confia cegamente que “vai dar tudo certo”?

Spoiler: Não vai. E a realidade cobra, e cobra rápido.

🔥 Quando Tudo Vai Pro Espaço (Mesmo em Grandes Empresas)

Recentemente, na liberação da pré-venda do Nintendo Switch 2, até sites gigantes tombaram, incapazes de lidar com a avalanche de acessos. E isso não é um caso isolado. Lembra da venda de ingressos do último show que você tentou comprar?
 O problema costuma nascer de um otimismo quase infantil: a crença de que recursos computacionais são infinitos ou de que “problemas de capacidade” são coisa do passado.
 Outros ainda jogam a batata quente exclusivamente pra equipe de infraestrutura, ignorando o fato de que garantir escalabilidade e resiliência é responsabilidade de todo o time, devs, QA, arquitetura, produto e afins.

🧪 Planejar, Testar e Validar: O Tríplice Mandamento da Estabilidade

Se você é da área de tecnologia, precisa encarar a realidade: planejar, testar e validar suas aplicações para os momentos de estresse é tão essencial quanto testar uma ponte antes de inaugurá-la.
 Não deixe sua entrega ruir exatamente quando ela mais for necessária. 
É aí que entram os testes de carga.

🧱 O Que São Testes de Carga?

Testes de carga simulam o comportamento de vários usuários acessando sua aplicação ao mesmo tempo, como se você pudesse provocar, de forma controlada, o pior congestionamento possível na sua "ponte digital".
Esses testes são essenciais para identificar:

Gargalos de performance;
Pontos frágeis na arquitetura;
Limites de capacidade operacional.

Sem eles, você está lançando seu sistema às cegas, apostando que ele vai aguentar qualquer volume de acessos e apostar não é estratégia.
Investir em testes de carga é investir em confiança, estabilidade e, no fim das contas, na experiência do usuário, aquele que não vai te perdoar se o app falhar justamente quando ele mais precisar.

📏 Antes de Testar: Faça a Estimativa Certa

Mas atenção: antes de testar, é essencial estimar corretamente o volume de acesso que você quer simular.
Esse processo começa com a análise de:

Picos históricos de uso da aplicação;
Projeções para eventos especiais (grandes lançamentos, campanhas de marketing, repercussões inesperadas).

E vai além: você também precisa considerar cenários de falha de infraestrutura, seja no seu data center ou na nuvem.

☁️ Cloud não é invencível: zonas podem cair, regiões inteiras podem ficar indisponíveis por horas.  Sua aplicação precisa estar preparada para redistribuir a carga e continuar operando.

🧠 Exemplo Prático: Planejando a Carga

Imagine que seu site, em um dia comum, sustenta 2 mil usuários simultâneos no pico. 
Agora, considere um evento especial (tipo Black Friday ou lançamento viral) que pode multiplicar esse número por 5. 
Além disso, pense na hipótese de uma falha em uma zona da nuvem, que forçaria sua aplicação a redistribuir a carga em apenas metade da infraestrutura disponível.
Nesse cenário, o teste de carga precisa simular:

10 mil usuários simultâneos, rodando em 50% da sua estrutura atual.

🛠️ Ferramentas Para Testes de Carga

Hoje, existem várias ferramentas, gratuitas e corporativas, que ajudam a simular acessos simultâneos, medir performance e identificar pontos críticos. 
Entre as mais conhecidas estão:

Apache JMeter
K6
Locust
Artillery
Gatling

Vamos focar aqui no K6, que é leve, simples e bem poderosa.

🧪 Criando um Endpoint para Teste com Node.js

Para testar com K6, primeiro vamos subir um serviço local simples com Node.js que sempre retorna um status 200.
Crie o arquivo server.js com o seguinte conteúdo:

const http = require('http');

const server = http.createServer((req, res) => {
  res.writeHead(200, { 'Content-Type': 'text/plain' });
  res.end('OK');
});

const port = 3000;
server.listen(port, () => {
  console.log(`Server running at http://localhost:${port}`);
});

Execute com:

node server.js

Agora temos um endpoint local na porta 3000 (ou a que for exibida no terminal).

⚙️ Instalando o K6

Para utilizar o k6 devemos fazer a instalação da seguinte forma.

Linux (Ubuntu):

sudo apt update
sudo apt install gnupg ca-certificates
sudo mkdir -m0755 -p /etc/apt/keyrings
curl -fsSL https://dl.k6.io/key.gpg | sudo gpg --dearmor -o /etc/apt/keyrings/k6-archive-keyring.gpg
echo "deb [signed-by=/etc/apt/keyrings/k6-archive-keyring.gpg] https://dl.k6.io/deb stable main" | sudo tee /etc/apt/sources.list.d/k6.list
sudo apt update
sudo apt install k6

Mac:

brew install k6

Windows (com Chocolatey):

choco install k6

🚀 Primeiro Teste de Carga com 50 Usuários
Crie o arquivo load-test.js:

import http from 'k6/http';
import { check } from 'k6'; 

export const options = {
    vus: 50,
    duration: '30s',
};

export default function () {
    const res = http.get('http://localhost:3000');
    check(res, { 'status é 200': (r) => r.status === 200 });
}

Esse script simula 50 usuários virtuais (VUs) acessando o endpoint http://localhost:3000 durante 30 segundos.  Cada VU faz requisições continuamente, e a função check valida se a resposta tem o código de status 200.
Execute-o com:

k6 run teste.js

📊 Interpretando os Resultados do K6

Ao executar devemos ter o retorno algo como print abaixo: 

 Nele podemos encontrar:

checks_total / succeeded / failed:  Verifica a quantidade total de verificações (check) feitas, quantas passaram e quantas falharam.  ✅ Neste caso: 1.675.407 verificações com 100% de sucesso. 
 http_req_duration:  Tempo total de duração das requisições HTTP (da saída até a resposta).
- avg: média geral (850.51μs, excelente).
- med: mediana (618μs).
- max: tempo máximo (90.91ms).
- p(90) e p(95): percentis (ex: 95% das requisições levaram até 1.89ms).
http_req_failed:  Percentual de falhas nas requisições.  ✅ Aqui: 0.00%, nenhuma falha. 
iteration_duration:  Duração de cada iteração completa (requisição + lógica de script).
vus / vus_max:  Quantidade de usuários virtuais ativos (aqui foram fixos em 50). 
data_received / data_sent:  Volume de dados trafegados durante o teste (283MB recebidos, 139MB enviados). 
http_reqs:  Total de requisições realizadas: 1.675.407 > Taxa: ~55.843 requisições/segundo.  ✅ O resultado mostra que o endpoint respondeu rapidamente, sem erros, mesmo sob alta taxa de requisições simultâneas.

📈 Rampas de Carga: Porque Nem Todo Pico Vem de Uma Vez

Em muitos cenários, não basta testar se a aplicação suporta uma determinada carga de forma imediata. Para entender de fato o comportamento do sistema sob diferentes níveis de pressão, é fundamental aplicar rampas de carga nos testes. 
Esse tipo de abordagem permite observar como a aplicação responde à medida que o número de usuários cresce gradualmente, além de ser essencial para avaliar a eficácia da elasticidade (escalabilidade automática) e identificar possíveis gargalos ao longo da curva de crescimento.
 Vamos criar um novo código baseado no exemplo anterior que iremos incluir uma rampa de carga. Nesse novo teste, vamos:

Simular 50 usuários virtuais nos primeiros 30 segundos;
Aumentar para 100 usuários nos 30 segundos seguintes;
Manter os 100 usuários por mais 30 segundos;
E por fim, reduzir a carga de forma gradual até zero ao longo de 30 segundos. Em testes reais, o ideal é que esses tempos sejam maiores e ajustados à realidade do seu sistema, refletindo picos esperados de uso com maior fidelidade.

Exemplo com Rampa de Carga
Crie o ramp-load-test.js com o seguinte conteúdo:

import http from 'k6/http';
import { check } from 'k6';

export const options = {
    stages: [
        { duration: '30s', target: 50 },
        { duration: '30s', target: 100 },
        { duration: '30s', target: 100 },
        { duration: '30s', target: 0 },
    ],
};

export default function () {
    const res = http.get('http://localhost:3000');
    check(res, { 'status is 200': (r) => r.status === 200 });
}

Execute-o com:

k6 run ramp-load-test.js

Esses testes devem ser executados em duração proporcional ao cenário real, aumentando, sustentando e reduzindo a carga como em eventos reais.

🛡️ Use Ferramentas de Observabilidade

Relatórios do K6 são ótimos, mas para diagnósticos profundos, combine os testes com ferramentas como:

New Relic
Datadog
Dynatrace
Elastic Stack
Splunk

Elas mostram uso de CPU, memória, latência entre serviços, Apdex, etc. Isso transforma dados em decisões reais sobre arquitetura e negócios.

🚨 E Quando Você Não Sabe o Pico?

Em muitos casos, especialmente durante o desenvolvimento de novas aplicações, não teremos um número exato de usuários para simular nos testes de carga. Nesses cenários, é recomendável conduzir um teste de estresse até identificar o ponto de saturação do sistema, sim a principal diferença do teste de carga e de estresse é que o primeiro é utilizado para responder se a aplicação suporta uma determinada carga, em quanto o segundo responde até qual carga a aplicação consegue lhe dar.
 Esse tipo de teste permite fornecer ao time de negócio uma visão clara dos limites atuais da aplicação, possibilitando decisões mais conscientes sobre infraestrutura, roadmap de melhorias e comunicação com usuários. 
Sim, a principal diferença entre teste de carga e teste de estresse está no objetivo:

O teste de carga busca validar se a aplicação suporta uma carga específica dentro de parâmetros aceitáveis.
Já o teste de estresse tem como foco descobrir até qual ponto a aplicação consegue lidar com o aumento de carga, identificando o momento em que começa a falhar ou degradar seu desempenho. Para realizar um teste de carga no K6, basta subir a va quantidade de VUs, e se for necessário aumentar a quantidade de rampas para entender o comportamento em cada etapa.

💡 Dica Final: Elasticidade Também É Desescalar

Ambientes elásticos devem voltar ao normal após o pico. Se os recursos não forem liberados, você pode acabar com:

Overprovisioning;
Uso desnecessário de máquinas;
E, claro, aquela fatura de nuvem mais assustadora que bug em produção 👻💸

🧩 Conclusão: Testar é Prevenir, Não Remediar

Toda ponte, avião ou elevador passa por testes antes de ser usado por milhões de pessoas. No mundo digital, o raciocínio precisa ser o mesmo. Não espere o caos para descobrir onde sua aplicação falha.
Testes de carga não são “luxo de grandes empresas”, são prática essencial para qualquer sistema que leve a sério a própria estabilidade, reputação e experiência do usuário. Ignorar isso é aceitar o risco de colapsar quando mais importa.

10 Passos Para Conduzir um Pós-Mortem Que Realmente Evita Novos Incidentes

Ed Wantuil — Sun, 14 Sep 2025 09:00:00 +0000

No último texto, falamos sobre como as crises têm o estranho hábito de aparecer no fim da tarde de uma sexta-feira, e como, muitas vezes, elas são tratadas como eventos isolados. Ignoramos suas causas profundas, apagamos o incêndio, respiramos aliviados... até que tudo se repete.
 Essa repetição constante de falhas nos leva a viver o que pode ser chamado do "dia da marmota", um ciclo vicioso onde sempre voltamos ao mesmo ponto. Como quebrar esse padrão?
 Vamos começar com uma analogia poderosa.
Acidentes de carro acontecem todos os dias. E, geralmente, pelas mesmas razões: distração, imprudência, falta de manutenção.
Pouco se investiga, pouco se documenta, e quase nada muda. Já os acidentes aéreos são raros, mas quando ocorrem, são profundamente analisados. Cada detalhe é estudado, discutido e documentado. As lições aprendidas são transformadas em normas, manuais e treinamentos. O resultado é uma indústria que evolui com cada falha e torna o próximo voo ainda mais seguro.
 No mundo da tecnologia, deveríamos fazer o mesmo. Incidentes acontecem, mas repetir os mesmos erros não pode ser parte do nosso processo.
 Uma ferramenta poderosa para essa transformação é o post mortem: uma análise estruturada, empática e colaborativa dos eventos que levaram à crise, com foco em aprendizado, não em punição.
 A seguir, compartilho 10 passos práticos para conduzir um post mortem que vá além do superficial, e que realmente gere evolução contínua.

1. Escolha o Momento Certo

Assim como não se investiga um acidente no meio do resgate, não se deve fazer um post mortem no calor do momento.
 Evite realizar a análise logo após o incidente. Nesse momento, as emoções ainda estão à flor da pele, e pode faltar clareza. Por outro lado, esperar demais pode causar esquecimento de detalhes importantes.

📌 Recomendo: agendar o post mortem entre 2 a 5 dias úteis após a crise, garantindo tempo para análise e preparação, sem deixar o caso esfriar.

2. Construa uma Linha do Tempo Clara

Uma das primeiras etapas é reconstituir a sequência de eventos, como se estivéssemos narrando uma história real, com começo, meio e fim.
 Inclua:

Quando e como o problema foi detectado?
Quais alertas foram gerados?
Quem foi acionado?
Quais decisões foram tomadas?
Quando e como o sistema foi estabilizado?

📌 Ferramenta útil: crie uma linha do tempo visual e colaborativa. Isso ajuda todos os envolvidos a terem uma compreensão comum dos fatos.

3. Envolva as Pessoas Certas

Não é uma reunião aberta. O post mortem deve contar com quem tem contexto e pode contribuir com informações valiosas. 
Inclua:

As pessoas que atuaram na crise;
Representantes de áreas impactadas;
Especialistas que possam propor melhorias reais.

📌 Evite excesso de participantes. Muita gente na sala pode inibir o debate e tornar a reunião improdutiva.

4. Crie um Ambiente Seguro

Erros acontecem. Mas quando o ambiente é punitivo ou competitivo, as pessoas se calam. E onde não há transparência, não há aprendizado.

📌 Crie um espaço de confiança:

Reforce que o objetivo não é apontar culpados, mas entender causas e contextos;
Valorize a coragem de quem compartilha falhas;
Adote o modelo de blameless post mortem, que foca no sistema, e não na pessoa.

5. Garanta Entendimento para Todos

Nem todos na sala falam o mesmo idioma técnico. E mesmo entre técnicos, há níveis e especialidades diferentes.

📌 Evite jargões ou explicações incompletas; 
📌 Esclareça siglas, processos ou termos; 
📌 Lembre-se: a responsabilidade por uma comunicação clara é sempre de quem fala.

Isso fortalece o entendimento e a colaboração, evitando mal-entendidos que poderiam se tornar novas crises.

6. Identifique os Fatores Contribuintes

É tentador buscar uma causa única, mas a verdade é que crises são multifatoriais. Pequenas falhas, decisões, suposições ou silêncios se somam até algo quebrar. 
Uma forma eficiente de encontrar essas causas é a técnica dos 5 Porquês.

📌 A ideia é simples: pergunte “por quê?” pelo menos cinco vezes a partir do problema identificado, até chegar à origem mais profunda e mapear os fatores contribuintes.

👉 Exemplo prático:

Problema: O site ficou fora do ar por 30 minutos. 
1️⃣ Por que o site saiu do ar? → Porque o servidor principal travou.
 2️⃣ Por que o servidor travou? → Porque a CPU estava em 100%.
 3️⃣ Por que a CPU estava em 100%? → Porque houve um pico de tráfego não esperado.
 4️⃣ Por que não esperávamos esse tráfego? → Porque o time de marketing lançou uma campanha sem avisar o time de infraestrutura.
5️⃣ Por que não houve comunicação entre os times? → Porque não existe um processo formal de integração entre marketing e tecnologia.

Fatores Contribuintes Identificados

Comunicação insuficiente: Não há canais ou rituais definidos para alinhar lançamentos de marketing e infraestrutura.
Monitoramento reativo: Falta de alertas pró‑ativos para variações acima de certo limiar de CPU ou tráfego.
Autoscaling não configurado (HPA): O Horizontal Pod Autoscaler estava ausente ou com thresholds muito altos, impedindo o escalonamento automático dos recursos.
Ausência de testes de carga: Possivelmente, nunca foi executado um teste de stress ou carga para validar a capacidade em cenários de pico.
Processo de resposta a incidentes frágil: Não há runbooks claros nem papéis definidos para acionamento rápido em crise.
Suposições não documentadas: Ficou implícito que “se todo mundo for avisado no Slack, já basta”, mas sem garantia de visibilidade ou confirmação.

7. Avalie a Resposta à Crise

Mais do que entender o problema, é essencial analisar como a equipe reagiu. 

Divida a avaliação em três partes:

O que funcionou bem e deve ser repetido?
O que não funcionou e precisa ser eliminado ou ajustado?
O que poderia ter sido feito de forma diferente?

📌 Perguntas úteis:

As pessoas sabiam o que fazer?
Havia documentação clara?
A comunicação entre times foi fluida?
Houve decisões acertadas que aceleraram a resolução?

👉 Valorize o que deu certo. Celebrar os acertos cria confiança e constrói maturidade organizacional.

8. Crie um Plano de Ação Concreto

Um post mortem sem ações claras é como um relatório ignorado numa gaveta.

Para cada fator identificado, defina:

Uma ação preventiva ou corretiva;
Um responsável claro;
Um prazo realista;
Um critério de conclusão.

Para ilustrar de forma mais enxuta, vamos focar nos 3 fatores principais identificados:

 Comunicação insuficiente
- Ação: Estabelecer um “Release Alignment” quinzenal entre marketing e infraestrutura.
- Responsável: Líder de Infraestrutura.
- Prazo: 2 semanas.
- Critério de conclusão: Primeira reunião realizada e ata validada por ambos os times.
 Monitoramento reativo
- Ação: Configurar alertas proativos em Prometheus/Grafana para CPU > 70% e tráfego > 80% da capacidade.
- Responsável: Engenheiro de Observabilidade.
- Prazo: 1 semana.
- Critério de conclusão: Alertas testados com simulação de pico e aprovados em staging.
 Autoscaling não configurado (HPA)
- Ação: Implementar HPA no cluster Kubernetes com thresholds para escalar automaticamente.
- Responsável: DevOps.
- Prazo: 10 dias.
- Critério de conclusão: Teste de carga demonstra escalonamento sem degradação de performance.

Com este plano reduzido, cada ação tem clareza de “o quê”, “quem”, “quando” e “como” medir, garantindo que o “dia da marmota” não se repita.

📌 E o mais importante: acompanhe a execução. O aprendizado só vira prática se for implementado.

9. Documente Tudo com Clareza e Intenção

O que nos torna uma espécie avançada não é apenas a linguagem, é a capacidade de registrar e transmitir conhecimento de forma assíncrona ao longo dos séculos. 
A documentação de uma crise serve para que outras pessoas, em outros contextos, possam entender, aprender e evitar os mesmos erros.

📌 Inclua:

A linha do tempo;
Os fatores identificados;
As ações tomadas;
As lições aprendidas;
Recomendações e observações úteis.

Assim como os manuais da aviação são atualizados após cada acidente, devemos usar nossos incidentes para revisar nossos processos e padrões. A documentação é onde esse aprendizado se materializa.

10. Compartilhe com as Lições Apreendidas (Sempre que Possível)

Aprendizado que fica preso em um time é conhecimento desperdiçado. Sempre que possível, compartilhe o post mortem (ou pelo menos suas lições principais) com outras áreas da organização.

📌 Isso:

Evita que outros repitam os mesmos erros;
Gera cultura de melhoria contínua;
Cria visibilidade para o esforço e evolução da equipe. Pode ser em forma de:
Newsletter interna;
Apresentação no all hands;
Canal de incidentes em ferramentas como Slack ou Confluence.

👉 E se o incidente for relevante para o mercado, considere compartilhar publicamente, como fazem grandes empresas de tecnologia, contribuindo para toda a comunidade.

✈️ Conclusão: A Crise Como Alicerce da Evolução

Crises são inevitáveis. Repeti-las, não.
Quando você trata cada incidente como uma oportunidade real de aprendizado, e estrutura esse aprendizado com empatia, clareza e disciplina, sua equipe cresce. Sua cultura amadurece. E sua organização se fortalece.
O post mortem é a ponte entre o que falhou e o que pode ser melhor. Use-o como uma ferramenta de transformação. Faça como a aviação: aprenda com cada queda para voar ainda melhor.

E quem sabe, um dia, as sextas-feiras voltem a ser só... sextas-feiras. 😄

Top 5 Vacilos que Desenvolvedores Cometem em uma Crise (e como evitar)

Ed Wantuil — Sun, 07 Sep 2025 15:24:45 +0000

Sexta-feira, 17:55. Você tá fechando o notebook, já pensando na pizza. E aí: TRIM TRIM, toca o telefone. Se você é dev, já sabe o frio na espinha:

“O que será que deu ruim agora?”

Poucas coisas assustam mais do que uma sala de crise, especialmente numa sexta à noite. E sejamos honestos: quem trabalha com desenvolvimento de software já viveu isso. Eu também. Mais de uma vez. E aprendi algumas lições valiosas (algumas doídas), tanto pelos meus erros quanto observando os vacilos do time.

1. Entrar em pânico

Tá escrito até no “Guia do Mochileiro das Galáxias”: não entre em pânico. E isso serve tanto pra salvar galáxias quanto sistemas em produção.
Durante uma crise, é fácil ser dominado pela ansiedade: mil mensagens no Slack, alertas pipocando, usuários surtando... e o medo de ter quebrado tudo. A tentação de sair clicando desesperadamente, derrubando pods ou alterando configs direto no prod é grande. Só que quase sempre... piora tudo.

Manter a calma não é ignorar o problema, é agir com clareza. 
Respira. Reuna o time. Olha os logs. Prioriza. E se der, até dá uma risada (humor também é ferramenta de sobrevivência, como diria o Ford Prefect).

🧠 Pânico gera pressa. Pressa gera erro. E erro... gera mais crise.

2. Tentar resolver sozinho (e no silêncio)

Principalmente no começo da carreira, muita gente tenta “segurar a bronca” sozinha. Por medo de julgamento ou por não ter noção do impacto. Mas o silêncio só faz a crise escalar.

Faça diferente:

Dê visibilidade para sua liderança sobre o incidente e os impactos no negócio;
Abra uma sala de guerra (quando necessário) com as pessoas certas;
Defina um "piloto da crise”, evita conflito de ações e atropelo nas decisões.

3. Procurar culpados no meio do incêndio

Nada trava mais a resolução do que começar uma caça às bruxas no meio do caos.

Troque julgamento por colaboração:

Foque na solução, não em quem causou.
Confie que cada pessoa agiu com o conhecimento e contexto que tinha.
Lembre-se: uma crise raramente acontece por um único erro. São vários elos se rompendo, tipo um acidente aéreo.

4. Buscar a causa raiz antes de estabilizar o sistema

Entrar no modo “Sherlock Holmes” logo de cara? Nem sempre é o melhor caminho.

Primeiro estabiliza, depois investiga.

Entenda o que está sendo impactado agora;
Faça um plano de primeira resposta;
Se precisar reiniciar serviço, aplicar um comando DML no banco ou até colocar um fix rápido no código... faça. Mas trate a causa raiz depois, com calma.

5. Ignorar o postmortem

Crise resolvida? Ótimo. Agora vem a parte mais importante: aprender com ela.

Trate incidentes como acidentes aéreos, não como batida de carro:

No trânsito, cada um vê seu prejuízo e segue a vida.
Na aviação, cada fator contribuinte é estudado, documentado e corrigido.

Postmortem é vacina contra bugs reincidentes. Se ninguém documentar o que rolou, vai acontecer de novo. E de novo...
Checklist para um bom postmortem:

Como a falha foi identificada? Cliente? Monitoramento?
Quais foram os impactos reais?
O que foi feito na primeira resposta?
Quais fatores contribuíram para o incidente?
Como evitar que aconteça de novo?
A observabilidade falhou? Tinha alerta? Dashboard?

👊 Respira. Aprende. Evolui.

Se você tá no meio de uma crise, ou ainda digerindo a última, calma. Todo mundo erra. Mas errar com consciência e corrigir com colaboração faz toda a diferença.

DEV Community: Ed Wantuil

Cloud Sem Falência: O mínimo que você precisa saber de FinOps

🦄 A Ilusão da Mágica: CAPEX vs. OPEX na Engenharia

1. CAPEX (Capital Expenditure): A Lógica do "PC Gamer"

2. OPEX (Operational Expenditure): A Lógica do Uber

Comparativo para Desenvolvedores (Salve isso)

Por que isso afeta a sua Arquitetura?

💸 Os 8 Cavaleiros do Apocalipse Financeiro na AWS

1. Instâncias "Just in Case": O Custo do Seguro Psicológico

2. Ambientes Zumbis: A Torneira Aberta Fora do Expediente

3. O Esquecimento Crônico: O Custo do Limbo

4. O Cemitério de Dados no S3

5. Snapshots: O Colecionador de Backups Fantasmas

6. Licenciamento Comercial (O Custo Invisível)

7. Dilema Geográfico: Reduzindo a Fatura pela Metade

8. Serverless: A Faca de Dois Gumes

🕵️‍♂️ FinOps: Engenharia Financeira na Prática

1. TAGs: Sem Etiquetas, Sem Dados 🏷️

2. AWS Budgets e Detecção de Anomalias 🚨

3. Modelos de Compra: O Fim do On-Demand 💸

🧠 Dev Assina o Código e o Cheque

🌐 O Mundo Híbrido e Multicloud: Complexidade é Custo

Conclusão: A Nuvem não é um Destino, é um Modelo Econômico

Java 25: tudo que mudou desde o Java 21 em um guia prático

O versionamento do Java

As atualizações acumulativas

🧹 Garbage Collectors

JEP 423: Fixação de Regiões para o G1 (Java 22)

JEP 474: ZGC - Modo geracional como padrão (Java 23)

JEP 475: Expansão tardia das barreiras do G1 (Java 24)

JEP 490: ZGC: Remover o modo não-geracional (Java 24)

JEP 521: Shenandoah geracional (Java 25)

💻 JVM

JEP 458: Executar Programas de Código-Fonte Multiarquivo (Java 22)

JEP 491: Sincronizar threads virtuais sem fixação (Java 24)

JEP 483: Carregamento e Vinculação de Classes Antecipados (AOT) (Java 24)

JEP 484: API de Arquivos de Classe (Java 24)

JEP 493: Vinculação de imagens de tempo de execução sem JMODs (Java 24)

JEP 514: Ergonomia de Linha de Comando para AOT (Java 25)

JEP 515: Ahead-of-Time Method Profiling (Java 25)

JEP 518: JFR: Amostragem Cooperativa (Java 25)

JEP 519: Cabeçalhos de Objetos Compactos (Java 25)

JEP 520: JFR: Medição de Tempo e Rastreamento de Métodos (Java 25)

📝 Linguagem

JEP 454: API de Funções e Memória Externas (FFM) (Java 22)

JEP 456: Variáveis e Padrões Sem Nome (Java 22)

JEP 467: Comentários de Documentação em Markdown (Java 23)

JEP 485: Stream Gatherers (Java 24)

JEP 506: Valores de Escopo (Java 25)

JEP 511: Declarações de Importação de Módulo (Java 25)

JEP 512: Arquivos de Fonte Compactos e main de Instância (Java 25)

JEP 513: Corpos de Construtores Flexíveis (Java 25)

🔒 Segurança e Criptografia

JEP 496: Mecanismo de Encapsulamento de Chaves baseado em reticulados modulares (ML-KEM) resistente a ataques quânticos (Java 24)

JEP 497: Algoritmo de Assinatura Digital baseado em Reticulados Modulares (ML-DSA) resistente a ataques quânticos (Java 24)

JEP 510: API de Funções de Derivação de Chaves (Java 25)

🗑️ Remoções e Depreciações

JEP 471: Deprecar métodos de acesso à memória em sun.misc.Unsafe para remoção (Java 23)

*JEP 472: Preparação para Restringir o Uso de JNI * (Java 24)

JEP 479: Remover a porta Windows 32-bit x86 (Java 24)

JEP 486: Desativar Permanentemente o Security Manager (Java 24)

JEP 501: Deprecar a porta x86 32-bit para remoção (Java 24)

JEP 503: Remover a porta x86 32-bit (Java 25)

🚀 Fechando o pacote: do Java 21 ao 25

Quer ver tudo isso funcionando na prática?

Seu Sistema Está Pronto pro Pico ou Vai Abandonar o Usuário Quando Mais Precisar?

🔥 Quando Tudo Vai Pro Espaço (Mesmo em Grandes Empresas)

🧪 Planejar, Testar e Validar: O Tríplice Mandamento da Estabilidade

🧱 O Que São Testes de Carga?

📏 Antes de Testar: Faça a Estimativa Certa

🧠 Exemplo Prático: Planejando a Carga

🛠️ Ferramentas Para Testes de Carga

🧪 Criando um Endpoint para Teste com Node.js

⚙️ Instalando o K6

📊 Interpretando os Resultados do K6

📈 Rampas de Carga: Porque Nem Todo Pico Vem de Uma Vez

🛡️ Use Ferramentas de Observabilidade

🚨 E Quando Você Não Sabe o Pico?

💡 Dica Final: Elasticidade Também É Desescalar

🧩 Conclusão: Testar é Prevenir, Não Remediar

JEP 512: Arquivos de Fonte Compactos e `main` de Instância (Java 25)

JEP 471: Deprecar métodos de acesso à memória em `sun.misc.Unsafe` para remoção (Java 23)

JEP 472: Preparação para Restringir o Uso de JNI (Java 24)