ARDA foi nosso projeto interno de 2016. Gastei inúmeras horas discutindo a arquitetura e as tecnologias envolvidas, mas o aprendizado aconteceu somente quando mergulhei na codificação.
O código-fonte está aqui: https://github.com/dxbrazIl/arda
Antes de começar a analisar o código, é importante dar um pouco mais de contexto. Afinal, eu nem disse para que serve o Arda!
Objetivo
ARDA é uma ferramenta de gestão do time técnico com o objetivo de acompanhar a distribuição de tarefas entre os colaboradores.
Simplificando o produto, queríamos algo semelhante ao Trello e ao VSTS – começamos com a ideia de um Kanban. Era importante criar um Dashboard (Reports) com todas as métricas do nosso ano fiscal, então adicionamos as classificações de Categoria, Complexidade da tarefa, Métricas do scorecard e Fiscal Year. Por fim, queríamos ter segurança, então adicionamos o conceito de usuários e permissões.
Você deve pensar que é bem provável que essa ferramenta já exista no mercado ou que a própria Microsoft tenha uma também. Entretanto, nós somos técnicos. Nosso verdadeiro objetivo era aprender a fazer uma arquitetura baseada em Microservices e, portanto, seguimos em frente com nosso projeto.
Arquitetura baseada em Microserviços
Imagino que muitos projetos nascem exatamente da forma como fizemos:
- Existe uma necessidade de negócio: gestão de tarefa em um time técnico
- Há um viés por uma tecnologia: usar microserviços custe o que custar
Foi exatatamente isso que aconteceu no nosso time, resultando em diferentes visões de implementação.
Segundo algumas definições, microserviços são pequenos (micro) e autônomos. Por outro lado, a manutenção de serviços independentes gera complexidade desnecessária – veja o exemplo de tornar “Fiscal Year” como microserviço. Por que? Assim, seguiu nossa discussão:
- Fabricio Catae (eu) queria uma arquiteutra composta por 1 microserviço (Arda Core!!!)
- Fabricio Sanchez queria uma arquitetura composta por 10 microserviços (reports, kanban, workloads, backlogs, …)
Chamo isso de Problema do Fabricio^2. O tempo passa e nenhuma conclusão é feita para começar o projeto. Nem lembro o que as outras pessoas opinaram porque estava obcecado em MINHA arquitetura com 1 microserviço. Tenho certeza que o Sanchez estava concentrado somente em defender a ideia DELE. Enfim, a discussão era infinita e sem objetivo.
Solução do Problema do Fabricio^2
A solução para o impasse é fácil – basta adotar a estratégia de FAIL FAST: “Falhe. Mas falhe logo”.
No nosso caso, calculamos a média aritmética e chegamos a conclusão (muito empírico não?) de que precisávamos de 5~6 microserviços para resolver nosso problema. Fim de discussão sobre quem estava certo ou errado.
Logo que criamos os projetos no Visual Studio, começamos a nos dar conta de que seriam muitos e retiramos alguns deles. A discussão se tornou técnica.
No final, nossa arquitetura ficou da seguinte forma:
Isso significa que chegamos a um consenso e adotamos 4 microserviços. Isso resolveu o problema do Fabricio^2.
Conclusão
Cuidado com as discussões infinitas. Já cansei de ver Arquitetos de Solução defendendo a arquitetura ideal da aplicação com todo o racional baseado no Visio ou Powerpoint, mas sem sequer colocar a mão na massa e mostrar algo concreto. Infelizmente não acredito em nada disso. Uma boa arquitetura requer planejamento e parte desse plano precisa de uma prova de conceito.
Repetindo a frase com que comecei: gastei inúmeras horas discutindo a arquitetura e as tecnologias envolvidas, mas o aprendizado aconteceu somente quando mergulhei na codificação.
Logo, "menos PPT, mais código".
Referência
Vale a pena visitar os artigos do Fabricio Sanchez, que explica o projeto Arda e as considerações iniciais em detalhe. Essa é a versão bonita da nossa história de arquitetura:
http://fabriciosanchez.azurewebsites.net/3/arda-primeiros-passos-com-microservicos/
Recomendo que você faça uma leitura rápida para se familiarizar sobre o projeto. Nos próximos posts começaremos a detalhar o código e o banco de dados.