Shared Nothing Architecture
Hoje em dia quando estamos entregando software podem surgir varias questões, por exemplo:
- Onde o sistema vai viver? (em termos de nuvem e hospedagem)
- Como o sistema será distribuído? (em termos de acesso público)
- Qual será a infraestrutura? (em termos de tecnologia)
- Como o sistema será publicado? (em termos de pacote e pipeline)
- etc…
Antigamente era muito comum que nossos sistemas fossem configurados e publicados em máquinas fisicas e através de algumas configurações o mesmo fosse publicamente acessível na internet através de algum endereço (comumente o tal do DNS (domain name system)).
Dessa forma sempre que havia uma nova versão do sistema à ser publicada a gente precisava parar o serviço da máquina, atualizar o pacote e depois subir o serviço novamente.
Muitas vezes nosso sistema era um grande pacote que continua toda a fonte da aplicação como um único entregável rodando tudo no mesmo processo.
O problema é que nessa única máquina em alguns momentos eram publicados e hospedados varios outros sistemas que também compartilham os recursos computacionais entre si (hardware).
Depois surgiram as famosas máquinas virtuais (VM’s), que ajudaram no processo e necessidade de configurar várias máquinas físicas (começamos automatizar tais provisionamentos de máquinas com códigos versionados (infraestrutura como código)), mas, em uma mesma máquina física ainda podiam rodar (e muitas vezes rodavam) vários sistemas distintos (compartilhando o mesmo hardware).
Mas, será que atualmente não podemos ter alguma forma de isolar tais sistemas em seus próprios processos consumindo e utilizando seus próprios recursos (que também podem ser limitados)? Sim, isso é possível.
Shared nothing architecture
A ideia dessa arquitetura é que cada sistema rode em seu próprio nó, através do seu próprio processo e que esse processo tenha seus próprios recursos computacionais (memória, disco, rede, CPU, etc…).
Podemos atingir tal objetivo utilizando tecnologias de container e orquestração de container, tais como: Docker e Kubernetes.
Cada sistema também pode ser dividido em múltiplos nós formando um cluster que distribuí a carga entre os mesmos e cada nó pode ser comunicar através de uma rede.
Alguns pontos positivos:
- Desacoplamento
- Autonomia dos sistemas
- Unidades de deploys separadas
- Separação de custos
- Escalabilidade necessária
- Distribuição de carga (load balance)
- Troca de infraestrutura menos complexa
- Custos menores
- Limitação de recursos por sistemas
Alguns pontos negativos:
- Alta complexidade
- Tracing e observabilidade distribuída
- Compartilhamento de tecnologias (o que pode gerar um alto acoplamento): Frameworks, bibliotecas, logging, monitoramento, service discovery, etc…
- Coordenar processos distribuídos que atingem múltiplos nós
Conclusão
Nesse post vimos como construir arquitetura que seja desacoplada e isole recursos computacionais entre contextos.
Abraços, até a próxima.