A AWS passou a permitir mudar o tipo de criptografia do lado do servidor (SSE) de objetos já armazenados no Amazon S3, facilitando ajustes de conformidade e padronização sem precisar recriar dados do zero. Na prática, isso ajuda equipes a migrarem entre opções como SSE-S3 e SSE-KMS, aplicando novas políticas de segurança e governança sobre dados existentes. Para operações e plataformas, a novidade reduz atrito em mudanças de requisitos (por exemplo, adoção de chaves gerenciadas no KMS), melhora a automação de remediação e pode ser incorporada a pipelines e rotinas de manutenção de buckets, com rastreabilidade de mudanças e alinhamento a controles de segurança.
💾
Amazon EC2 lança instâncias C8id, M8id e R8id com até 22,8 TB de NVMe local em disponibilidade geral
A AWS anunciou a disponibilidade geral das novas instâncias Amazon EC2 C8id, M8id e R8id, voltadas a workloads que exigem alto desempenho de armazenamento local, com até 22,8 TB de SSD NVMe diretamente no host. A proposta é atender cenários intensivos em I/O e baixa latência, como bancos de dados e análises com dados temporários, processamento de logs e pipelines que precisam de scratch space rápido. Por serem baseadas em armazenamento efêmero (local), essas instâncias favorecem arquiteturas que se beneficiam de throughput e latência previsíveis no disco, mas exigem desenho cuidadoso para durabilidade e recuperação (por exemplo, replicação e checkpoints em armazenamento persistente). Para times de plataforma e SRE, elas podem reduzir gargalos de I/O e melhorar a previsibilidade de performance em cargas stateful com cache local, desde que o ciclo de vida dos dados seja tratado fora do NVMe do host.
A comma.ai detalha a experiência de operar um data center próprio na casa dos US$ 5 milhões, cobrindo desde decisões de compra de hardware e rede até a realidade de energia, refrigeração, espaço físico e manutenção contínua. O texto coloca na mesa o que normalmente fica “escondido” quando se usa cloud: capacidade real, densidade por rack, redundância, falhas esperadas e a logística de manter tudo funcionando com previsibilidade. Na prática, a publicação vira um comparativo técnico entre cloud e self-host para workloads intensivos (como treinamento/inferência de IA e CI), destacando trade-offs de custo, controle e performance — e por que, em certos cenários, ter infraestrutura própria pode fazer sentido quando o gargalo é GPU, rede e energia, não apenas provisionamento.
O artigo detalha como aplicar profiling de performance em pipelines de CI/CD para enxergar, com métricas, onde o tempo e o dinheiro estão sendo gastos — desde filas de execução e etapas de build/test até downloads de dependências, cache, paralelismo e provisionamento de infraestrutura. A proposta é tratar o pipeline como um sistema observável, registrando duração por etapa, variabilidade entre execuções e pontos de espera, para separar lentidão real de ruído e identificar gargalos recorrentes. Além de acelerar entregas, o enfoque é conectar performance a custo: medir consumo por job, taxa de retrabalho (re-runs), desperdício por falta de cache e impacto de concorrência/limites do runner. Com esses dados, times conseguem priorizar otimizações (ex.: ajustar cache, dividir estágios, reduzir I/O, melhorar testes, dimensionar runners) e estabelecer baselines e SLOs de pipeline para evitar regressões e tornar a eficiência do CI/CD uma prática contínua.
O Octopus apresenta a ideia de tratar “prompts como políticas” para padronizar o uso de IA em tarefas operacionais, como gerar relatórios do AWS Well-Architected de forma mais consistente e auditável. Em vez de depender de instruções soltas, a proposta é definir regras e guardrails reutilizáveis que orientem a IA a seguir critérios técnicos (ex.: segurança, confiabilidade, custos) e a produzir saídas alinhadas ao que times de plataforma e SRE precisam. Na prática, isso ajuda a transformar análises e recomendações em um fluxo repetível, reduzindo variação entre execuções e facilitando governança: o prompt vira um artefato versionável, revisável e passível de evolução, como qualquer política de engenharia. O texto também reforça o uso desse modelo para integrar IA a pipelines e rotinas de compliance sem abrir mão de controle e rastreabilidade.
A AWS anunciou melhorias de observabilidade no AWS Lambda para event source mappings (ESM) do Apache Kafka, facilitando a análise do fluxo de consumo de eventos e o diagnóstico de falhas na integração. A atualização adiciona métricas e visibilidade mais detalhada sobre o processamento de registros, ajudando times de plataforma e SRE a identificar gargalos, erros e comportamento de retries/offsets com mais rapidez. Na prática, o recurso reduz o tempo de troubleshooting em pipelines orientados a eventos e melhora a confiabilidade de workloads serverless que consomem tópicos Kafka (incluindo cenários com MSK e Kafka autogerenciado), com sinais mais claros para monitoramento e alertas em produção.
Um levantamento da Chainguard indica que a grande maioria das vulnerabilidades (CVEs) associadas a imagens de contêiner não está concentrada nas imagens mais populares: 98% aparecem fora do top 20. A conclusão desafia a estratégia comum de focar apenas na “pilha base” mais usada e reforça que o risco se espalha principalmente pela cauda longa de dependências e imagens menos padronizadas presentes nos ambientes. Na prática, o estudo sugere ampliar a cobertura de segurança no pipeline para além do básico: inventário de imagens em execução, políticas de proveniência (SBOM/assinaturas), varredura contínua e priorização por explorabilidade e exposição real em produção. Para times de plataforma e SRE, a mensagem é que reduzir a diversidade de imagens e adotar bases minimalistas e verificadas pode diminuir significativamente a superfície de ataque e o volume de correções reativas.
A Pulumi liberou uma especificação OpenAPI oficial para a API REST do Pulumi Cloud, facilitando a descoberta de endpoints, a validação de contratos e a geração automática de clientes e SDKs em diferentes linguagens. Na prática, isso reduz atrito na integração de automações e ferramentas internas com operações como gerenciamento de stacks, deploys e administração de recursos no Pulumi Cloud. Para times de DevOps e engenharia de plataformas, o suporte a OpenAPI ajuda a padronizar integrações em pipelines e serviços, melhora a documentação “viva” da API e viabiliza fluxos mais confiáveis (incluindo testes e mocks) ao consumir funcionalidades do Pulumi Cloud via HTTP, sem depender de implementações manuais ou documentação dispersa.
A Databricks descreve como construir um chatbot de futebol que melhora continuamente a qualidade das respostas com orientação de especialistas do domínio, combinando práticas de avaliação, feedback humano e ajustes iterativos no comportamento do assistente. A proposta é sair do “prompt fixo” e adotar um ciclo de otimização baseado em métricas e testes, reduzindo alucinações e aumentando a precisão em cenários reais de perguntas e respostas. O artigo detalha uma abordagem prática para operacionalizar esse loop de melhoria em plataforma de dados, usando pipelines para registrar interações, rotular exemplos, comparar versões e promover mudanças com governança. Para times de dados e plataforma, o valor está em tratar o chatbot como um sistema em produção: observável, versionado e continuamente validado antes de atualizar a experiência do usuário.
O artigo argumenta que o GitHub Actions tende a virar uma “infra de CI por acidente”: começa simples, mas rapidamente cresce em complexidade e custo operacional. Com pipelines cada vez mais críticos, a equipe passa a gastar tempo excessivo lidando com filas, tempo de execução imprevisível, limites de concorrência, caching frágil, dependências externas e flakiness — além de retrabalho para contornar particularidades do runner e do ambiente efêmero. Na prática, isso empurra a engenharia para um ciclo de manutenção contínua do próprio CI (debug de falhas intermitentes, otimização de performance, contenção de gastos e hardening de segurança em workflows), desviando foco de produto. O texto sugere tratar CI como plataforma: medir e perfilar pipelines, isolar builds, padronizar ambientes e considerar alternativas — como runners self-hosted ou outras soluções — quando confiabilidade, previsibilidade e custo total de operação começarem a pesar.