Microsserviços são para mim? Como começar?

Olá Dev! 

Neste artigo falarei um pouco sobre microsserviços e principalmente com iniciar com esta arquitetura. Espero lhe ajudar a entender se esta é realmente a escolha correta para seu projeto, produto, equipe e stakeholders. 

A arquitetura de microsserviços é, juntamente com arquitetura orientada a eventos, uma das mais faladas e buscadas atualmente quando se trata de alto desempenho, escalabilidade e desacoplamento. Este modelo de desenvolvimento já existe há muito mais tempo do que todos imaginam, mas só nos últimos anos com esta forte nomenclatura de “Microsserviços” tem se tornado Hype. 

Resumindo bem, o estilo de Microsserviços é uma forma de se construir uma solução por meio do uso de vários e vários serviços, todos rodando de forma: 

• Desacoplada 
• Independente 
• Distribuída  
• Escalável  
• Resiliente
• Vários outros adjetivos que enchem os olhos.  

Qual o tamanho de cada um para ser um microsserviço? Esse é um assunto extenso que poderemos abordar em outro artigo. 

Na prática todos os benefícios acima são reais, porém, existe um custo a se pagar e é disso que tratarei aqui. 

Afinal, devo utilizar? O que há de errado com o Monólito? 

Não há nada explicitamente errado com arquiteturas que sejam construídas com um único software, um único código fonte. O que acredito que ocorra muito é que soluções de software legado, em sua grande maioria, são Monólitos, e essa junção sim traz os maiores problemas e maiores dores. Os sintomas quase sempre são: 

• Dificuldade de evolução e manutenção 
• Alto acoplamento 
• Lentidão
• Processos jurássicos e manuais de deploy.  

Juntando esses elementos quase sempre somos levados por nossas experiências e pelo Hype a escrever, ou reescrever, sistemas em arquiteturas mais “modernas” e acabamos por desconsiderar por completo o estilo de arquitetura atual.  

Se você não se encaixa necessariamente nos requisitos para determinada arquitetura, o mais simples e funcional a se fazer é manter a arquitetura monolítica. Em boa parte dos casos apenas o fato de reescrever o software de maneira mais estruturada e planejada, aplicando os patterns e qualidade de código, já irá resolver grande parte dos problemas aqui mencionados.  

Da mesma forma para uma nova solução nem sempre é necessário trazer todo o arcabouço de microsserviços e seu ônus. De forma planejada e caso não exista real necessidade para outra arquitetura, escrever o monólito vai ser uma alternativa clean, objetiva e produtiva. 

E ainda existem casos onde você pode dividir toda a solução em duas ou mais aplicações menores sem que seja necessário entrar em conceitos mais avançados e complexos como microsserviços e orientação a eventos. 

Costumo dar o exemplo de uma aplicação simples que tem apenas um ou dois processos mais pesados, como manipulação de arquivos ou geração de relatórios. Nesse caso é possível que você escreva toda a aplicação como um monólito e apenas extrair para um serviço separado esta parte pesada. Dessa forma você mantem sua aplicação com bom design, simples e efetiva sem trazer os custos de novas e mais sofisticadas arquiteturas. 

Lembrando… 

O fato de se trabalhar com arquitetura monolítica não impede em nada de se utilizar boas práticas de Devops com automação de builds e deploys. Também nada impede de se utilizar dos benefícios de containers, mesmo que seja uma única aplicação. 

Quais critérios devo avaliar ao pensar em Microsserviços? 

Divido os critérios em três categorias: Necessidade, Preparação Técnica e Preparação do ambiente. 

1 – Necessidade 

O Software a ser desenvolvido, seja novo ou reescrito, tem: 

a) Uma alta carga: O que é considerado alto pode variar, então é preciso uma análise mais aprofundada. 

Quando falamos de software legado já temos as métricas do sistema e é possível avaliar se a simples reescrita do código irá resolver os problemas ou se realmente existem gargalos que só poderão ser resolvidos com escalabilidade e distribuição. 

Se otimizarmos aplicações podemos atender milhares de requisições por segundo, colocar processamentos de forma assíncrona, liberar memória, etc. 

Já para uma solução a ser criada é preciso contar com a proximidade do dono do produto e os Stakeholders, principalmente os de alto escalão. Apenas parta para uma arquitetura se a projeção de carga for realmente grande quando comparada com métricas do mercado e lembre-se que sempre há a possibilidade de construir algo mais simples, que seja de fácil adaptação e conforme for o andamento iniciar uma migração para o modelo definitivo. 

b) Alta disponibilidade: Todo usuário de um sistema irá querer o mesmo sempre funcionando. É preciso avaliar primeiro se este é um software crítico e quais as consequências caso ele fique indisponível por alguns minutos ou até algumas horas. Em seguida a possibilidade de queda do serviço VS. o tempo para reiniciar caso ocorra uma falha.  Existem empresas e soluções que podem deixar de faturar milhares de reais em apenas alguns minutos e existem sistemas que podem aguardar um pouco caso o sistema venha a falhar um dia. 

c) Domínios bem separados ou repetidos com a estrutura: Podem existir soluções que são tão grandes e complexas que não irão se adequar muito bem em um único sistema. Nesse caso a quebra dos diferentes e bem declarados domínios para o desenvolvimento de micro serviços pode ser um bom indicador para adotar a arquitetura. Porém, somente este quesito talvez não justifique o “throughput”. 

Vou utilizar um dos produtos da DB1 como exemplo para casos de domínios repetidos com a mesma estrutura. O ANYMARKET é um HUB de integrações de Ecommerce/ERP com os mais diversos marketplaces do mercado. Para este cenário nós temos como exemplo a estrutura de Marketplace que é “repetida”, porém com a particularidade de integração de cada player. Dessa forma a estrutura de microsserviços vem a beneficiar na construção e integração de novas integrações na mesma solução. 

d) Aumento do time: Muitos pensam que microsserviços foram criados para resolver apenas problemas tecnológicos, no entanto isso não é uma verdade absoluta. Microsserviços também tem como objetivo permitir escalar times de forma exponencial, empresas como Netflix, Spotify, Twitter, criam novos times todos os dias. Com microsserviços isso se torna menos custoso e podem antecipar entregas de valor ao cliente. 

2 – Preparação Técnica 

Você que está lendo e avaliando para sua solução a adoção desse estilo de arquitetura tem os conhecimentos técnicos e alguma experiência no desenvolvimento de soluções complexas?  

O seu time, que atuará diretamente na elaboração e codificação da solução, é preparado tecnicamente? O time muito mais que tecnicamente deve ser preparado emocionalmente e de forma bem integrada. É natural a arquitetura que o desenvolvimento seja paralelizado entre várias pessoas ou até equipes e a integração e comunicação é fundamental para o sucesso. Se o time atual tem dificuldades, o desafio será aumentado de forma exponencial. 

Existe espaço para preparação prévia antes e durante o desenvolvimento do projeto? A resposta desta pergunta tem de ser muito bem elaborada e acordada com todos os envolvidos, principalmente a alta gestão, os patrocinadores, pois podem haver situações a serem estudadas e provas de conceito a serem realizadas durante o desenvolvimento do projeto. 

Ferramentas e objetivos a serem atendidos. 

3 –  Preparação para Stakeholders e Ambiente 

O caminho na construção de projetos em microsserviços, principalmente quando estamos iniciando pode ser cheio de desafios e descobertas e isso pode impactar o seu prazo, esforço e custo. Dessa forma, stakeholders precisam estar alinhados e cientes que há fatores adicionais se comparado ao desenvolvido das arquiteturas “tradicionais”.  

Outro ponto importante que pode passar despercebido inicialmente é o ambiente necessário. E quando falo ambiente não só para produção, mas também homologação e desenvolvimento.

Você está desenvolvendo uma aplicação de ponta e acredito que queria buscar as melhores práticas e ter um ambiente de desenvolvimento e homologação o mais próximo possível de produção.

Com isso bem claro é importante pensar em um ambiente mínimo para iniciar e alinhar com gestores e stakeholders essa necessidade para que não haja surpresas.

É muito comum que ocorram choques de realidade e alguma resistência por parte dos envolvidos pois haverá uma grande diferença do tradicional para a aplicação rodando de forma distribuída. 

Conclusão: 

1. Tudo depende de sua avaliação para se enquadrar ou não em um novo modelo de arquitetura, não siga o Hype apenas por seguir. 
2. O monólito ainda vive e pode ser uma ótima opção dependendo do seu contexto. 
3. Esteja muito bem alinhado com seus stakeholders e seja muito transparente em todos os ônus e riscos. Obtenha o compromisso e os envolva no processo. 

Como sequência agora você está se perguntando:  

Estou enquadrado e quero prosseguir, como começar de fato? 

Vou lhe ajudar com isso com os passos iniciais desde estudos a ferramentas e código na prática em uma série nos próximos dois capítulos. 

Esperto que tenha gostado até aqui e lhe convido para acompanhar e me contar como está sendo a sua experiência. 

Enquanto isso, que tal ler sobre um dos maiores desafios ao implantar esta arquitetura? As temidas transações distribuídas: https://codejourney.com.br/microservices-the-ugly-side-transactions/ 

Dentre tantas coisas que formam a Cultura DB1, compartilhar conhecimento é uma das principais! Estamos sempre em busca de novos talentos que se identifiquem com essa ideia. Você é um deles?

Sobre o autor

Fernando Henrique dos Santos Gomes é formado pela UTFPR. Desenvolvedor Java FullStackDevOps e etc há 10 anos. Atualmente é Programador e Líder Técnico na DB1 Global Software. Tem atuado nos últimos dois anos com microsserviços em aplicações corporativas. Empreendedor nas horas vagas, programa de madrugada, gosta de Rock e tudo que é Geek.