Diário de Bordo – Poltys – #2

Diário de Bordo – Poltys – #2

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

O breakeven dos projetos Docker – Sem docker é mais caro

O breakeven dos projetos Docker – Sem docker é mais caro

Docker já faz parte de muitos projetos que tenho assistido e participado, e está cada vez mais no dia-a-dia de mais gente. Uma vez superada a curva de aprendizado, você rapidamente se vê com super poderes, compondo suas aplicações com os mais variados serviços, e eliminando assim a necessidade de construção e setup extenso de diversos desses serviços. Esse empoderamento lhe permite fazer muito mais, de forma muito mais profissional com menor custo1.Então vemos um fenômeno curioso, o breakeven dos projetos Docker, onde meus orçamentos saem mais caros quando não uso docker, do que usando docker. É sobre isso que vou abordar hoje.

(mais…)

Docker Compose: simplificando o deployment de aplicações

Docker Compose: simplificando o deployment de aplicações

Docker Compose é um serviço do próprio Docker voltado à criação e execução conjunta dos múltiplos containers de uma aplicação. Tal capacidade contribui para facilitar o deployment de um projeto em diferentes ambientes.

Além disso, o Docker Compose é considerado uma alternativa extremamente útil em cenários que envolvam a implementação de uma arquitetura de microsserviços.

Esta tecnologia foi abordada em detalhes num evento online recente do Canal .NET: