BT

Início Artigos Microservices é o novo Santo Graal da escalabilidade

Microservices é o novo Santo Graal da escalabilidade

Favoritos

O Santo Graal é um tesouro que serve como um motivo importante na literatura Arturiana, além de grandes filmes como Indiana Jones. Em algumas versões da lenda, um cálice sagrado é responsável por curar todas as doenças e problemas. O Santo Graal também se tornou sinônimo de um objeto ou relíquia sagrada por algumas áreas ou a solução de todos problemas. Na área de TI também temos esse Santo Graal que busca por desempenho e escalabilidade de uma aplicação com uma única solução da qual chamamos de bala de prata. Essa bala de prata vem mudando técnicas por gerações e a atual são os microservices. Será que finalmente encontramos o Santo Graal de TI com os microservices? Nesse artigo falaremos um pouco sobre o grande problema do Santo Graal com os microservices.

O sonho do desempenho e escalabilidade sempre foi um desejo forte entre os arquitetos de computação. E muitos deles começam a usar microservices pelo argumento do desempenho. E como sabemos em computação desde 1960:

Uma otimização prematura é raiz de todo o mal.

As gerações de Santo Graal (No clue generation)

Obviamente, não tenho décadas de práticas, porém, nesse período pude ver algumas gerações do Santo Graal ou simplesmente tenho problema de desempenho e eis que sai a típica solução "no clue" como bala de prata. O que chamo de "no clue", basicamente, se baseia na solução que sai da manga de um arquiteto como a solução para todos os problemas possíveis. Ao longo da minha caminhada, pude perceber essas soluções de Santo Graal mudarem com o tempo, porém, o seu conceito base não, uma solução rápida, sem muita análise da arquitetura atual:

  • Aumentar a memória da JVM: o problema da aplicação certamente se consiste em aumentar a memória da aplicação;
  • Colocar cache para o banco de dados: o problema está no banco de dados, logo precisamos colocar um cache;
  • Mudar o banco relacional para NoSQL: o banco de dados precisa ser escalável, logo colocarei uma solução com NoSQL como Cassandra;
  • Mudar para microservices: preciso criar escalabilidade da aplicação, logo preciso e dividir a aplicação.

Os problemas dos microservices

Existem diversos problemas que as palestras ou workshops não falam, a arquitetura de software do mundo real:

  • Complexidade de hardware: uma vez que a nova arquitetura lidará com novas máquinas é importante salientar que além da criação é importante manter esses serviços, ou seja, os bancos de dados precisam de mais operações de backup;
  • Segurança: segurança é importante e garantir o acesso entre as máquinas é trivial. Por exemplo, é importante garantir que os servidores do setor financeiros acessem os bancos de dados do setor financeiros e que as outras máquinas não o acessem;
  • Toda aplicação precisa de testes e com microservices não diminuirá, pelo contrário, esses testes precisam aumentar uma vez que é necessário testar integração, sem falar, que precisa verificar quando tais serviços não estejam disponíveis, Circuit Break;
  • Uma aplicação com dificuldade de log se tornará ainda mais difícil com microservices, é importante ter ainda mais infraestrutura e máquinas para centralizar os logs e ter um open trace id para seguir o log entre os serviços disponíveis na aplicação.

Os erros mais comuns com microservices

É muito comum existir a lista mais comuns dos erros que todo software tem, principalmente, quando existe uma mudança de paradigma. Por exemplo, quando houve a migração para os bancos de dados NoSQL, certamente, o erro foi pensar em relacionamento em bancos de dados que não tem suporte a relacionamento como Cassandra. A lista a seguir apresenta os erros mais comuns que encontramos nos microservices:

  • Quebra de domínio: o DDD trouxe vários benefícios, principalmente, trazer o código para próximo do negócio com a linguagem ubíqua. Dentro do DDD temos o conceito de domínios e quando movemos para microservices é muito normal quebrar de maneira errada o negócio no domínio. Falando no desempenho, a maneira mais eficiente para comunicar entre domínios é a memória ou não reinventar a roda, por exemplo, ao invés de orquestrar serviços, podemos simplesmente fazer um join e buscar as informações necessárias;
  • Não automatizar: uma das boas práticas existentes quando falamos de microservices, certamente, é o CI/CD. Essas técnicas são realmente importantes, principalmente, uma vez que existe uma grande quantidade de máquinas a serem gerenciadas;
  • Diversidade de linguagens: essa decisão certamente é a mais intrigante para mim. Até o momento não conheço um único projeto cujo o objetivo é exibir alguma coisa no console, porém, é muito comum ouvir a decisão de um programador baseado no número de linhas dentro de um "Hello World". É importante ter muito cuidado com esse tipo de decisão;
  • Sua aplicação não é grande suficiente para se tornar microservice: nem toda aplicação grande precisará ser um microservice e é muito importante admitir isso;
  • Um dos grandes argumentos para escolher microservices está na possibilidade de escolher escalar um componente individualmente. Porém, eis que surge a seguinte pergunta: realmente faz sentido escalar individualmente um componente?;
  • Microservices precisam de informações e como todo banco de dados distribuídos eles enfrentam a teoria do CAP. Realizando diversas atualizações em cada serviço é necessário adicionar uma nova camada e complexidade na aplicação, como o padrão SAGA, e essa camada dada a sua complexidade, geralmente, causa ainda mais impacto na consistência nos dados de todos os serviços envolvidos;
  • Começar o projeto já como microservices tende a ser um grande erro, principalmente, na instabilidade na definição dos domínios um erro na quebra faz com que exista uma grande dependência e acoplamento entre serviços de modo que muitas orquestrações como boa prática seriam joins para relacional ou subdocumentos pensando num armazenamento de bancos NoSQL, como o MongoDB.

Um outro ponto muito importante, utilizar microservices apenas porque grandes empresas utilizam esse tipo de arquitetura. No mundo de arquitetura de software, uma decisão não deve ser tomada apenas pela popularidade na solução. Como o Edson Yanaga fala em seu livro: "Certamente, sempre lemos grandes coisas sobre as arquiteturas de microservices implementadas por empresas como Netflix ou Amazon. Então, deixe-me fazer uma pergunta: quantas empresas no mundo podem ser Netflix e Amazon?".

Microservices como toda decisão de arquitetura sem suas vantagens e desvantagens como Martin Fowler fala:

"Os microservices introduzem eventuais problemas de consistência, por causa de sua louvável insistência no gerenciamento de dados descentralizado. Com um monólito, podemos atualizar várias coisas juntas em uma única transação. Os microservices exigem vários recursos para atualizar, e as transações distribuídas são desaprovadas (por um bom motivo). Portanto, agora, os desenvolvedores precisam estar cientes dos problemas de consistência e descobrir como detectar quando as coisas estão fora de sincronia antes de fazer qualquer coisa que o código se arrependa." - Martin Fowler

A busca do Santo Graal na computação ainda é um dos maiores mitos dentro do mundo da computação. Os microservices como qualquer decisão arquitetural tem benefícios e desvantagens como qualquer outra solução. Os microservices não foram a primeira e não será a última bala de prata de desempenho da qual chamo carinhosamente de "no clue generation". Como engenheiros e arquitetos devemos analisar carinhosamente tais decisões. Vale lembrar que apesar da grande glamourização dos microservices nas palestras, artigos e alguns livros, muitas vezes suas explicações se restringem a criação e não na manutenção e trade-offs. Uma vez que a criação, no geral, é a parte mais fácil de um software. É sempre muito importante na escolha de arquitetura verificar as vantagens e desvantagens de uma solução e tenha muito medo quando apenas te falam das vantagens, afinal, é mais um conteúdo em busca do santo Graal.

Sobre o autor

Otávio Santana é engenheiro de software, com grande experiência em desenvolvimento open source, com diversas contribuições ao JBoss Weld, Hibernate, Apache Commons e outros projetos. Focado em desenvolvimento poliglota e aplicações de alto desempenho. Otávio trabalhou em grandes projetos nas áreas de finanças, governo, mídias sociais e e-commerce. Membro do comitê executivo do JCP e de vários Expert Groups de JSRs, é também Java Champion e recebeu os prêmios JCP Outstanding Award e Duke's Choice Award.

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

BT

Seu cadastro no InfoQ está atualizado? Poderia rever suas informações?

Nota: se você alterar seu email, receberá uma mensagem de confirmação

Nome da empresa:
Cargo/papel na empresa:
Tamanho da empresa:
País:
Estado:
Você vai receber um email para validação do novo endereço. Esta janela pop-up fechará em instantes.