fbpx
Diário de Bordo – Poltys – #2
Publicado em: domingo, 26 de maio de 2019

Esse é um post complementar que endereça algumas dúvidas da galera que viu esse post e me chamaram para tirar suas dúvidas.

Desde já vou chamar esse Controller/Scheduler/Manager de CSM, isso porque até então todos esses nomes são compatíveis com seus comportamentos (scheduler talvez não). Mas ficará como CSM até poder batizá-lo de forma decente.

Um dos mantras que ajuda no design que gosto de usar é:

Dessa forma, quando estava escrevendo sobre a possibilidade de ter um CSM orquestrando a criação de Workers com Docker standalone, Clusters Swarm ou Kubernetes, pensei:

E seu eu abstraísse a forma como crio Containers?

E seu eu abstraísse a forma como o CSM cria os Workers (que são containers)?

Bastaria definir uma interface, bem consistente e pronto, teria um ponto de indireção e abstração.

E seguindo esse mantra, começaria com a implementação mais básica (Docker) e construiria as demais na medida que fosse necessário.

A diferença entre esse desenho e um desenho que BDUFasse menos, é que em vez de fazer algo mais acoplado, eu desacoplo para ter extensibilidade. Como trabalho muito bem com Injeção de Dependência e Inversão de Controle, principalmente pelo apoio do Oragon.Spring, tudo fica mais fácil. Lidar com configurações específicas para cada caso é trivial, o que precisa ser pré-desenhado é o fluxo e a iteração entre a abstração e seus consumidores.

Pronto, mais um insight para o projeto. Não só eleva sua capacidade de lidar com diversas estratégias de deploy, como possui um pequeno custo.

Isso só é possível pois no desenho eu defini que precisava de um CSM, e na medida que passa esse elemento vai se confirmando como fundamental no desenho de arquitetura. Claro que o primeiro pensamento surge da necessidade de ter uma aplicação central, que é a API de gestão, mas principalmente da impossibilidade de gerenciar hosts remotos, então como a API precisa estar disponível e pública, é muito mais eficiente fazer com que o CSM se registre como um CSM do que a API criando workers dinamicamente, em um cluster remoto.

Então vou ficando por aqui! Até a próxima novidade

0 comentários

Enviar um comentário

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *

Esse site utiliza o Akismet para reduzir spam. Aprenda como seus dados de comentários são processados.

Lives

Fique de olho nas lives

Fique de olho nas lives no meu canal do Youtube, no Canal .NET e nos Grupos do Facebook e Instagram.

Aceleradores

Existem diversas formas de viabilizar o suporte ao teu projeto. Seja com os treinamentos, consultoria, mentorias em grupo.

Share This