Implemente componentes de uma aplicação num processo ou contentor separado, para oferecer isolamento e encapsulamento. Este padrão também pode ativar as aplicações a ser compostas por componentes heterogéneos e tecnologias.
Este padrão é denominado Sidecar porque se assemelha a um sidecar ligado a um motociclo. No padrão, o sidecar está ligado a uma aplicação principal e proporciona funcionalidades de suporte para a aplicação. O sidecar também partilha o mesmo ciclo de vida da aplicação principal, que está a ser criado e extinguido juntamente com o elemento principal. O padrão de sidecar é, por vezes, referido como o padrão de sidekick e é um padrão de decomposição.
Contexto e problema
As aplicações e serviços, muitas vezes, precisam de funcionalidades relacionadas, como monitorização, registo, configuração e serviços de rede. Estas tarefas periféricas podem ser implementadas como componentes ou serviços separados.
Se eles estiverem fortemente integrados ao aplicativo, eles podem ser executados no mesmo processo que o aplicativo, fazendo uso eficiente de recursos compartilhados. No entanto, isso também significa que eles não estão bem isolados, e uma interrupção em um desses componentes pode afetar outros componentes ou todo o aplicativo. Além disso, normalmente, têm de ser implementados com a mesma linguagem que a aplicação principal. Como resultado, o componente e a aplicação estão estreitamente interligados.
Se a aplicação for decomposta em serviços, cada serviço poderá ser criado através de linguagens e tecnologias diferentes. Embora proporcione uma maior flexibilidade, significa que cada componente tem as suas próprias dependências e requer bibliotecas específicas da linguagem para aceder à plataforma subjacente e a quaisquer recursos partilhados com a aplicação principal. Além disso, a implementação destas funcionalidades como serviços separados pode adicionar latência à aplicação. A gestão do código e das dependências para estas interfaces específicas da linguagem pode também adicionar uma complexidade considerável, especialmente para o alojamento, a implementação e a gestão.
Solução
Colocalize um conjunto coeso de tarefas com a aplicação principal, mas coloque-as no interior do seu próprio processo ou contentor, fornecendo uma interface homogénea para serviços da plataforma nas várias linguagens.
Um serviço de sidecar não faz necessariamente parte da aplicação, mas está ligado a ela. Vai onde a aplicação vai. Os sidecars são processos ou serviços de apoio que são implementados com a aplicação principal. Num motociclo, o sidecar está ligado a um motociclo e cada um pode ter o seu próprio sidecar. Da mesma forma, um serviço de sidecar partilha o destino da aplicação principal. Para cada instância da aplicação, uma instância do sidecar é implementada e alojada em conjunto com a mesma.
Vantagens da utilização de um padrão de sidecar:
Um sidecar é independente da aplicação principal em termos de ambiente de tempo de execução e linguagem de programação, pelo que não precisa de desenvolver um sidecar por linguagem.
O sidecar pode aceder aos mesmos recursos que a aplicação principal. Por exemplo, um sidecar pode monitorizar os recursos do sistema utilizados pelo sidecar e pela aplicação principal.
Devido à sua proximidade com o aplicativo principal, não há latência significativa na comunicação entre eles.
Mesmo para aplicativos que não fornecem um mecanismo de extensibilidade, você pode usar um sidecar para estender a funcionalidade anexando-o como seu próprio processo no mesmo host ou subcontêiner que o aplicativo principal.
O padrão de sidecar é, muitas vezes, utilizado com contentores e referido como um contentor de sidecar ou contentor de sidekick.
Problemas e considerações
- Considere a implementação e o formato de empacotamento que irá utilizar para implementar serviços, processos ou contentores. Os contentores são particularmente adequados para o padrão do sidecar.
- Ao conceber um serviço de sidecar, decida cuidadosamente o mecanismo de comunicação interprocessos. Tente utilizar tecnologias de linguagem ou arquitetura desconhecidas, exceto se os requisitos de desempenho o tornarem impraticável.
- Antes de colocar a funcionalidade num sidecar, considere se funciona melhor como um serviço separado ou um daemon mais tradicional.
- Também considere se a funcionalidade pode ser implementada como uma biblioteca ou com a ajuda de um mecanismo de extensão tradicional. As bibliotecas específicas da linguagem podem ter um nível mais aprofundado de integração e menos custos de rede.
Quando utilizar este padrão
Utilize este padrão quando:
- Seu aplicativo principal usa um conjunto heterogêneo de linguagens e estruturas. Um componente localizado num serviço de sidecar pode ser utilizado por aplicações escritas em linguagens diferentes, através de arquiteturas diferentes.
- Um componente pertencer a uma equipa remota ou a uma organização diferente.
- Um componente ou recurso deve estar colocalizado no mesmo host que o aplicativo.
- Precisar de um serviço que partilhe o ciclo de vida global da aplicação principal, mas que possa ser atualizado de forma independente.
- Precisat de um controlo detalhado dos limites de recursos para um componente ou recurso em particular. Por exemplo, poderá querer restringir a quantidade de memória que um componente específico utiliza. Pode implementar o componente como um sidecar e gerir a utilização de memória, independentemente da aplicação principal.
Este padrão pode não ser adequado:
- Quando a comunicação interprocessos tem de ser otimizada. A comunicação entre uma aplicação principal e os serviços de sidecar inclui alguma sobrecarga, nomeadamente latência nas chamadas. Esta desvantagem pode não ser aceitável para conversações longas.
- Para aplicações pequenas onde o custo de recursos de implementação de um serviço de sidecar para cada instância não valha a vantagem de isolamento.
- Quando o serviço tem de dimensionar de forma diferente ou independente das aplicações principais. Se assim for, poderá ser melhor implementar a funcionalidade como um serviço separado.
Design da carga de trabalho
Um arquiteto deve avaliar como o padrão Sidecar pode ser usado no design de sua carga de trabalho para abordar os objetivos e princípios cobertos nos pilares do Azure Well-Architected Framework. Por exemplo:
| Pilar | Como esse padrão suporta os objetivos do pilar |
|---|---|
| As decisões de design de segurança ajudam a garantir a confidencialidade, integridade e disponibilidade dos dados e sistemas da sua carga de trabalho. | Ao encapsular essas tarefas e implantá-las fora do processo, você pode reduzir a área de superfície de processos confidenciais apenas para o código necessário para realizar a tarefa. Você também pode usar sidecars para adicionar controles de segurança transversais a um componente de aplicativo que não foi projetado nativamente com essa funcionalidade. - SE:04 Segmentação - Encriptação SE:07 |
| A Excelência Operacional ajuda a fornecer qualidade de carga de trabalho por meio de processos padronizados e coesão da equipe. | Esse padrão fornece uma abordagem para implementar flexibilidade na integração de ferramentas que pode melhorar a observabilidade do aplicativo sem exigir que o aplicativo assuma dependências diretas de implementação. Permite que a funcionalidade do sidecar evolua de forma independente e seja mantida independentemente do ciclo de vida da aplicação. - OE:04 Ferramentas e processos - OE:07 Sistema de monitorização |
| A Eficiência de Desempenho ajuda sua carga de trabalho a atender às demandas de forma eficiente por meio de otimizações em escala, dados e código. | Você pode mover tarefas transversais para um único processo que pode ser dimensionado em várias instâncias do processo principal, o que reduz a necessidade de implantar funcionalidade duplicada para cada instância do aplicativo. - PE:07 Código e infraestrutura |
Como em qualquer decisão de design, considere quaisquer compensações em relação aos objetivos dos outros pilares que possam ser introduzidos com esse padrão.
Exemplo
O padrão de sidecar é aplicável a vários cenários. Alguns exemplos comuns:
- API da infraestrutura. A equipa de desenvolvimento da infraestrutura cria um serviço que é implementado juntamente com cada aplicação, em vez de uma biblioteca de cliente específica da linguagem para aceder à infraestrutura. O serviço está carregado como um sidecar e proporciona uma camada comum para os serviços de infraestrutura, incluindo registos, dados do ambiente, arquivo de configuração, deteção, verificações do estado de funcionamento e serviços de watchdog. O sidecar também monitoriza o ambiente do anfitrião da aplicação principal e o processo (ou contentor) e regista as informações num serviço centralizado.
- Gerir o NGINX/HAProxy. Implemente o NGINX com um serviço de sidecar que monitoriza o estado do ambiente, atualiza o ficheiro de configuração NGINX e recicla o processo quando é preciso uma alteração do estado.
- Sidecar ambassador. Implemente um serviço ambassador como um sidecar. A aplicação chama através do ambassador, que processa o registo de pedidos, encaminhamento, disjuntor de circuito e outras funcionalidades relacionadas com a conectividade.
- Descarregar o proxy. Coloque um proxy NGINX à frente de uma instância de serviço node.js, para processar o conteúdo do ficheiro estático do serviço.