A maioria das empresas está mirando chegar no topo do nirvana arquitetural utilizando-se de tecnologias de ponta. Infelizmente, o que observo são movimentos desesperados de executar o que se lê em artigos de fonte, no mínimo, duvidosa. Isso quando a intenção não é simplesmente um desejo irresponsável de um grupo de desenvolvedores de mostrar (no LinkedIn? para amigos? para uma talk na conferência da esquina?) que consegue.

Vamos imaginar que você tenha autonomia para adotar uma arquitetura de micro serviços em sua empresa. Antes de quebrar seu monolito em várias partes, na esperança de que magicamente isso transforme seu sistema atual em uma arquitetura de micro serviços, existe um conjunto de questionamentos que devem ser feitos.

Tem apoio organizacional?

Após várias pesquisas você viu os benefícios que a Netflix, Spotify, entre outras empresas tiveram ao adotar o modelo arquitetural e agora tem certeza de que se funciona com eles, então obviamente funciona para você, certo?

ERRADO!

Cada caso é um caso.

Como sua empresa lida com uma falha ou um bug? Ela procura por culpados quando algo da errado em produção ou tenta aprender com as falhas?

Lembre-se de que a barreira cultural é a maior barreira a ser quebrada.

Um dos grandes alvos da adoção de micro serviços é a independência no deploy. Então, se a cultura é ter janelas de deploy para produção, vocês já tem um grande trabalho cultural pela frente.

Fazer um sistema distribuído não é fazer um blog com Rails. Existe uma grande quantidade de técnicas e tecnologias novas para além da famigerada arquitetura de 3 camadas que devem ser dominadas para a adoção da arquitetura de micro serviços.

Meu time tem os skills necessários?

Fundamental: colaboração, comunicação e conhecimento do negócio.

Refatorar base de dados. Mensagens distribuídas. Teoria de filas. API Gateway. Protocolos de comunicação além do HTTP. Domain Driven Design. Teorema CAP. Profiling de aplicações. Service discovery SQL vs NoSQL. A importância dos logs em um modelo distribuído. Correlation ID. DevOps. Testes baseados em contrato. IaC. Linux containers. Swagger. Continuous Delivery. Stateful vs. Stateless. Graceful shutdowns.

Se o seu time não entende no mínimo 80% do termos descritos, me parece que tem um GRANDE trabalho de estudo antes de se meter em apuros.

Seu time já sabe fazer um monolito?

Se seu time ainda não sabe fazer um excelente monolito, o que te faz pensar que vocês conseguirão fazer a mesma coisa, dessa vez, de forma distribuída?

Você já consegue olhar para o seu sistema monolítico e identificar as diversas áreas de negócio?

O core business está coberto por testes descritivos o suficiente que sirvam de documentação? Estão cobertos também os casos conhecidos de exceção?

O quão fácil é remover uma funcionalidade sem quebrar o sistema?

Que problemas serão resolvidos com essa arquitetura e que novos problemas serão assumidos?

O que pode ser feito com essa arquitetura que não seria possível com a monolítica?

O time já sabe a vazão do sistema atual para justificar a possível alta disponibilidade no modelo distribuído?

Em troca da disponibilidade alta seu time já sabe lidar com transações distribuídas?

Quando existe uma mudança, é fácil observar que sistemas ou clientes são afetados?

Como eu garanto que o serviço que depende do sistema atual (que o time não tem domínio de como foi implementado) vai continuar funcionando após uma mudança?

Ainda é preciso fazer um acesso via SSH para ver logs da aplicação?

Conclusão

Sejam quais forem as respostas, tenha em mente que o seu time tem que conseguir ser mais eficiente na velocidade de entrega e nos custos mantendo o sistema altamente disponível.

Nos próximos textos pretendo atacar essas perguntas e dissecar os temas para uma visão clara de como lidar com os desafios.

Tem algum ponto que gostaria de discutir? Comente ou mande uma mensagem no twitter: @alextrending.