Ensaios opinativos sobre engenharia de software. Textos longos, sem hype.
Chega de romantizar mensageria. Quando o sistema começa a chiar, fila travando e consumidor engasgando, é aí que o arquiteto leva culpa. Kafka e RabbitMQ não são mágicos, têm propósitos distintos — e escolher errado vira dívida técnica que assombra por anos. Neste artigo, trago a visão de trincheira: onde cada um brilha, onde cada um quebra, e quando abandonar o hype e focar no que realmente resolve o problema do negócio.
A verdade nua e crua: muita gente coloca mensageria em microserviços porque viu num diagrama bonito no slide do arquiteto da moda. Só que hype não paga boleto — e muito menos salva sistema mal modelado. Aqui eu explico onde a mensageria realmente resolve dor de negócio, quando ela vira over-engineering e como implementar sem transformar sua stack em um zoológico distribuído impossível de manter.
Low‑code funciona… até o dia em que você precisa entender o que realmente está acontecendo lá dentro. Como arquiteto nas trincheiras, já vi mais projetos ruírem por dependência cega em plataformas mágicas do que por falta de framework moderno. Neste artigo, vou direto à dor: o low‑code vende eficiência, mas frequentemente entrega dívida técnica embrulhada para presente. Hora de desmontar o hype e mostrar onde ele realmente funciona — e onde vira armadilha arquitetural.
Como arquiteto nas trincheiras, vejo devs tratando IA como se fosse mágica. Não é. Machine Learning só amplifica padrões — inclusive os enviesados, sujos ou inúteis do seu dataset. Este artigo corta a “gourmetização” da IA e mostra, sem romance, o que modelos realmente aprendem, como isso afeta decisões de produto e por que muitos times criam dívida técnica emocional ao esperar que um algoritmo resolva falta de estratégia.
Muita gente vende a ideia de que a IA vai automatizar tudo, mas basta abrir um repositório legado para perceber que o buraco é mais embaixo. Como arquiteto, já vi times inteiros apostarem em 'mágica' enquanto ignoram dívidas técnicas fossilizadas há décadas. Este artigo é um tapa na cara do hype: direto, pragmático e sem gourmetização. Aqui eu mostro por que automação total é um sonho bonito que morre no primeiro módulo acoplado, e o que realmente dá para fazer sem cair em over-engineering.
A fricção entre dev e ops não é mito: é sintoma de prioridades conflitantes, ferramentas usadas como muleta e falta de entendimento sobre contexto de negócio. Neste artigo, eu, Rei Nascimento, corto o romantismo DevOps e explico por que a colaboração costuma fracassar, como alinhar objetivos sem gourmetização e como implementar práticas simples que realmente reduzem incêndios — sem transformar sua stack em um Frankenstein corporativo.
Microserviços prometem autonomia e escalabilidade, mas sem Kubernetes essa fantasia dura pouco. O problema é que muita gente entra nessa arquitetura achando que ela reduz complexidade — quando, na prática, ela só a desloca. Neste artigo, vou direto ao que realmente dói nas trincheiras: por que Kubernetes desmonta a ilusão da simplicidade, como usá‑lo de forma pragmática e quais custos você precisa assumir antes de apertar o primeiro `kubectl apply`.
Microserviços salvam? Às vezes. Mas também podem virar a maior fábrica de dor que um time já viu. O problema raramente é a tecnologia — é a dependência mal pensada que transforma um sistema elegante em um monólito distribuído cheio de dívida técnica. Neste artigo direto das trincheiras, explico quando microserviços brilham, quando só atrapalham e como cortar o over-engineering antes que ele coma seu projeto vivo.
Kubernetes prometeu simplificar a orquestração de serviços, mas acabou criando um ecossistema que parece punir quem só quer entregar software. Neste artigo falo sem rodeios: o hype transformou K8s em uma solução padrão mesmo quando o contexto de negócio não exige metade do que ele oferece. Vamos cortar a gourmetização e analisar onde está a dor real, quando realmente faz sentido usar, e quando você só está assinando uma dívida técnica de luxo.
Microserviços viraram a buzzword favorita de quem acha que quebrar código em caixinhas mágicas entrega agilidade. A realidade é dura: sem domínio claro, sem limites bem definidos e sem disciplina arquitetural, você só constrói um monólito distribuído — caro, lento e impossível de evoluir. Aqui eu explico, sem gourmetização, por que tanta empresa se queima e como evitar virar refém da própria arquitetura.