DEV Community: Eduardo Rosa

Pare de Construir "Big Balls of Mud": O Guia de Sobrevivência Cloud-Native

Eduardo Rosa — Fri, 09 Jan 2026 18:10:20 +0000

Ferramentas morrem, padrões sobrevivem. Um guia agnóstico sobre arquitetura, de microsserviços a DDD, para você parar de apagar incêndios.

Você pisca e um novo framework JS nasceu. Você vai tomar café e a AWS lançou três novos serviços. A sensação de estar sempre atrasado é real no nosso meio.

Mas aqui vai um segredo que os arquitetos sêniores guardam: Ferramentas morrem, Padrões sobrevivem.

Se você focar apenas em aprender a ferramenta da moda ("Como configurar o Kubernetes v1.29"), seu conhecimento tem data de validade. Se você entender os Padrões de Arquitetura, você navega bem seja em mainframes, servidores on-premise ou arquiteturas serverless.

Hoje, vamos destilar a essência da arquitetura de aplicações modernas. Vamos sair do caos do "Big Ball of Mud" e entender como construir sistemas que não colapsem sob o próprio peso.

Uma Breve História do Caos

Para saber para onde vamos, precisamos saber de onde viemos. A arquitetura de software é um pêndulo oscilando entre centralização e descentralização.

A Era dos Mainframes: Tudo centralizado. Terminais "burros" conectados a um cérebro gigante. Simples de gerenciar, difícil de escalar e personalizar.

A Rebelião do Desktop: O poder foi para o usuário. Cada um com seu PC e seus dados. Ótimo para o usuário, pesadelo para sincronizar dados corporativos.

O Cliente/Servidor: O meio-termo dos anos 90. Lógica pesada no PC (Thick Client), dados no servidor.

A Nuvem (Hoje): "A rede é o computador". Estamos distribuídos, escaláveis e... complexos.

O Inimigo nº 1: Big Ball of Mud (BBoM)

Se você já abriu um projeto legado onde mudar uma cor de botão quebrava o relatório financeiro, você conheceu o Big Ball of Mud.

Definição: Uma arquitetura onde "tudo fala com tudo". Dependências circulares, estado global, zero documentação e medo constante de deploy.

Muitas startups começam assim para validar ideias rápido ("Programação Exploratória"). O problema é quando o protótipo vira produção e fica lá por 5 anos.

A Alternativa: O Monólito Modular

Antes de pular direto para microsserviços e se afogar em complexidade de rede, considere o Monólito Modular.

É um executável único, mas internamente organizado. O módulo de Faturamento não acessa as tabelas do módulo de Usuários diretamente; ele usa uma interface pública interna. Se você precisar quebrar isso em microsserviços no futuro, o trabalho duro de desacoplamento já está feito.

As Regras da Casa: Cloud-Native Basics

Para jogar o jogo da nuvem, você precisa seguir algumas regras. A bíblia aqui é o The Twelve-Factor App. Vamos focar no que realmente importa para não quebrar a produção:

1. Separe Configuração de Código

Jamais, em hipótese alguma, faça isso:

// ❌ NÃO FAÇA ISSO 
const dbPassword = "minha_senha_secreta_123";
const apiUrl = "http://localhost:3000";

// ✅ FAÇA ISSO
const dbPassword = process.env.DB_PASSWORD;
const apiUrl = process.env.API_URL;

2. Seja Stateless (Sem Estado)

Em uma arquitetura de nuvem robusta, servidores são gado, não animais de estimação. Eles nascem e morrem o tempo todo (Auto-scaling).

Se você guardar a sessão do usuário na memória RAM do Servidor A, e a próxima requisição cair no Servidor B, seu usuário foi deslogado.

A Solução: Externalize o estado. Jogue sessões no Redis, dados no Banco, arquivos no S3. Sua aplicação deve ser apenas um processador de lógica efêmero.

Entrando no Mundo dos Microsserviços

Microsserviços não são sobre ter 50 repositórios pequenos. São sobre Capacidades de Negócio.

A maior armadilha aqui é criar um "Monólito Distribuído": vários serviços pequenos que compartilham o mesmo banco de dados gigante.

A Regra de Ouro: Self-Managed Data Store

Cada microsserviço deve ser dono soberano dos seus dados.

Serviço de Pedidos tem o banco orders_db.

Serviço de Clientes tem o banco customers_db.

"Ah, mas como eu faço join?"

Você não faz. Você usa composição de dados via API ou duplicação controlada de dados via eventos. Dói no começo, mas é o único jeito de garantir que o time de Pedidos possa mudar o esquema do banco sem quebrar o time de Clientes.

DDD (Domain-Driven Design) ao Resgate

Para não errar no tamanho do serviço, usamos DDD. O conceito de Bounded Context (Contexto Delimitado) é seu melhor amigo. Ele define fronteiras linguísticas e de modelo. O que é "Cliente" para o contexto de Vendas é diferente de "Cliente" para o contexto de Suporte. Respeite essas fronteiras e seus serviços terão o tamanho certo.

Modo Avançado: Coreografia e Eventos

Quando seus serviços precisam conversar, evite o acoplamento direto (HTTP/REST síncrono) para tudo. Se o Serviço A chama o B, que chama o C, e o C cai... tudo cai.

Event-Driven Architecture (EDA) propõe uma mudança de mentalidade:

Em vez de Comandar ("Ei Serviço B, processe esse pagamento agora!"), você Notifica ("Ei mundo, um pedido foi criado").

Quem estiver interessado (Pagamento, Estoque, Email) escuta e reage. Isso é Coreografia.

*Event Sourcing: A viagem no tempo *

E se, em vez de guardar apenas o estado atual (Saldo: 100), guardássemos todas as transações?

ContaCriada: 0

DepositoRealizado: +50

O estado atual é apenas a soma dos eventos. Isso permite auditoria perfeita e debugging incrível ("Vamos repassar os eventos de ontem para ver onde o bug aconteceu").

*Persistência Poliglota e Modernização *

Não tente enfiar tudo em um banco Relacional.

Precisa de grafos de relacionamento (Rede Social)? Use Neo4j.

Precisa de leitura rápida de chave-valor (Carrinho de compras)? Use Redis ou DynamoDB.

Precisa de queries complexas financeiras? O bom e velho PostgreSQL ou MySQL.

Strangler Fig Pattern: Matando o Legado

Você tem um monólito gigante e quer migrar para microsserviços. Não reescreva tudo do zero. (Sério, a chance de falha é enorme).

Use o padrão Strangler Fig (Estrangulamento):
Coloque uma fachada (API Gateway) na frente do sistema.
Crie uma funcionalidade nova como microsserviço.
Aponte a fachada para o novo serviço para essa rota específica.
Repita até o monólito não ter mais função.

Conclusão

Arquitetura de software é a arte de gerenciar Trade-offs.

Microsserviços dão agilidade de deploy, mas trazem complexidade operacional.

Event Sourcing dá auditoria, mas é difícil de versionar.

Não existe bala de prata. Existe a ferramenta certa para o seu contexto. Comece simples (Monólito Modular), respeite os 12 Fatores e evolua conforme a dor aparecer.

E você? Qual desses padrões você acha mais difícil de implementar na vida real hoje? O desacoplamento do banco de dados ou a mudança cultural para DevOps? Deixe nos comentários! 👇

Este artigo foi baseado em conceitos fundamentais do livro "Cloud Application Architecture Patterns".

Latência: O Novo Gargalo da Arquitetura de Software (e Como Vencê-lo)

Eduardo Rosa — Wed, 07 Jan 2026 21:51:42 +0000

No mundo dos sistemas distribuídos e da computação de alto desempenho, vivemos uma mudança de paradigma. Antigamente, a grande batalha era pela largura de banda (throughput). Hoje, porém, a largura de banda é frequentemente um problema que resolvemos "escalando horizontalmente" ou paralelizando a infraestrutura.
O verdadeiro vilão agora é outro: a Latência.
Baseado nos princípios do tratado Latency: Reduce Delay in Software Systems de Pekka Enberg, este artigo explora por que o atraso temporal se tornou o principal gargalo da eficácia dos sistemas modernos e como podemos arquitetar soluções para mitigá-lo.

Largura de Banda vs. Latência: Entendendo a Diferença

É crucial distinguir os dois conceitos. Imagine enviar um caminhão cheio de discos rígidos através do país. A largura de banda é altíssima (petabytes de dados transportados de uma vez), mas a latência é catastrófica (leva dias para chegar).
A latência é o tempo entre a causa (um clique do usuário) e o efeito (a resposta na tela). Enquanto a largura de banda pode ser comprada, a latência esbarra em constantes físicas imutáveis, como a velocidade da luz.

Por que cada milissegundo importa?

O impacto não é apenas técnico, é econômico. Dados de gigantes como Amazon e Google mostram uma correlação direta: aumentos marginais na latência resultam em perda de receita e queda no engajamento.

As Leis Imutáveis e a "Cauda Longa"

Para projetar sistemas rápidos, precisamos entender a matemática por trás do atraso.

1. Lei de Little: Relaciona concorrência, throughput e latência. Para aumentar o throughput sem aumentar a latência, você precisa aumentar a concorrência. Mas atenção: todo sistema tem um limite de concorrência antes que as filas (e a latência) explodam.

**2. Lei de Amdahl: **O limite do paralelismo. Não adianta adicionar infinitos processadores se você tem gargalos seriais (como locks de banco de dados). Otimizar a parte sequencial do seu código vale mais do que adicionar mais CPUs.
Cuidado com a média: Em sistemas distribuídos, a média é uma mentirosa. O foco deve estar no P99 (o 99º percentil). Em uma arquitetura de microsserviços, se uma requisição depende de 100 sub-chamadas, a sub-chamada mais lenta dita a velocidade total. Isso é o fenômeno da "Cauda em Escala" (The Tail at Scale).

Estratégias de Arquitetura: A Física e os Dados

Como reduzimos a latência quando a física joga contra nós?
1. Colocation e Geografia
A luz leva tempo para viajar. A solução é trazer o processamento para perto do usuário através de CDNs e Edge Computing. Se a lógica roda na borda, evitamos o round-trip até um data center central.

2. Otimização de Hardware (Intra-nó)
Dentro do servidor, a distância também importa.
- NUMA (Non-Uniform Memory Access): Garanta que sua thread acesse a memória local do seu processador, não a de um soquete remoto.

**- Kernel Bypass: **Técnicas como DPDK ou io_uring permitem que a aplicação pule o kernel do SO, falando diretamente com a placa de rede. Isso elimina microssegundos preciosos de trocas de contexto.

3. Consistência de Dados
Aqui entra o Teorema CAP. Para ter consistência forte (todos veem o mesmo dado ao mesmo tempo), pagamos o preço da latência de coordenação. Para sistemas ultra-rápidos, muitas vezes optamos pela Consistência Eventual ou arquiteturas Local-First, onde a interface responde imediatamente e sincroniza depois.

Otimização de Código: "O código mais rápido é aquele que não roda"

Além da arquitetura, a forma como escrevemos software define a latência.

- Serialização: Esqueça JSON para comunicação interna de alta performance. Formatos como Protobuf ou FlatBuffers (que permite acesso sem parsing) são ordens de magnitude mais eficientes.

- Gerenciamento de Memória: O Garbage Collector (GC) é o inimigo da baixa latência. Use Object Pooling para evitar alocações dinâmicas e as temidas pausas "Stop-the-world".

- Sincronização Wait-Free: Locks (Mutexes) colocam threads para dormir. Arquiteturas de baixa latência usam estruturas de dados Lock-Free (como Ring Buffers) e instruções atômicas da CPU para evitar o custo de bloqueio e acordar threads.

Ocultando a Latência: Quando a Física Vence

Quando não é possível reduzir o atraso fisicamente, devemos escondê-lo:

1. Assincronia: Desacople a solicitação da resposta. Use backpressure para evitar que filas internas cresçam demais.

2. Execução Especulativa: Tente adivinhar o que o usuário vai fazer. Carregue dados antes de serem pedidos (Prefetching).

3. UI Otimista: Atualize a interface instantaneamente (ex: o botão de "like") antes mesmo do servidor confirmar. Se der erro, reverta depois.

Conclusão

Reduzir a latência exige uma mentalidade de "Latência em Primeiro Lugar". Não é sobre uma única bala de prata, mas sobre otimizar toda a pilha: desde a escolha geográfica do servidor e o bypass do kernel, até a escolha do algoritmo de serialização e a atualização otimista da UI.
O futuro do software não é apenas processar mais dados, mas processá-los com uma responsividade que pareça mágica para o usuário final.

Do Vibe Coding à Engenharia de IA: O Guia Prático para 2025 (Com Prompts!)

Eduardo Rosa — Wed, 24 Dec 2025 17:41:27 +0000

Você já sentiu que programar com IA às vezes parece mágica ("Vibe Coding") e outras vezes parece uma luta constante contra alucinações e bugs ("Prompt Wars")?

Se sim, você não está sozinho. Estamos vivendo uma transição fundamental na nossa carreira: de "digitadores de código" para "arquitetos de intenção".

Este artigo esta baseado em meus estudos recentes e reforço do livro "Beyond Vibe Coding" de Addy Osmani, este artigo vai te mostrar como sair do modo aleatório e aplicar a Engenharia Assistida por IA. E o melhor: vamos fazer isso na prática com um exercício real.

O Espectro: Vibe vs. Engenharia

Antes de abrir o editor, precisamos entender onde estamos pisando.

Vibe Coding
É a abordagem "prompt-first". Você descreve o que quer, aceita o código gerado e segue o fluxo. É rápido, divertido e ótimo para protótipos.

Risco: Cria um "castelo de cartas". Funciona no caminho feliz, mas quebra na produção.

Engenharia Assistida por IA
É a abordagem "plan-first". Você define a estrutura, as interfaces e as regras antes de pedir uma linha de código sequer.

Benefício: Software robusto, manutenível e seguro.

Hoje entrando em 2026, o segredo não é escolher um ou outro, mas saber quando usar cada um. E para construir sistemas reais, precisamos de Engenharia.

A Estratégia de Ouro: Raciocínio + Execução

A maior evolução recente não está apenas nos modelos, mas em como os orquestramos. A técnica mais eficaz hoje é separar o Planejamento da Execução, usando modelos diferentes para cada fase.

O Arquiteto (Modelo de Raciocínio): Usa modelos como OpenAI o1 ou DeepSeek R1. Eles "pensam" antes de responder, sendo perfeitos para criar especificações e prever erros.
O Construtor (Modelo de Execução): Usa modelos como Claude 3.5 Sonnet ou GPT-4o. Eles são velozes e excelentes em seguir instruções de código.

O Desafio Prático: Timer Pomodoro 2.0

Vamos parar de teoria e colocar a mão na massa. Vamos criar um Timer Pomodoro simples, mas com um requisito de engenharia: ele deve persistir os dados no LocalStorage e ter um código limpo e separado por componentes.

Passo 1: O Prompt de Planejamento (O "Mini-PRD")

Não peça o código ainda! Vamos pedir para a IA atuar como um Arquiteto Sênior.

** Objetivo:** Gerar um arquivo SPEC.md que servirá de mapa.
** Modelo recomendado:** o1, o3-mini ou DeepSeek R1.

Copie e use este prompt:

Atue como um Arquiteto de Software Sênior especialista em React e Clean Code.
Eu quero construir um "Timer Pomodoro" web simples.

REQUISITOS:
1. Funcionalidades: Iniciar, Pausar, Resetar, Configurar tempos (Foco/Pausa).
2. Persistência: Salvar histórico de ciclos no LocalStorage.
3. Tech Stack: React (Vite), TailwindCSS, Lucide Icons.

SUA TAREFA:
Não escreva o código da aplicação ainda.
Primeiro, crie um documento de especificação técnica (SPEC.md) contendo:
1. Estrutura de Pastas detalhada.
2. Definição das Interfaces (Typescript Interfaces) para o estado e props principais.
3. Lista de "Edge Cases" que devemos tratar (ex: o que acontece se fechar a aba?).
4. Um plano passo-a-passo de implementação.

Pense passo a passo sobre a arquitetura antes de gerar a especificação.

Passo 2: A Revisão Humana (O Pilar da Confiança)

Agora, leia o que a IA gerou.

A estrutura de pastas faz sentido?
As interfaces cobrem tudo?

Se algo estiver ruim, peça para refazer o plano. Só avance quando o plano estiver sólido. Isso é o que separa um Senior de um Junior na era da IA.

Passo 3: O Prompt de Execução

Com o SPEC.md aprovado, agora vamos para a construção.

** Objetivo:** Gerar o código final.
** Modelo recomendado:** Claude 3.5 Sonnet, GPT-4o ou a ferramenta Cursor/Windsurf.

Copie e use este prompt (anexe o resultado do passo anterior se não estiver na mesma janela de chat):

Atue como um Desenvolvedor Sênior em React.
Siga rigorosamente o plano definido no arquivo SPEC.md acima.

REGRAS DE EXECUÇÃO:
1. Implemente a estrutura de pastas sugerida.
2. Use componentes funcionais e Hooks.
3. Siga as interfaces definidas no plano.
4. Se o código for muito longo, implemente primeiro os componentes base (UI) e depois a lógica (Hooks/Context).

Comece a implementação.

Por que isso funciona?

Ao fazer isso, você aplicou três conceitos avançados do livro "Beyond Vibe Coding":

Context Pinning: Você travou o contexto no SPEC.md, impedindo a IA de alucinar funcionalidades novas.
Plan-First: Você resolveu a lógica antes de digitar a sintaxe.
Separação de Preocupações: Usou o melhor modelo para pensar e o melhor modelo para codar.

Sua Vez!

Teste esse fluxo hoje. Pegue aquela ideia de app que você tem na gaveta, gere um Mini-PRD primeiro e veja a diferença na qualidade do código final.

Comente abaixo: Qual foi a maior diferença que você notou ao usar essa abordagem estruturada?

Este artigo foi inspirado nos conceitos da Parte I e II do livro "Beyond Vibe Coding".




Assim posso te dar feedback se o plano gerado pela IA está robusto o suficiente para a fase de execução! O que acha?


https://a.co/d/6Q46Pze

Vibe Coding vs. Engenharia Assistida por IA: Onde você está no espectro?

Eduardo Rosa — Wed, 24 Dec 2025 17:03:42 +0000

Você já sentiu que a programação está mudando de "digitar códigos" para "gerenciar intenções"? Se sim, você pode estar entrando na era do Vibe Coding.

Recentemente, tenho estudado o livro "Beyond Vibe Coding" de Addy Osmani, e a primeira parte traz uma reflexão fundamental sobre como nossa função está evoluindo. Não se trata apenas de usar o Copilot para autocompletar uma função, mas de uma mudança de paradigma.

Vamos mergulhar nos conceitos de Vibe Coding e Engenharia Assistida por IA.

O que é Vibe Coding?

O termo, popularizado por Andrej Karpathy, descreve um estilo de programação onde você "se entrega às vibes" da IA.

Basicamente, é uma abordagem prompt-first (o prompt vem primeiro). Em vez de escrever a sintaxe linha por linha, você descreve o que quer em linguagem natural e deixa o LLM (Grande Modelo de Linguagem) fazer o trabalho pesado.

O foco: Velocidade extrema e exploração.
A promessa: Transformar o "desenvolvedor 10x" em "desenvolvedor 100x", removendo o gargalo da digitação.
A mentalidade: Você atua menos como um digitador e mais como um gerente de projetos, aceitando sugestões de código rapidamente, muitas vezes sem ler cada linha do diff, desde que o resultado funcione.

É perfeito para criar protótipos, projetos "zero-to-one" ou scripts rápidos. Mas... tem seus perigos.

O Espectro da Codificação com IA

O livro destaca que não existe apenas um jeito de codar com IA. Existe um espectro, e entender onde se posicionar é o que separa um código frágil de um sistema robusto.

1. O Modo Vibe Coding (Exploração)

Aqui, a meta é ver o resultado na tela o mais rápido possível. É ótimo para hackathons ou validação de ideias.

Risco: O código pode virar um "castelo de cartas". Funciona no "caminho feliz", mas pode ser difícil de manter, inseguro ou cheio de bugs sutis.

2. O Modo Engenharia Assistida por IA (Estrutura)

No outro lado do espectro, temos a Engenharia Assistida por IA. Aqui, a abordagem é plan-first (o plano vem primeiro).

O processo: Você cria uma especificação ou arquitetura clara antes de pedir código à IA.
A mentalidade: A IA é sua estagiária ou copiloto. Você delega tarefas, mas revisa tudo com rigor. O humano mantém o controle total das decisões arquiteturais.
O objetivo: Qualidade, confiabilidade e manutenibilidade a longo prazo.

Encontrando o Equilíbrio

A grande sacada não é escolher um lado e ficar nele para sempre. Desenvolvedores de elite na era da IA serão como maestros:

Usarão Vibe Coding para desbloquear a criatividade e sair do zero.
Mudarão para a Engenharia Assistida por IA quando for hora de construir sistemas de produção, refatorar ou garantir a segurança.

E você?

Em qual parte do espectro você tem passado mais tempo ultimamente? Você se sente confortável "confiando na vibe" ou prefere manter o controle total linha por linha?

Deixe sua opinião nos comentários!

Este artigo foi baseado em estudos sobre a "Part I: Foundations" do livro Beyond Vibe Coding.

Implantando e Interagindo com Serviços AWS

Eduardo Rosa — Thu, 29 May 2025 20:24:43 +0000

Embarcar na jornada de construir soluções na plataforma Amazon Web Services (AWS) requer uma compreensão abrangente das ferramentas e abordagens disponíveis. Aqui tentarei demonstrar metodologias para arquitetar na AWS, começando com atividades preparatórias como coleta de requisitos, seleção de serviços e diagramação.

Exploraremos os diversos métodos e ferramentas disponíveis para implantar e interagir com os serviços AWS, incluindo o Console AWS, a Interface de Linha de Comando (CLI) da AWS, os Kits de Desenvolvimento de Software (SDKs) da AWS e a Infraestrutura como Código (IaC).

Abordaremos os seguintes tópicos:

Arquitetando na AWS
Começando com o Console AWS
Navegando pela CLI e SDK da AWS
Entendendo IaC

Ao final deste capítulo, você possuirá o conhecimento e as habilidades necessárias para criar, operar e monitorar serviços AWS usando a abordagem que melhor se alinha com seus requisitos e preferências, seja através do Console AWS, da CLI, acesso programático via SDKs ou das poderosas ferramentas de IaC.

Para acompanhar, você precisará de uma conta AWS.

Arquitetando na AWS

Arquitetar na AWS refere-se ao processo de projetar e planejar soluções baseadas em nuvem usando os serviços da AWS. Envolve entender os diversos serviços AWS, suas capacidades e como eles podem ser combinados para construir arquiteturas escaláveis, seguras e econômicas.

Ao arquitetar na AWS, os seguintes quatro aspectos devem ser considerados, cada um detalhado posteriormente neste capítulo:

Coleta de requisitos: Etapa crucial que envolve entender as necessidades de negócios, requisitos funcionais, não funcionais e restrições que moldarão o design e a implementação da arquitetura AWS.
Padrões de arquitetura: A AWS oferece vários padrões e arquiteturas de referência que servem como pontos de partida para casos de uso comuns, como aplicações web, pipelines de processamento de dados ou arquiteturas serverless.
Seleção de serviços: A AWS oferece uma ampla gama de serviços, incluindo computação, armazenamento, bancos de dados, rede, análise, machine learning e mais. Você deve avaliar cuidadosamente os requisitos das aplicações e selecionar os serviços AWS que melhor atendam a essas necessidades.
Diagramação: Criar representações visuais da arquitetura proposta é uma etapa crucial no processo de arquitetura. Ferramentas como PowerPoint ou draw.io podem ser usadas para criar diagramas de arquitetura, que ajudam a comunicar o design e facilitam a colaboração e implementação.

Coleta de Requisitos

Requisitos claros e bem definidos são essenciais para que os arquitetos projetem soluções AWS que atendam às necessidades específicas da organização e forneçam os resultados desejados. A coleta de requisitos pode envolver colaboração com stakeholders, workshops, análise de sistemas existentes e entendimento do contexto de negócios.

Para projetos de menor escopo, nem todas essas etapas podem se aplicar. No entanto, é importante entender que tipos de requisitos podem ser coletados antes de um projeto começar:

Requisitos de negócios: Entender os objetivos, metas e drivers por trás da solução sendo arquitetada.
Requisitos funcionais: Definir os recursos e capacidades específicas que a solução deve fornecer.
Requisitos não funcionais: Atributos qualitativos que a solução deve possuir, como desempenho, escalabilidade, disponibilidade, segurança e conformidade.
Requisitos técnicos: Tecnologias específicas, linguagens de programação, frameworks e ferramentas que precisam ser usadas ou integradas com a solução AWS.
Requisitos de dados: Tipos de dados, volumes, fontes, necessidades de processamento e requisitos de governança.
Requisitos de integração: Pontos de integração com sistemas locais, serviços de terceiros ou outros ambientes de nuvem.
Requisitos de segurança e conformidade: Padrões regulatórios, leis de proteção de dados ou certificações específicas do setor.
Requisitos financeiros: Restrições orçamentárias e considerações de custo, essenciais para selecionar serviços AWS e implementar arquiteturas econômicas.

Escolhendo um Padrão de Arquitetura

Padrões de arquitetura e arquiteturas de referência servem como pontos de partida para projetar e implementar soluções baseadas em nuvem. Esses padrões encapsulam melhores práticas, designs comprovados e princípios arquiteturais adaptados a casos de uso específicos.

Você pode encontrar muitos desses padrões no AWS Architecture Center. Ao alavancar esses padrões, você pode acelerar o processo de desenvolvimento e garantir que suas soluções estejam alinhadas com as melhores práticas da AWS e padrões do setor.

Selecionando um Serviço

Com mais de 200 serviços disponíveis, a AWS oferece uma vasta gama de blocos de construção que podem ser combinados para criar arquiteturas escaláveis, seguras e econômicas. A seleção de serviços é um processo iterativo que envolve equilibrar práticas arquiteturais recomendadas e todos os tipos de requisitos.

O primeiro passo é mapear os requisitos coletados para os serviços AWS disponíveis. Isso envolve entender as capacidades e casos de uso de cada serviço e identificar aqueles que podem atender aos requisitos específicos da solução.

Diagramação

Representações visuais da arquitetura proposta ajudam a comunicar o design, facilitam a colaboração entre membros da equipe e garantem um entendimento compartilhado dos componentes da solução e suas interações. Não há uma ferramenta padrão para diagramar soluções AWS, mas as mais aceitas são PowerPoint usando AWS Architecture Icons ou draw.io.

Explorando o Well-Architected Framework

A AWS fornece um conjunto de melhores práticas e princípios de design conhecidos como Well-Architected Framework (WAR), disponível em AWS Well-Architected. Este framework abrange seis pilares: excelência operacional, segurança, confiabilidade, eficiência de desempenho, otimização de custos e sustentabilidade.

Arquitetos de nuvem usam esse framework para garantir que suas soluções estejam alinhadas com as melhores práticas da AWS, geralmente após a construção, mas também pode ser usado durante a fase de design.

Começando com o Console AWS

O Console AWS é uma interface baseada na web fornecida pela AWS que permite acessar e gerenciar vários serviços e recursos AWS através de uma interface gráfica (GUI). Ele é projetado para ser amigável e acessível de qualquer navegador, permitindo que os usuários gerenciem seus recursos AWS de qualquer lugar com conexão à internet.

Usando o Console

Nesta seção, você implantará uma instância EC2, que é uma máquina virtual AWS. Para usar o Console, você deve ter uma conta AWS. O processo de criação de uma conta AWS está além do escopo deste livro, mas você pode encontrar todas as informações necessárias no site da AWS em AWS Free Tier.

Acesse o Console AWS em https://console.aws.amazon.com/.
Faça login com suas credenciais.
Navegue até o serviço EC2 usando a barra de pesquisa.
Para lançar a máquina virtual mais simples possível, sem personalização, selecione Launch instance.
Selecione Proceed without a key pair (Not recommended) no menu Key pair name e, em seguida, selecione Launch instance.
Navegue até suas instâncias em execução. Você verá uma instância EC2 em execução com um ID de instância e outros atributos.
Você pode encerrar a instância selecionando Terminate (delete) instance.

Embora o Console AWS seja uma maneira conveniente de gerenciar recursos AWS, ele tem limitações quando se trata de automação e escalabilidade. A AWS fornece ferramentas de linha de comando e SDKs para acesso programático e automação de serviços AWS que abordam essas limitações.

Navegando pela CLI e SDK da AWS

A CLI e os SDKs da AWS são ferramentas programáticas para acessar e gerenciar serviços AWS. Nesta seção, você explorará cada uma delas e as executará em seu próprio ambiente.

AWS CLI

A AWS CLI é uma ferramenta unificada da AWS que permite interagir e gerenciar serviços AWS a partir de uma linha de comando, como terminal macOS ou Prompt de Comando do Windows. Ela fornece uma maneira conveniente e scriptável de automatizar e controlar vários recursos e operações AWS.

A AWS CLI requer um processo de instalação, que varia de acordo com o sistema operacional, mas está bem documentado pela AWS em AWS CLI Installation.

Usando a AWS CLI

Nesta seção, você criará uma instância EC2 usando a AWS CLI. A autenticação funciona de maneira diferente do Console AWS. A AWS CLI suporta vários métodos de autenticação, incluindo chaves de acesso AWS, funções IAM e provedores de credenciais externos.

Para criar uma instância EC2 usando a AWS CLI, siga estas etapas:

Configure suas credenciais AWS no terminal:

   export AWS_ACCESS_KEY_ID=XXXXXXXXXX
   export AWS_SECRET_ACCESS_KEY=xxxxxxxxxx
   export AWS_DEFAULT_REGION=us-east-1

Execute o seguinte comando para criar uma instância EC2:

   aws ec2 run-instances --image-id ami-0c1e1f26f147fa7fd --instance-type t2.micro

Verifique as instâncias em execução:

   aws ec2 describe-instances

Encerre a instância:

   aws ec2 terminate-instances --instance-ids i-0a65cf3ecaec728a8

AWS SDK

Os SDKs da AWS são uma coleção de bibliotecas de código aberto que fornecem acesso programático a serviços AWS a partir de várias linguagens de programação, incluindo Java, Python, Node.js, .NET, Ruby, Go, PHP e outras. Esses SDKs permitem que os desenvolvedores criem aplicativos que interajam com recursos AWS diretamente, sem a necessidade de APIs de baixo nível.

Os SDKs abstraem as complexidades de fazer solicitações HTTP/HTTPS autenticadas para serviços AWS, lidando com repetições e tratamento de erros, e analisando as respostas dos serviços AWS. Eles fornecem uma interface de nível mais alto, específica da linguagem, que facilita a integração de serviços AWS em aplicativos.

Entendendo IaC

IaC é uma abordagem para provisionar e gerenciar recursos, como infraestrutura de nuvem. Permite definir e implantar seus recursos usando arquivos de definição ou código legíveis por humanos.

Em vez de configurar recursos manualmente através do Console AWS ou ferramentas de CLI, o IaC permite uma especificação declarativa do estado desejado da infraestrutura. No nosso contexto, isso significa a nuvem AWS, incluindo instâncias de computação, armazenamento, rede, grupos de segurança e outros serviços AWS.

Benefícios do IaC

Consistência de configuração: Promove o conceito de infraestrutura imutável, onde os componentes são tratados como descartáveis e substituíveis, em vez de serem modificados manualmente.
Controle de versão e colaboração: Os modelos e códigos de IaC podem ser armazenados em sistemas de controle de versão, como Git, permitindo colaboração, revisões de código e rastreamento de alterações.
Implantações automatizadas: Os modelos de IaC podem ser integrados a pipelines de CI/CD, permitindo implantações e atualizações automatizadas.
Teste e validação de infraestrutura: Os modelos de IaC podem ser testados e validados antes da implantação, garantindo que a infraestrutura definida atenda às especificações desejadas.
Otimização de custos e gerenciamento de recursos: Ao tratar a infraestrutura como código, as organizações podem rastrear e gerenciar melhor seus recursos AWS, permitindo melhores estratégias de otimização de custos.

Ferramentas de IaC

Existem várias ferramentas de IaC. A AWS fornece suas próprias ferramentas nativas, como AWS CloudFormation, que permite definir recursos de infraestrutura usando modelos JSON ou YAML. Também fornece o AWS Cloud Development Kit (CDK), que oferece uma abstração de nível mais alto sobre o CloudFormation, permitindo definir construções AWS usando linguagens de programação familiares, como TypeScript, Python, Java e C#.

Além das ferramentas nativas da AWS, existem soluções de IaC de terceiros, como o Terraform. O Terraform é agnóstico em relação à nuvem, suportando uma ampla gama de provedores de nuvem, incluindo a AWS, e fornece um fluxo de trabalho consistente para gerenciar infraestrutura em várias plataformas.

Usando o CloudFormation

Nesta seção, você criará uma instância EC2 usando o CloudFormation. Este é um exemplo introdutório; ele não se aprofundará em todos os recursos e sintaxes do CloudFormation.

Crie um arquivo chamado ec2.yml em seu ambiente local com o seguinte conteúdo:

   Resources:
     NewEC2Instance:
       Type: AWS::EC2::Instance
       Properties:
         ImageId: "ami-0c1e1f26f147fa7fd"
         InstanceType: "t2.micro"

Navegue até o CloudFormation usando o Console AWS em https://us-east-1.console.aws.amazon.com/cloudformation e selecione Create stack.
Selecione Upload a template file e escolha o arquivo ec2.yml criado anteriormente.
Dê um nome à stack.
Pule todas as opções e implante a stack.

Ao final do processo de implantação, o status da sua stack deve mostrar CREATE_COMPLETE. Você pode verificar a instância EC2 criada navegando até o serviço EC2.

Para excluir a instância, selecione sua stack e clique em Delete.

Usando o Terraform

Agora, você criará outra instância EC2, desta vez usando o Terraform. Esta seção assume que você já configurou seu terminal com suas credenciais AWS, conforme feito na seção anterior da AWS CLI.

Crie um arquivo chamado ec2.tf em qualquer diretório local e popule-o com o seguinte código:

   provider "aws" {
     region = "us-east-1"
   }
   resource "aws_instance" "ec2" {
     ami           = "ami-0c1e1f26f147fa7fd"
     instance_type = "t2.micro"
   }

Execute os seguintes comandos no mesmo diretório onde você criou o arquivo ec2.tf:

   terraform init
   terraform apply

Você será solicitado a confirmar. Se a execução for bem-sucedida, você verá uma saída semelhante à seguinte:

   Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
   + create
   Terraform will perform the following actions:
   # aws_instance.ec2 will be created
   + resource "aws_instance" "ec2" {
       + ami           = "ami-0c1e1f26f147fa7fd"
       + instance_type = "t2.micro"
       ...
   }
   Plan: 1 to add, 0 to change, 0 to destroy.
   Do you want to perform these actions?
     Terraform will perform the actions described above.
     Only 'yes' will be accepted to approve.
     Enter a value: yes
   aws_instance.ec2: Creating...
   aws_instance.ec2: Still creating... [10s elapsed]
   aws_instance.ec2: Still creating... [20s elapsed]
   aws_instance.ec2: Creation complete after 34s [id=i-00e732fda772c16cf]
   Apply complete! Resources: 1 added, 0 changed, 0 destroyed.

Para excluir todos os recursos, execute o seguinte comando Terraform:

   terraform destroy

O Terraform oferece muitos mais recursos, como execuções de teste usando terraform plan ou visualizações dos recursos implantados através de terraform state list. Você pode ler mais sobre isso na documentação oficial do Terraform em Terraform CLI Commands.

Resumo

Arquitetar na AWS não se trata apenas de implantar serviços AWS, mas também de coletar diferentes tipos de requisitos, contrastá-los com padrões e arquiteturas de referência conhecidos, escolher diferentes serviços e documentar tudo.

Explorar os diversos métodos e ferramentas disponíveis para implantar e interagir com serviços AWS após ter seu design. O Console AWS fornece uma interface gráfica amigável, enquanto a CLI e os SDKs da AWS permitem acesso programático e automação. Além disso, você foi exposto a várias técnicas de IaC, como Terraform, CloudFormation e AWS CDK, que permitem definir e gerenciar sua infraestrutura AWS usando código.

Ao entender essas diferentes abordagens, você pode escolher o método mais apropriado com base em seus requisitos e nível de habilidade, bem como na complexidade de suas implantações AWS. Seja preferindo uma interface visual, ferramentas de linha de comando, acesso programático ou IaC, a AWS oferece uma variedade de opções para atender às suas necessidades e simplificar suas operações de nuvem.

O Que Define uma Boa Fronteira de Microsserviço?

Eduardo Rosa — Tue, 27 May 2025 21:59:59 +0000

Introdução: Definindo as Fronteiras Certas

como decidimos o que se torna um microsserviço? Dividir um sistema grande em partes menores parece bom, mas fazer as divisões erradas pode criar mais problemas do que soluções. Como encontrar as "fronteiras" ideais para nossos microsserviços, garantindo que eles sejam coesos, independentes e alinhados ao negócio.

O Que Define uma Boa Fronteira de Microsserviço?

Encontrar a divisão certa é uma arte, mas existem princípios que nos guiam:

Ocultação de Informação (Information Hiding): Um princípio clássico da engenharia de software. Cada microsserviço deve esconder seus detalhes internos (como sua estrutura de banco de dados ou lógica complexa) atrás de uma interface bem definida (a API). Outros serviços só interagem através dessa interface, sem precisar saber como o serviço funciona por dentro. Isso permite que a implementação interna mude sem quebrar quem depende do serviço.
Coesão (Cohesion): As funcionalidades dentro de um microsserviço devem estar fortemente relacionadas, trabalhando juntas para um propósito comum. Um serviço deve ter uma responsabilidade clara e única. Por exemplo, um serviço de "Gerenciamento de Perfis de Usuário" é coeso se lida apenas com dados e operações de perfil. Se ele também começa a gerenciar postagens de blog, ele perde coesão.
- Visual: Um diagrama mostrando um círculo (microsserviço) com vários pontos relacionados dentro (alta coesão) vs. um círculo com pontos desconexos (baixa coesão).
Acoplamento (Coupling): Mede o grau de dependência entre microsserviços. Queremos baixo acoplamento, ou seja, que as mudanças em um serviço tenham o mínimo impacto possível em outros. Se para alterar o serviço A, você sempre precisa alterar o serviço B, eles estão fortemente acoplados.

A Dança entre Coesão e Acoplamento: Geralmente, buscar alta coesão dentro de um serviço ajuda a alcançar baixo acoplamento entre serviços. Se um serviço faz uma coisa bem feita (alta coesão), ele tende a depender menos dos detalhes internos de outros (baixo acoplamento).

Tipos de Acoplamento (O Que Evitar)

Acoplamento de Domínio (Domain Coupling): O mais comum. Um serviço precisa entender parte do domínio de outro para interagir. É necessário, mas deve ser minimizado.
Acoplamento Passa-Através (Pass-Through Coupling): O serviço A chama B, que apenas repassa a chamada para C. Isso adiciona complexidade desnecessária.
Acoplamento Comum (Common Coupling): Vários serviços dependem de um recurso compartilhado, como um banco de dados. Isso é muito perigoso em microsserviços, pois viola a autonomia (cada um deve ter seus dados).
Acoplamento de Conteúdo (Content Coupling): O pior tipo! O serviço A modifica ou depende diretamente dos dados internos do serviço B (ex: acessa a tabela do banco de dados do outro). Isso destrói a independência e deve ser evitado a todo custo. ## Domain-Driven Design (DDD): Uma Ferramenta Poderosa

Como encontrar essas fronteiras coesas e de baixo acoplamento na prática? O Design Orientado ao Domínio (DDD) oferece conceitos valiosos:

Linguagem Ubíqua (Ubiquitous Language): Criar um vocabulário comum entre desenvolvedores e especialistas do negócio para descrever o domínio. Falar a mesma língua evita ambiguidades e ajuda a modelar o software de forma mais precisa.
Agregado (Aggregate): Um agrupamento de objetos de domínio que são tratados como uma única unidade. Pense em um "Pedido" em um e-commerce. Ele inclui itens, endereço de entrega, status, etc. O Agregado "Pedido" garante que todas essas partes sejam consistentes. Geralmente, um microsserviço é modelado em torno de um ou mais agregados.
Contexto Delimitado (Bounded Context): Define uma fronteira clara onde um modelo de domínio específico (e sua Linguagem Ubíqua) é válido. Dentro do contexto de "Vendas", a palavra "Cliente" pode ter um significado; no contexto de "Suporte", pode ter outro. O Bounded Context é frequentemente o candidato ideal para se tornar um microsserviço. Ele encapsula um modelo e protege sua integridade.

Mapeando DDD para Microsserviços: A ideia central é alinhar as fronteiras dos microsserviços com as fronteiras dos Bounded Contexts identificados no domínio do negócio. Isso naturalmente leva a serviços mais coesos e com menor acoplamento.

Event Storming: Uma técnica colaborativa (workshop) mencionada para ajudar a descobrir esses domínios, eventos e contextos delimitados, envolvendo tanto técnicos quanto especialistas do negócio.

O Poder da Arquitetura Orientada a Eventos

Eduardo Rosa — Fri, 28 Feb 2025 12:44:11 +0000

A arquitetura orientada a eventos (Event-Driven Architecture - EDA) tem ganhado destaque no design de software moderno. Com a ascensão dos microsserviços, big data e processamento em tempo real, as empresas precisam de uma maneira escalável e flexível para gerenciar interações entre diferentes componentes.
Neste artigo, exploraremos os princípios da arquitetura orientada a eventos, seu crescimento em popularidade e estudos de caso de empresas como Netflix e Uber, que utilizam esse modelo para processar bilhões de eventos diariamente.

O Problema das Arquiteturas Tradicionais
À medida que um sistema cresce e novos serviços são introduzidos, o modelo tradicional de solicitação e resposta torna-se menos eficiente. Em um cenário simples, o serviço A solicita dados do serviço B, que processa a solicitação e envia uma resposta. No entanto, com a adição de novos serviços, a complexidade cresce exponencialmente. Cada serviço deve conhecer e gerenciar múltiplas interações, resultando em forte acoplamento e dificuldades de escalabilidade e manutenção.
A introdução ou atualização de um serviço pode impactar toda a rede de conexões, aumentando o risco de falhas. É aqui que a arquitetura orientada a eventos entra em cena.

Como Funciona a Arquitetura Orientada a Eventos
O EDA desacopla os serviços por meio da comunicação baseada em eventos, permitindo sistemas mais escaláveis, flexíveis e eficientes. Neste modelo, os serviços não se chamam diretamente; em vez disso, reagem a eventos.

Componentes Principais da EDA

Produtores de Eventos: Serviços que geram eventos. Por exemplo, em um e-commerce, o serviço de pedidos pode gerar um evento "Pedido Realizado" ou "Pagamento Concluído".
Consumidores de Eventos: Serviços que reagem a eventos. No exemplo do e-commerce, o serviço de estoque pode consumir o evento "Pedido Realizado" para atualizar a quantidade disponível, enquanto o serviço de remessa inicia o envio do produto.
Corretor de Mensagens (Message Broker): Middleware que gerencia o tráfego de eventos, como Apache Kafka, RabbitMQ ou AWS EventBridge, garantindo comunicação assíncrona entre produtores e consumidores.

Benefícios do EDA

Desacoplamento: Serviços podem operar de forma independente, facilitando manutenção e escalabilidade.
Escalabilidade: Como os serviços não dependem de chamadas diretas, cada componente pode ser escalado separadamente.
Processamento em Tempo Real: Eventos são propagados imediatamente, permitindo respostas rápidas a mudanças no sistema.

Estudos de Caso: Netflix e Uber

Netflix: Processamento Massivo de Eventos em Tempo Real
A Netflix processa bilhões de eventos diários para aprimorar a experiência do usuário. A cada ação realizada – iniciar um novo programa, avaliar um filme ou pausar um streaming –, um evento é gerado e consumido por serviços como o mecanismo de recomendação. Por exemplo, ao começar a assistir uma nova série, um evento é disparado para atualizar sugestões personalizadas.
Além disso, a Netflix monitora continuamente seus serviços. Se um deles começa a falhar, eventos são gerados e consumidos por sistemas de monitoramento para alertar engenheiros ou ativar processos de recuperação automática.

Uber: Coordenação em Tempo Real
O Uber opera globalmente, gerenciando milhões de solicitações de viagem diariamente por meio do EDA. Quando um usuário solicita uma corrida, um evento "Viagem Solicitada" é gerado e consumido por diferentes serviços:

Serviço de Correspondência encontra um motorista disponível.
Serviço de Preços calcula o custo da corrida.
Serviço de Roteamento otimiza o trajeto com base em condições de tráfego em tempo real. A capacidade de coletar e processar eventos de telemetria em tempo real permite ao Uber ajustar preços dinâmicos e fornecer informações precisas sobre tempos de chegada.

EDA, Malha de Serviços e o Padrão Sidecar
Embora a EDA promova comunicação assíncrona baseada em eventos, há cenários onde a comunicação síncrona entre serviços ainda é necessária. Para isso, muitas empresas combinam EDA com malhas de serviço (Service Mesh), que gerenciam chamadas diretas entre serviços, garantindo balanceamento de carga e roteamento eficiente.
Uma malha de serviço geralmente implementa o padrão sidecar, onde proxies controlam o tráfego de rede entre microsserviços, oferecendo segurança, monitoramento e descoberta de serviços.

Tipos de Processamento de Eventos
O EDA pode ser implementado de duas formas principais:

Processamento de Eventos Simples: Cada evento aciona uma resposta direta. Exemplo: um evento "Pedido Realizado" aciona atualizações de estoque e preparação para envio.
Processamento de Eventos Complexos: Múltiplos eventos são analisados para detectar padrões. Exemplo: o sistema de preços do Uber monitora demanda, tráfego e disponibilidade de motoristas para ajustar tarifas dinâmicas.

Desafios e Considerações ao Implementar EDA
Embora traga inúmeros benefícios, a arquitetura orientada a eventos também apresenta desafios:

Ordem e Consistência: Garantir a ordem correta dos eventos pode ser complexo. Algumas operações precisam ser idempotentes para evitar duplicações (ex.: evitar cobranças duplicadas ao processar pagamentos).
Gerenciamento de Estado: Como os serviços são desacoplados, manter a consistência entre sistemas requer estratégias como event sourcing e sagas.
Ferramentas e Infraestrutura: Tecnologias como Apache Kafka, AWS SNS/SQS e RabbitMQ ajudam a implementar EDA, mas exigem planejamento para evitar gargalos e perda de mensagens.

Conclusão
A arquitetura orientada a eventos não é apenas uma tendência, mas um pilar essencial para sistemas modernos de grande escala. Empresas como Netflix e Uber demonstram que o EDA pode proporcionar maior flexibilidade, escalabilidade e eficiência no processamento de eventos em tempo real.
Com as ferramentas e estratégias corretas, qualquer empresa pode adotar o EDA para aprimorar sua infraestrutura, reduzir o acoplamento entre serviços e preparar seus sistemas para o futuro da computação em nuvem e microsserviços.