Sidecar Pattern: Ineficiência Operacional e Computacional ou Uma Carta na Manga? 🤔♣️

Compilado do newsletter:

  • O Sidecar Pattern é um processo/container secundário que roda ao lado do processo/container principal para lidar com funções complementares sem acoplar à aplicação.
  • Ele é útil para observabilidade, segurança, service discovery e integração com sistemas legados, reduzindo impacto ou acoplamento no código principal.
  • Pode gerar ineficiência e aumento de custos, pois exige seus próprios recursos de CPU, memória e disco, tornando essencial avaliar se o custo-benefício justifica seu uso na arquitetura.

Se até o fim do newsletter você curtir o conteúdo e quiser se aprofundar mais em arquitetura de software, venha fazer parte da Comunidade de Arquitetura Descomplicada (CaD)! Saiba mais em https://mugnos-it.com/cad/ 🚀


Sidecar Pattern: Ineficiência Operacional e Computacional ou Uma Carta na Manga? 🤔♣️

Sempre tive dúvidas sobre a real eficiência do Sidecar Pattern. Será que ele só adiciona complexidade e consumo desnecessário de recursos? Ou realmente pode ser um trunfo na arquitetura? Até que entendi como ele pode ser uma peça-chave em alguns cenários bem específicos, como observabilidade, segurança e integração com sistemas legados ou refactor de código.

O Sidecar Pattern é uma abordagem onde um componente complementar roda ao lado da aplicação principal, normalmente dentro do mesmo pod (em Kubernetes) ou máquina, mas isolado da lógica central do app. Ele permite desacoplar funcionalidades transversais sem modificar o código do serviço principal, como por exemplo no mesmo POD subir um container com GO e fazendo chamadas para o container no mesmo POD para utilização de alguma função que esta em alguma outra linguagem, como por exemplo Java.

Agora, vamos ver casos de usos reais onde o Sidecar Pattern geralmente é usado, mas antes, só pra garantir que vc entendeu o que é Sidecar, essa imagem abaixo é o que um Sidecar signficia, uma moto com uma direção central e um “container” ao lado que pode ser multiuso, tanto para colocar pessoas como qualquer outra coisa.

(Não… não… essa imagem não esta tentando dizer que a tartaruga representa o famoso rígido e rápido Java!!! Essa conclusão foi sua… haha 👀)

Voltando para realidade, aqui estão alguns casos de usos onde o Sidecar é geralmente usado:

➡️ Logging e Observabilidade

O Sidecar Pattern pode ser usado para lidar com logging, métricas e tracing distribuído de forma centralizada. Em vez de cada serviço implementar sua própria lógica de coleta de logs e métricas, um sidecar dedicado pode interceptar e encaminhar esses dados para ferramentas como Fluentd ou OpenTelemetry. Isso reduz o acoplamento da aplicação com soluções específicas de observabilidade e facilita a padronização do monitoramento sem modificar o código dos serviços principais.

Note que em alguns casos faz mais sentido você ter um agente rodando como daemonset e coletando de todos PODs, mas como tudo… depende do seu ambiente e do que esta tentando fazer.

Exemplo: Já precisei usar o Sidecar Pattern para instalar o OpenTelemetry em uma task definition do AWS App Mesh rodando no ECS. O sidecar capturava os logs do STDOUT do container principal e os encaminhava para o Splunk, garantindo observabilidade sem modificar a aplicação.

Bons tempos… Mas agora a AWS anunciou que o AWS App Mesh será descontinuado até o final de 2026 😭😭. (Não que eu vá sentir falta—prefiro outras soluções de service mesh no EKS 😎).


➡️ Service Discovery

O Sidecar Pattern pode facilitar a descoberta de serviços ao atuar como um intermediário na comunicação entre aplicações. Em arquiteturas dinâmicas, como Kubernetes, os serviços podem mudar de IP ou serem escalados dinamicamente, tornando difícil a conexão direta entre eles.

Com um service mesh como Istio ou Linkerd, cada serviço tem um sidecar proxy (geralmente Envoy) que intercepta e gerencia as requisições. Isso permite que os serviços se comuniquem sem precisar saber exatamente onde os outros estão, pois o sidecar lida com a resolução dos endereços automaticamente.

Hoje, isso é algo tão automático no Kubernetes que muitas vezes nem percebemos. Mas já precisei usar um sidecar para registrar e remover serviços de uma base de dados ao integrar com um Mainframe. Poderia ter feito isso diretamente no container principal? Sim, mas a complexidade teria sido bem maior!”


Exemplo:

Em um sistema de e-commerce, o serviço de checkout precisa se comunicar com o serviço de pagamento, mas os pods de pagamento podem escalar ou reiniciar a qualquer momento. Com um sidecar atuando no service discovery, o serviço de checkout pode simplesmente enviar a requisição para o proxy local, que roteia automaticamente para uma instância válida do serviço de pagamento, sem que o app precise lidar com mudanças de IPs ou DNS.

➡️ Proxy e Routing

Em arquiteturas distribuídas, lidar com balanceamento de carga, retries e failover pode ser um desafio, principalmente quando cada serviço precisa implementar essas regras por conta própria. O Sidecar Pattern resolve isso ao adicionar um proxy inteligente, como o Envoy, que gerencia a comunicação entre microsserviços de forma transparente.

Exemplo:

Imagine um sistema de e-commerce onde o serviço de checkout precisa se comunicar com o serviço de pagamentos. Se um dos pods de pagamentos estiver sobrecarregado ou indisponível, um sidecar proxy pode automaticamente redirecionar a requisição para outra instância saudável, sem que o serviço de checkout precise lidar com essa lógica. Além disso, se uma requisição falhar, o proxy pode aplicar um retry inteligente, reduzindo a chance de falhas percebidas pelo usuário.

Outro benefício é o controle de tráfego. Se você quiser fazer um canary deployment, onde apenas 10% dos usuários acessam a nova versão do serviço, o sidecar pode rotear o tráfego dinamicamente, sem alterar o código da aplicação.

Com isso, o Sidecar Pattern não só melhora a resiliência do sistema, mas também facilita a implementação de estratégias avançadas de deploy e roteamento. 🚀

➡️ Autenticação e Segurança

Em vez de implementar autenticação dentro de cada serviço, um sidecar pode lidar com JWTs, certificados mTLS e até Rate Limiting, garantindo um controle mais centralizado.

Gerenciar autenticação e segurança em uma arquitetura distribuída pode ser complexo, especialmente quando cada serviço precisa validar tokens, gerenciar certificados e aplicar restrições de acesso individualmente. O Sidecar Pattern resolve isso ao centralizar essas responsabilidades, garantindo mais consistência e reduzindo a complexidade dentro dos microsserviços.

Lembra do SOLID? Pois é, Single Responsibility Principle! Se o seu microsserviço é responsável pelo checkout, por que ele deveria lidar com autenticação também? Além de misturar responsabilidades, qualquer mudança no mecanismo de autenticação exigiria atualizar todos os microsserviços que dependem dele. Já viu esse filme? Eu já – e várias vezes! O resultado? Código duplicado, menos agilidade e um impacto direto no time to market.

Exemplo:

Imagine um ambiente onde múltiplos serviços precisam validar JWTs para autorizar requisições. Em vez de cada serviço implementar essa lógica, um sidecar pode atuar como um gateway de autenticação, interceptando as requisições, validando tokens e só encaminhando requisições válidas para os serviços principais.

Outro caso comum é o uso de mTLS (Mutual TLS) para garantir que apenas serviços autorizados consigam se comunicar dentro da infraestrutura. Um sidecar pode gerenciar certificados automaticamente, garantindo que a aplicação se comunique de forma segura sem precisar se preocupar com rotação de chaves ou configurações complexas de criptografia.

Além disso, Rate Limiting pode ser aplicado diretamente no sidecar, protegendo os serviços contra abuso e DDoS, sem necessidade de código adicional nos microsserviços. Por exemplo, um serviço de checkout pode ter um limite de 100 requisições por segundo, bloqueando requisições excedentes diretamente no sidecar antes de sobrecarregar o backend.

➡️ Libs Compartilhadas ou Legadas

Em muitos sistemas, especialmente em migrações de arquiteturas monolíticas para microsserviços, pode haver bibliotecas legadas ou proprietárias que ainda são essenciais para o funcionamento da aplicação. Em vez de incluir essas dependências em cada serviço, um sidecar pode encapsular essa lógica e expô-la via API local, garantindo que todos os microsserviços possam acessá-la sem acoplamento direto.

Se você leu e não ficou 100% claro, sugiro :

while [ ! $understood ]; do read_again “Libs Compartilhadas ou Legadas”; done

Exemplo:

Imagine que você tem uma biblioteca de cálculo de impostos usada há anos no monolito, mas que agora precisa ser acessada por vários microsserviços sem reescrevê-la. Em vez de integrar essa lib em cada serviço (o que geraria problemas de versão, compatibilidade e manutenção), um sidecar pode rodar essa biblioteca separadamente e expor um endpoint local, permitindo que os serviços consultem os cálculos sem depender diretamente da implementação.

Isso também facilita migrações graduais, permitindo que a lógica seja substituída ou modernizada no sidecar sem impactar os microsserviços que a utilizam. 🚀

🚀 Conclusão

O Sidecar Pattern pode ser uma solução poderosa para desacoplar funcionalidades transversais, mas não é uma bala de prata. Como ele roda em um pod separado, pode gerar ineficiência de capacidade, já que consome CPU, memória e espaço em disco próprios, aumentando o consumo computacional. Em ambientes mal planejados, isso pode escalar mal e até encarecer a infraestrutura sem trazer um benefício que valha a pena.

No fim, a pergunta não é “Devo usar Sidecar?”, mas sim “Faz sentido usar Sidecar neste contexto?”. Se a resposta for sim, você tem um grande indicativo que deve usar.

mas como sempre digo na CaD (Comunidade de Arquitetura Descomplicada), não adianta aprender um pattern e sair aplicando ele como se fosse a solução para todos problemas.

Arquitetura não é sobre ter um martelo e sair procurando pregos—é sobre ter várias ferramentas e saber qual escolher para cada situação.

E é aqui que vem a melhor analogia: escolher um pattern é como escolher um(a) parceiro(a) de vida. Você precisa conhecê-los bem, entender os trade-offs e, principalmente, escolher pelos defeitos, não só pelas virtudes. Afinal, sabendo os desafios de antemão hehehe 😂 

E aí, já passou por alguma situação onde um Sidecar fez (ou não fez) sentido? Vários já estão compartilhando suas experiências, e essa troca de informações tem sido sensacional! Em breve, quando tivermos um número maior de pessoas engajadas, a ideia é abrir um grupo no WhatsApp para discutirmos ainda mais sobre arquitetura. O que acha dessa ideia?


🚨Se curtiu esse conteúdo e quer aprender mais sobre arquitetura de software e um nível bem mais aprofundado, venha fazer parte da
Comunidade de Arquitetura Descomplicada (CaD)! Saiba mais em https://mugnos-it.com/cad/ 🚀🚨

Abraços!

Douglas Mugnos

guest
0 Comentários
Mais Velhos
Mais Novos Mais Votados
Inline Feedbacks
Veja todos comentários
0
Gostaria muito de saber sua opinião!x