Esse e-mail veio de forma assíncrona pra você, junto com tópicos de Mensagens, Eventos e Streaming

Mais um post de System Design e uns updates do meu feed

Venho por meio deste, formalmente, dizer que mais um artigo da série de System Design foi publicado. Esse foi especialmente muito difícil de terminar, devido sempre que eu detalhava algum tópico, anotava mais umas par de coisa pra detalhar.

O conhecimento de borda da arquitetura de software é muito torturante, ainda mais quando a missão de desse projeto é facilitar ele de alguma forma.

Esse texto aborda tópicos muito importantes de Mensageria, Eventos e Streaming na visão de System Design, onde usamos o Kafka, MQTT e AMQP pra quebrar em partes e explicar conceitualmente esses caras.

Ao meu ver, esses tópicos são os que permitem os sistemas distribuídos funcionarem de forma eficiente em larga escala, e espero ter consigo passar minha empolgação ao falar desses temas. Então já vamos começar esse e-mail com jabá:

Leia o Artigo Completo - e da uma moral pro pai

Artigos Legais Que Cairam No Meu Feed Esses Dias™️

Segue a minha seleção pessoal de coisinhas legais que valeram a pena serem compartilhadas com meus amigos. Só coisa de qualidade. Qualidade duvidosa, mas de qualidade…

Disaster Recovery no EKS com replicação do EFS

Aquelas pocs documentadas da AWS que viram artigos legais. Esses dias comentei no meu Twitter que estava um pouco decepcionado com a qualidade dos artigos técnicos que tem sido publicados no meu feed. Um dos motivos de eu ter dado um tempo da newsletter, esse aqui foi um case / trick bem legal que deu vontade de compartilhar.

Temas de DR são meus assuntos favoritos quando falamos de Cloud, e reunir o maximo de dicas de arquitetura pra debater esses tópicos é sempre de grande valor pra mim.

Esse artigo publicado no blog da AWS aborda como utilizar o EFS com replication para duplicar os itens de uma região primária para o seu DR. O unico problema é que a replicação é unilateral e necessita que a segunda região seja completamente passiva, e necessita que a replicação seja deletada manualmente para virar a escrita para o DR.

Mas de toda forma, foi legal o case.

Vou deixar aqui o artigo

O PR que deletou 1 milhão de linhas do Kubernetes

Acabou os if cloud == “aws” no bagulho será?

Uma movimentação legal no Twitter esses dias foi o anuncio da comunidade da remoção de 1 milhão de linhas de código da codebase do Kubernetes. O objetivo foi mover as paradas especificas dos Cloud Providers para outro lugar, e deixar a plataforma mais “vanilla” possível. A iniciativa foi concluída pela SIG de Cloud Providers.

Leia a KEP-2395 completa

Google matando projetos, mas dessa vez dos outros…

A UniSuper, fundo super importante australiano que presta serviços de superannuação para empregados do setor de ensino superior e pesquisa da Austrália teve que lidar com uma parada ~meio chata~ esses dias ai.

A conta na GCP da empresa foi EXCLUÍDA por uma misconfig - sem precedentes - de alguns serviços da Google. Os cara apagou a conta dos maluco.

O fundo tem mais de 615.000 membros e administra aproximadamente 124 bilhões de dólares australianos em fundos. Dados de 30 de junho de 2023.

A parte boa foi que conseguiram recuperar a partir de backups dando uma minimizadinha.

Leia a matéria do The Guardian

O post mais bizarro sobre o S3 que você verá - Na moralzinha

Aqui temos o exemplo perfeito de meme que escala demais, dessa vez pro bem. Esses dias o meu grande amigo Bernardo, me mandou esse artigo do Maciej Pocwierz, onde ele detalhava um caso bizarro que ocorreu no billing de sua conta na AWS. O artigo, em traduções quase literais, tem o titulo de “Como um bucket S3 vazio pode fazer o billing da sua conta da AWS explodir”.

Após a execução de uma PoC usando o S3, ele notou um aumento absurdo no billing da sua conta, basicamente $ 1.300,00 de um dia pro outro. Investigando, ele encontrou mais de 100.000.000 de requests de PutItem no bucket que ele esqueceu largado. Acontece que descobrimos que: A AWS COBRAVA POR PUT/GET MESMO QUE A RESPOSTA SEJA 401. Isso signica que qualquer pessoa que saiba o nome de qualquer um de seus buckets no S3 pode aumentar a sua fatura se ela quiser. Bizarro demais. De um dia pro outro Bucket no S3 virou dado sensível???? hahaha.

Leia o Artigo sobre o Caso

Mas calma que deu tudo certo…

Esse artigo escalou em quase todos os grupos de WhatsApp / Telegram de tecnologia que eu participo, e a parte boa é que chegou na mão de gente grande da AWS também.

O famoso Jeff Barr, sim, do blog do Jeff, atual VP da AWS postou no linkedin que depois de um consenso interno, chegaram a conclusão de que realmente não era justo cobrar por solicitações inválidas de seus clientes.

A AWS no dia 13/05 publicou a nota de que agora o S3 não irá cobrar por requisições inválidas. Rapido né? Nada como uma pressãozinha pra acelerar uma burocrinha interna. Mas zoeiras a perte achei legal essa resposta rápida e transparente quase que imediata a repercução do caso.

Leia a Nota da AWS sobre a alteração de billing

É isso ai por enquanto galera. Tamo junto!