26 de julho de 2018

 

Microsserviço é um dos temas mais polêmicos e que mais tenho falado recentemente, que sempre gera muitas e muitas discussões. Mas será que realmente você precisa de microsserviço (sim, em PT-BR é com dois S).

Um pouco de história

Diferentemente do que a maioria pensa, esse modelo de arquitetura não é tão recente. Desde a década de 70 já se construíam aplicações distribuídas, onde um computador enviava comandos para serem executados em outro computador. E pasmem! Nem o SOA foi inventado nos anos 90, como parece. Estamos trabalhando com serviços distribuídos à aproximadamente 5 décadas! CINCO décadas.

Afinal, o que são microsserviços?

Em resumo, quando falamos em microsserviços, nos referimos à um modelo arquitetural de aplicações distribuídas (não confunda com SOA, ok?), onde cada uma tem uma responsabilidade exclusiva, em um escopo bem delimitado de atuação, uma base de dados própria, um ciclo de vida próprio, uma equipe de desenvolvimento própria e em geral, são aplicações expostas por HTTP (mas não restritas à).

Para começar a explicar mais detalhadamente o que são microsserviços, precisamos entender:

Aplicações monolíticas

Geralmente são aplicações com inúmeras responsabilidades como por exemplo: exibir produtos, emitir nota, enviar email, autenticar o usuário, produzir log, etc.

Também podemos qualificar um monolito como aplicações tradicionais em 3 camadas, que compartilha sua base de dados com outras aplicações/serviços, que exerce inúmeras responsabilidades.

O monolito é o caminho natural da construção das aplicações. Em geral, abrimos a IDE e começamos a montar o projeto/MVP e ele vai crescendo, ganhando novas funcionalidades, novas responsabilidades, e vai se tornando uma aplicação “faz-tudo”.

Essas aplicações em geral são bem complexas de serem atualizadas, pois paralizam processos que estão rodando, precisam de interrupção em sua completa execução e quase sempre, deixam o serviço indisponível, obrigando as empresas a terem processos de controle de atualização em janelas – a famosa GMUD. Dentre outras, essa é uma das razões que mais levam times a terem baixo desempenho de entrega.

Aplicações distribuídas

Quando as empresas começam a ter problemas de carga, escalabilidade, manutenção no código de linhas infinitas, geralmente começam a distribuir partes da aplicação seguindo o modelo SOA de componentização por serviços. Geralmente nascem os serviços de log, carrinho, etc. E a estratégia de separação em serviços costuma decidir por componentizar partes da aplicação, pela complexidade de manutenção, depois pela criticidade de atualização, depois pela necessidade de escalabilidade e outros fatores.

Mas distribuir seu monolito em serviços distribuídos, não faz deles microsserviços!

Pensando micro, pensando em produto

Antes de qualquer coisa, convido o leitor a repensar a forma como se pensa em software. Não é possível falarmos de microsserviço como projeto. Esqueçam projeto! Vamos mudar o mindset! Pensar em microsserviço exige estruturar aplicações como produtos.

A partir de agora, se você for falar de microsserviço, ele é um produto que atende à empresa e a qualquer outra aplicação, não somente a sua. Afinal, um microsserviço é exatamente isso, uma aplicação que indifere seus clientes e não compartilha sua base!

Alguns exemplos de aplicações que são microsserviços e você possivelmente já usou:

• Active Directory – Responsável única e exclusivamente pela autenticação e autorização de usuários e suas regras. Qualquer aplicação pode usá-lo, sem acessar sua base, que é exclusiva.

• Google Maps – Possui uma série de microsserviços expostos por API’s distintas – Rotas, mapas, lugares. Cada um, responsável por um conjunto delimitado de recursos. Qualquer aplicação pode consumir, mas sua base é exclusiva e ninguém tem acesso.

Enfim, poderia passar a eternidade aqui listando outros exemplos, mas creio que esses são suficientes para explicar a necessidade de pensar em produtos, não mais em projetos.

Como desconstruir um monolito?

Existem inúmeros fatores decisórios sobre como abordar a decomposição do monolito, desde a necessidade de escalabilidade de um conjunto de funcionalidades, até a necessidade de refactoring, passando pela necessidade de segregação de base de dados.É quase uma ciência própria, sem exageros. A discussão é tão, tão, tão extensa, que há um livro com inúmeras orientações sobre o tema:

A arte da escalabilidade

Pensar em microsserviço não é simples como o momento hype faz parecer! Viu?

 Alguns pré-requisitos

Antes de continuar, gostaria de perguntar: hoje, você já tem um processo maduro de DevOps rodando na sua organização? O código do seu time é compilado automaticamente no servidor de build, testado, qualificado e publicado em ambiente de desenvolvimento?

 

Se a sua resposta foi não, sugiro parar a leitura aqui e implementar DevOps urgentemente na sua organização. Sem essa cultura madura e funcionando perfeitamente, pensar em microsserviços é quase como pensar em andar de avião sentado nas asas. Poucos conseguem, não é confortável, causa problemas de saúde e na maioria dos casos, é suicídio.

Complexidades envolvidas

São inúmeras as complexidades envolvidas no planejamento de uma arquitetura distribuída, principalmente no que tange à transações de longa duração, segregação de dados, orquestração dos serviços.

Listei abaixo, uma série de questionamentos que exemplificam a complexidade de se pensar na construção de microsserviços:

• Como lidar com operações que são de longa duração, processadas em diversos microsserviços diferentes, em inúmeras bases de dados diferentes e ainda assim, garantir integridade?

• Se os microsserviços possuem cada um a sua própria base de dados, como manter a integridade referencial? Como manter os relacionamentos?

• Se o processamento das atividades ocorrerá em inúmeros microsserviços de maneira distribuída, como informar ao usuário que o processamento ocorreu com sucesso ou falha?

• O que acontece quando um microsserviço está fora do ar? Todos os demais também ficarão? Se não, como se dará uma transação quando um microsserviço do ecossistema estiver indisponível?

• Quando um microsserviço for publicado, quais outros deverão ser atualizados? Ou não deveria haver essa dependência?

• Sendo as bases de dados distribuídas, como manter os dados atualizados entre todas elas?

• Posso ter uma base de dados para cada microsserviço, no mesmo servidor e dados?

• Como faria para publicar 20 microsserviços?

Essas são algumas das perguntas que frequentemente me fazem quando começam a ler sobre esse modelo arquitetural e que sem dúvidas, você já deve ter feito.

Conclusão

Arquitetura de microsserviços é muito mais complexa do que se parece. E muito além de engenharia de software, eu acredito que há uma severa necessidade de mudança cultural de toda a equipe. Precisamos amadurecer na equipe a gestão horizontal do produto, para que todos os envolvidos (PO, SM, Devs, QAs, DevOps, etc), estejam a par de todas as necessidades, do planejamento e principalmente, da stack técnica e de evolução.

Construir microsserviços com mindset de produto, com um time não sênior, em um ambiente sem DevOps, e sem maturidade para orquestração e coreografia deles, é distribuir seu problemão monolítico, em probleminhas micro e exponenciais.

Meu conselho para quem estiver pensando em se aventurar com esse modelo arquitetural é: estudem, capacitem-se, entendam muito de rest, mensageria, CQRS, event sourcing, log as event, instrumentação, SOLID, clean code e ainda algumas outras competências.

Se precisarem de ajuda, se quiserem tirar dúvidas, me procurem. =)

Abraços, Lucas Massena

Para acessar o post original, basta clicar nesse link: https://www.linkedin.com/pulse/microsservi%C3%A7os-voc%C3%AA-precisa-mesmo-lucas-massena/