Martin Campbell, especialista em escalabilidade de microservices na DigitalOcean,falou sobre como rodar Orquestradores distribuídos em uma arquitetura de microservices na conferência MicroXchg Berlin de 2017. Ele focou nos problemas encontrados durante o processo de migração, e falou sobre as vantagens e desvantagens dos orquestradores como Kubernetes, Nomad e Mesos.
Alguns pontos importantes:
- Orquestradores distribuídos podem ser gerenciados em um cluster como se fossem uma máquina virtual.
- Eles deixam DevOps mais fácil, reduzindo uma grande complexidade operacional que está presente em uma arquitetura de microservices.
- Nenhum desses orquestradores rodam serviços stateful muito bem. Dessa forma é recomendável que não você utilize nenhum deles para rodar esse tipo de serviço.
- No caso de uma partição de rede, um orquestrador que seja tolerante a falhas deve deixar todos os seus serviços rodando, mesmo que ele não consiga se comunicar com a máquina líder do seu cluster.
Campbell explica que o kernel de um sistema operacional é um orquestrador centralizado. Isso ocorre porque ele é o responsável por gerenciar diversos processos em uma única máquina. Ele afirma que o conceito de um orquestrador distribuído é exatamente o mesmo, exceto que ele funciona em um conjunto de máquinas ao invés de uma só:
Você está levando todo seu datacenter e tratando como se fosse apenas uma máquina virtual.
Orquestradores distribuídos são particularmente benéficos em uma arquitetura de microservices. Campbell acredita que isso ocorre pela sobrecarga operacional causada pelos diversos serviços que são constantemente escalados e implantados.
Comparando vários orquestradores distribuídos, Campbell primeiro falou sobre sua experiência com Mesos. Utilizando o Mesos você não precisa se preocupar com os recursos de uma máquina física que o processo utiliza, pois ele lida com o gerenciamento dos recursos e atribuí cotas de utilização, tais como: CPU e Memória RAM. Ele também possui um painel que permite uma visualização do seu data center como se fosse uma única máquina física.
O principal problema que Campbell enfrentou com o Mesos foi a forma que ele lida com suas partições de rede. Se um processo não conseguir se comunicar com a máquina líder do cluster do Mesos, ele é morto. Campbell acredita que essa escolha de design é ruim e, de fato, partições de rede são comuns em sistemas distribuídos, dessa forma as aplicações devem continuar em execução no caso de uma falhar. Ele utilizou o Kafka para demonstrar como esse comportamento pode levar à perda de dados. Embora o Kafka foi desenhado para ser um barramento de mensagens distribuídas, a perda de uma partição pode ser que ocasione a perda de todos os nós, e consequentemente os dados.
Por fim, Campbell não utiliza o Mesos, utilizando o Nomad como alternativa. A vantagem do Nomad é que ele utiliza um protocolo próprio para realizar sua comunicação, permitindo que os servidores se comuniquem dentro do mesmo data center e em data centers diferentes. E no caso de partições, serviços que estão na mesma partição podem funcionar e se comunicar, e caso eventualmente ocorra um problema na partição, os serviços devem ser consistentes e continuar funcionando. Entretanto, como Campbell não conhecia ninguém que estivesse utilizando o Nomad em produção, ele não queria arriscar a migração.
Sua escolha final foi o Kubernetes. Embora ele seja parecido com o Mesos, Campbell encontrou algumas vantagens. Principalmente, a forma como o kubernetes lida com suas partições de rede, visto que, caso alguma pare de funcionar ele não mata o serviço. Kubernetes também possuí um painel que facilita o raciocínio sobre o cluster e com menos níveis de abstrações ao lidar com as aplicações.
A palestra completa está disponível para assistir online, com mais detalhes sobre a arquitetura que Campbell tratou e mais informações sobre os orquestradores.