Douglas Picolotto

Olá pessoal, tudo bem?

Dando um intervalinho na série sobre o Well-Architected Framework, vamos falar um pouco sobre o padrão sidecar, que ficou mais conhecido recentemente, quando outro pattern que falarei no futuro, o Service Mesh, ganhou popularidade.

Definição

O sidecar pattern ganhou esse nome, pois ele lembra os sidecars utilizados em motos. O que faz bastante sentido, pois, como veremos a seguir, ele visa estender e melhorar funcionalidades de um outro processo ou container (na comparação, a moto).

Para manter a simplicidade, no restante do post me aterei apenas a containers, que é onde este padrão é mais popular.

Em seu funcionamento, um sidecar andará sempre junto do container principal (a aplicação), de forma simbiótica, como se fossem um componente só. Alguns orquestradores, como o Kubernetes ou o ECS, facilitam este processo por meio de seus constituintes, os pods e as tasks, respectivamente, que facilitam a execução de containers co-localizados, compartilhando recursos de networking, disco, entre outros.

Nestes casos, a comunicação entre eles se dá através do endereço de loopback (127.0.0.1 ou localhost), que, consequentemente, garante uma latência muito pequena na comunicação.

Cenários

Abaixo falaremos brevemente sobre alguns cenários onde poderemos utilizar este padrão, com o intuito de deixar esta ideia mais clara.

Proxy reverso

Uma das principais funções do sidecar, inclusive no padrão Service Mesh, é a função de proxy reverso. Neste cenário, o sidecar irá receber todas as requisições externas e irá encaminhá-las para o container principal.

Isso possibilita que funções de caching, entrega de arquivos estáticos, log de requisições, SSL, entre outras, sejam removidas da aplicação e atribuídas ao sidecar.

Monitoramento

Outra função de um sidecar é monitoramento. Fazendo o deploy de um sidecar como monitor, permite a extração de métricas de estado do container principal, do próprio sidecar e do daemon onde ambos executam, possibilitando, posteriormente, o envio destas informações para um serviço centralizado.

Ambassador

O Ambassador (ou embaixador) é um padrão com uma função contrária ao proxy reverso citado anteriormente. Ele servirá como um proxy, mas para todas as requisições que saem da aplicação principal e acessam serviços externos.

Isso nos dá a possibilidade de manipular uma série de aspectos relacionados a conectividade com estes serviços, logging, caching, routing, sharding, segurança, etc.

Por que utilizar?

Como vimos nos exemplos citados acima, o container sidecar absorve uma série de funcionalidades que estariam na aplicação (container principal), caso o mesmo não existisse. Isto possibilita a separação de responsabilidades, permitindo que o desenvolvedor mantenha o foco no desenvolvimento das features necessárias para o negócio, se preocupando menos com requisitos não-funcionais.

Além disso, o sidecar pode ser utilizado em diversos serviços do sistema, promovendo o reaproveitamento de recursos/código (como vimos no exemplo do sidecar como monitor, acima). Uma arquitetura de microserviços, por exemplo, pode se beneficiar bastante deste padrão. Contudo, para este reaproveitamento ser possível, o sidecar deve permitir uma configuração flexível o suficiente para ser reutilizado adequadamente.

Quando não utilizar?

Como nem tudo são flores, o sidecar também possui alguns downsides que deveremos cuidar quando formos utilizá-lo.

Cenários onde a latência extrema é prioridade, ele pode não ser uma boa opção, visto que, por se tratar de comunicação entre processos, teremos uma latência mínima, mas teremos.

Outro aspecto importante a ser considerado é que ele pode trazer demasiada complexidade para aplicações simples, inviabilizando a sua utilização.

Para quem quiser saber mais sobre o sidecar, pode clicar aqui para visitar o centro de arquitetura da Microsoft, que possui uma excelente documentação sobre este padrão.

Abraços e boa semana!