Para que o sucesso de qualquer projeto ou serviço se concretize, contamos com grandes especialistas, hoje convidamos André Zarlenga, um de nossos consultores e desenvolvedor aqui na Platform Builders, para falar sobre microsserviços, trabalhando alguns pilares voltados a motivação, conhecimento do time, arquitetura de software e DevOps.

Boa leitura =)

Neste artigo vou abordar um assunto que está em alta há algum tempo, estamos falando do micro serviço. Pretendo listar os motivos pelos quais você não deve utilizá-lo em circunstâncias, nas quais, essa abordagem pode causar mais problemas do que solução. Daí vem a pergunta: você está criando micro serviço ou uma api de puxadinho?

Motivação

A motivação para escrever sobre esse tema, surgiu em cenários de diversas empresas, cujo os argumentos inconsistentes e sem embasamento, justificam o emprego adequado do “uso” de micro serviço, quando na prática, estão repetindo métodos antigos, só que agora, utilizando os principais ‘’termos do momento’’ e uma boa dose de problemas para corrigir.

Eu vejo que o cenário atual está gerando um legado de códigos absurdos. Comparo ao SOAP, que esteve no auge em um passado próximo, mas hoje, os devs o conhecem e não fazem tanta questão de utilizá-lo.

Quando cito legado, estou mencionando práticas questionáveis de desenvolvimento, como falta de testes, duplicação, etc. Antes de mais nada, vejo o micro serviço como uma abordagem fantástica, quando aplicado no cenário onde se faz jus.

Definição de micro serviço

Não existe uma definição exata do que constitui ou não um microsserviço, embora algumas pessoas defendam essa abordagem com unhas e dentes, mesmo tendo codificado de maneira bem razoável, resolvi trazer alguns pontos que devemos levar em consideração, são  eles:         

(Vou listar os mais básicos, visto que o artigo tem como objetivo desmistificar uma melhor entrega)

  •   Manter um código coeso
  •   Ter um propósito bem definido para o micro serviço
  •   Ser possível levar aplicação de forma simples para diversos ambientes
  •   Dimensionamento escalável
  •   Manter o armazenamento distribuído

Porque não adotar

Vamos descrever alguns pontos pelos quais você deveria pensar se deve ou não adotar micro serviço no projeto.

 Você não tem domains experts para aplicar DDD

Acredito que quando você não consegue ter disponibilidade de pessoas que realmente entendam do negócio, como será possível definir o limite de fronteiras (estou me referindo ao conhecido Context Bounds)?

Como é possível saber de forma bem definida o ciclo de vida em um contexto de negócio? Automaticamente, nós não temos mais plena convicção de como desmembrar em micros serviços; e nesse caso, qual será o critério de separação dos endpoints?

Infelizmente, vejo o critério “CRUD” sendo usado para saber como separar os micro serviços. No fim das contas qual a diferença entre abordar desta maneira ou como se fazia no passado?

Talvez este traga mais problemas, inclusive com a duplicação de código, digo isto, porque outro detalhe que tenho percebido é que o micro serviço “À la CRUD” é sinônimo de entregar o projeto  de qualquer maneira, desde de que funcione. 

Nesta linha de raciocínio, acredito que estávamos melhor servidos com monólitos, onde os times tinham o costume de alinharem-se com a arquitetura do software. A falta de um cenário complexo a ponto do DDD ser viável, trouxe pensamentos que os micro serviços também andam na mesma linha.

Conhecimento do time

Um ponto a ser avaliado são se os times de arquitetos e desenvolvedores estão aptos para essa jornada. Aqui vão algumas qualidades imprescindíveis, as quais, não podem faltar na equipe:

POO

Programação Orientada à Objeto

Pode parecer banal dizer isso na atualidade, mas vemos uma dificuldade muito grande no entendimento de POO ainda. As regras devem estar bem claras para o time todo, isso é imprescindível.

Eu insisto em dizer que o POO veio para nos aproximar do mundo real e também do código, fazendo uma tradução    mais semântica do negócio, do contrário, qual seria a necessidade de adicionar uma camada a mais de regras, gerando um processamento desnecessário? Bastaria enfocar em código somente (como no passado). 

A frase que eu costumava ouvir no passado é: “Se você souber lógica de programação, você programa em    qualquer coisa”, ela ainda é verdade, mas com um relevância reduzida, visto que isso é um requisito, mas agora não está mais isolado. Para ser um dev, você tem que ter uma know how maior na atualidade. Um dev que apenas sabe lógica, tem cada vez menos espaço no mercado.

Quando nos aproximamos do negócio, fazendo uma tradução, mantendo a semântica dele especialmente no código, estamos mais próximos de entregar valor do que apenas um deploy. 

SOLID

Este é um acrônimo criado por Michael Feathers, é extremamente necessário para que tudo que escrevi sobre POO faça sentido, o SOLID reforça a semântica do negócio. Se o time não tem isso bem definido, fica muito difícil trabalhar.

Design Pattern

Este também é fundamental, visto que temos inúmeros problemas “resolvidos”. Mesmo fora do contexto de micro serviço, este deve ser levado em consideração.

Eu gosto de fazer uma analogia sobre Designer Pattern, com serviços elétricos. Imagine você contratar um eletricista, onde ele resolve fazer a fiação de sua residência de maneira mais rápida, sem se preocupar com problemas previsíveis, onde estou falando de um serviço que você não vê como foi feito, apenas avalia seu resultado final: funciona ou não?

 Pode funcionar de momento, mas quando precisamos de manutenção deste, percebemos o quanto podíamos ter levado um pouco mais a sério o trabalho.

Quantas vezes nos deparamos com um software, onde nos perguntamos porque o dev desenvolveu desta maneira? Pois tornou-se mais difícil de entender o fluxo, gerando uma ansiedade para criação de manutenção neste código. Nesse aspecto, mandar o projeto para produção é se arriscar como em uma roleta russa, podendo gerar graves efeitos colaterais, não previstos.

Devops

A abordagem de manter micro serviços sem ao menos ter alguém para administrar a esteira de entrega, torna-se um entrave. Imagine uma situação na qual vemos aplicações subindo de forma antiga, podendo ter diversos problemas, desde dessincronização de versão dos micro serviços até falta de disponibilidade.

Esta abordagem também impacta não somente no ambiente de produção, mas também no de desenvolvimento. É importante ter um ambiente mais estável, no qual, o dev novo ou aquele que trocou de máquina, clone ou projeto, consiga subir todas suas dependências de forma  simples.

Recordo-me que há muitos anos, eu perdia semanas criando um ambiente para o projeto. Onde a falta de aparato era o principal bloqueio na rede do servidor de banco; a falta de infra estrutura adequada, licença para trabalhar nos ambiente também era um empecilho. 

Este problema foi minimizado atualmente, através de um docker compose configurado que facilita em muito o tempo de configuração de nosso ambiente de desenvolvimento, ou seja, é necessário ter alguém com essas competências no time.

Arquitetura de software

É necessário saber qual arquitetura de software utilizar em um em micro serviço. O que tenho visto muito é a arquitetura: Nenhuma.

Infelizmente, vejo que um micro serviço vira um puxadinho quando se pensa na entrega do endpoint, sem ao menos tentar manter a qualidade de software. 

Vejo que o micro serviço virou pretexto para entrega desqualificada, afinal de contas, ele é pequeno e a gambiarra é pontual. Quando percebemos, temos um abundância de micro serviços com essa abordagem. Claro que não existe uma receita exata, mas temos algumas disponíveis: Hexagonal, Onion, CQRS, etc. Devemos escolher a qual melhor nos adapta ao projeto, mas como saber?

O arquiteto de software deve deve saber disso. Outro detalhe importante é o modo como os arquitetos são concebidos, ser um dev sênior não é referência para isso, contudo deixaremos essa abordagem para outro artigo.

Ter conhecimento real sobre armazenamento

Algo que tem sido muito menosprezado na atualidade. Vejo que o NOSQL virou bala de prata, quando não deveria. Os devs criaram o péssimo costume de não pensar em modelagem de dados, apenas armazenar. Acredito que isso venha um pouco do ORM, mas nele temos uma abstração de modelagem, onde isso não é um problema.

Estou querendo dizer que o uso de NOSQL é ruim?

Muito pelo contrário. Contudo temos que saber onde deve ser utilizado e a  partir do momento que usamos NOSQL no projeto algo deve ficar bem claro: Abdicamos da consistência de dados, pois temos uma consistência parcial. Este é conhecido como teorema de CAP (tema para outro post também). 

Temos que avaliar onde podemos utilizar e como devemos utilizar um banco de dados relacional. Muitas soluções têm ido para o modelo heterogêneo, onde usamos NOSQL sem um requisito de consistência em tempo real. Vamos para um exemplo.

Imagine um cenário no qual precisamos vender ações para operações de trade. Isso deve estar disponível em um ambiente multiusuário. Já é possível identificar que não podemos de jeito nenhum disponibilizar um preço errado para o trader. Justificar que algumas frações de ações foram vendidas com preço errado, não será desculpa, ou seja, você precisará do ACID neste caso.

Trabalhei e trabalho em projetos que tem 5 fontes de armazenamento, seja para relacional, cache, logs, ETL e mensageria.

Existe uma abordagem para “resolver” este cenário sem uso de banco relacional. Que é trabalhar com SAGA, porém este deve se visto com muito cuidado, tendo em vista que na maioria dos casos muitos devs colocam um API Gateway  e criam um ponto de gargalo, voltando para o mesmo problema que o fez sair do banco relacional: falta de escalabilidade, já que o mesmo não tem uma proposta de escalabilidade igual a um banco NOSQL, que permita manter clusters.

Mensageria

Saiba que os eventos irão ocorrer de forma assíncrona e que estão suscetíveis a falhas, aos quais você não tem controle, como por exemplo. Um simples envio de e-mail. Você depende de um servidor SMTP, onde este pode recusar novas mensagens por motivos que o consumidor não consegue tratar ou resolver no momento. Então você deve perder um fluxo de cadastro, porque o servidor SMTP falhou na comunicação?

Uma forma de resolver isso é trabalhar com serviços de mensageira, para se ter resiliência nas comunicações. E este é mais um ponto que os Devs têm como requisito para se trabalhar com micro serviço.

Conclusão 

O cliente final quer solução e não mais problemas; chega o momento que não tem como justificar GAPs técnicos. O cliente não aceita falhas, todavia existe uma propensão muito grande para tal, afinal ele está cansado de injetar capital com o micro serviço e não ter uma solução definitiva. Logo, eles resolvem retroceder, ou seja, não podemos desperdiçar a oportunidade de se trabalhar com essa ferramenta, que é tão poderosa, temos que manter a qualidade para apresentar bons resultados.

Quer dizer que o único caminho é o micro serviço?

A resposta é taxativa: Não, temos aplicações legadas de bancos (em Cobol) que rodam e trazem funcionalidade para seu negócio, por exemplo.

O micro serviço é uma solução muito robusta, mas tem que vir acompanhado de uma equipe que saiba o que está fazendo.

SOAP (Simple Object Access Protocol) – O SOAP é uma especificação para requisitar métodos de negócio, como documentos XML, e suporta outros protocolos como HTTP e SMTP

DDD (Domain Driven Design) – O Domain Driven Design é a reunião de um conjunto de princípios e práticas.

CRUD (Create, Read, Update e Delete) – Termo utilizado para definir as operações basicas de um sistema.

POO (Programação Orientada à Objeto) – Paradigma de programação baseado no conceito de “objetos”, que podem conter dados na forma de campos, também conhecidos como atributos,e comportamentos.

Design Patterns – Design Patterns ou são soluções generalistas para problemas recorrentes durante o desenvolvimento de um software

NOSQL – Os bancos de dados NoSQL são amplamente reconhecidos por sua facilidade de desenvolvimento, funcionalidade e performance em escala

ACID (Atomicidade, Consistência, Isolamento e Durabilidade) – Se refere às quatro propriedades de transação de um sistema gerenciado de banco de dados.

SMTP – SMTP é a sigla para Simple Mail Transfer Protocol, que pode ser traduzido como protocolo simples de transferência de correio

Curtiu o conteúdo? A Platform Builders pode te ajudar na idealização desse e outros!