O Hype dos microserviços (Falei to leve)

Microserviços são a ideia certa, feitos do jeito errado. Será que eu li isso aqui? O problema não são os microserviços per si, mas a complexidade desnecessária que as pessoas adicionam aos seus projetos. Não é porque todas as grandes empresas tecnologias usam, que você deve usar também. Eles precisam de toda essa complexidade, você não.

O que faz sentido, porém, é criar programas que façam uma coisa bem feita e que trabalhem bem com outros programas, a boa e velha filosofia unix:

1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".

2. Expect the output of every program to become the input to another, as yet unknown, program.

Essa é a essência do que os microservices deveriam ser, não sistemas distríbuidos.

A tese A Note on Distributed Computing, escrito por pesquisadores da Sun é uma leitura essencial para qualquer pessoa interessada em compreender os desafios fundamentais da computação distribuída. Publicado no início dos anos 90, esse trabalho seminal destaca as diferenças cruciais entre programação local e distribuída, argumentando que construir sistemas distribuídos corretamente — seja em termos de desempenho, confiabilidade, escalabilidade, ou qualquer outro critério de "correto" — é notoriamente difícil.

Importante destacar, esse trabalho introduziu as "Falácias da Computação Distribuída", que são suposições errôneas que desenvolvedores frequentemente fazem ao projetar sistemas distribuídos. Quase todos que embarcam na jornada dos microserviços parecem não ter aprendido essas lições, ignorando coisas como latência e falhas de comunicação.

E mesmo que você acerte, e que a adoção de microservices traga vantagens significativas em termos de agilidade, resiliência e escalabilidade, ela invariavelmente introduz muita complexidade. Esta complexidade não deve ser subestimada. Quase sempre as dificuldades de gerenciar uma arquitetura distrubída é desproporcional as suas vantagens.

Na maioria dos cenários uma abordagem modular, inspirada na filosofia Unix, oferece as mesmas vantagens. Isso não apenas simplifica o desenvolvimento e a manutenção, mas também mantém a equipe focada em entregar valor de forma eficiente, sem se perder na gestão de uma arquitetura distribuída (e portanto) complexa.

Existe uma frase famosa que resume tudo: "Você não constrói um sistema distribuído a menos que você absolutamente precise dele"

Microsserviços é pra sistema de grande porte e escalável ponto.

Ultimamente tenho visto mais gente se opor aos microserviços... Meio que um "hype reverso". Parece que estão aos poucos notando os drawbacks de ter sistemas assim.

Transformar tudo em microserviços faz sua conta na AWS ficar muito extensa no final do mês.
Querem fazer a mesma arquitetura que o spotify mas esquecem que o mundo inteiro conhece o spotify.

Eu fui um dos que faziam parte desse culto. Depois do último projeto, me arrependo. Mas me arrependo só um pouco.

Resumindo: a experiência do seu time é um fator fundamental pra tomar a decisão de monolito X microsserviços.

Eu, o engenheiro de dados do projeto (com experiência prévia em dev), argumentei bravamente contra o líder técnico e o desenvolvedor full-stack (que era quem ia de fato desenvolver o nosso backend, sozinho). Ele queria fazer um monolito, pra entregar a solução o mais rápido possível. Eu disse que fazer um monolito ali não era a melhor solução, dada a complexidade do nosso sistema (não era um sistema simples, a empresa é de grande porte). Ele queria entregar rápido, porque ia sair da empresa em poucos meses, e nós íamos ficar lá com um monolito legado, de difícil manutenção. Eu estava pensando na manutenabilidade do sistema, e nada importava mais do que isso. Afinal, depois que ele saísse, a bomba iria cair no nosso colo.

Entretanto, eu falhei em levar em consideração que nem ele nem o líder técnico tinham experiência com arquitetura de microsserviços, e eles não tinham a quem recorrer para tirar dúvidas - a não ser eu. E eu não tenho tanta experiência assim com arquitetura de microsserviços! E mesmo se tivesse, eu tinha minhas tarefas com deadlines também. E ainda por cima acho que ele ficou com raiva de mim, porque não pediu ajuda também, mesmo eu me dispondo pra ajudar no que pudesse.

O resultado é que cerca de dois meses depois ele entregou um "microsserviço" por página da aplicação. Ou seja, como vocês já devem imaginar, havia duplicação de código por todo lado. Por exemplo, ao invés de fazer um microserviço para efetuar o log, o mesmo código era copiado em todos os microsserviços. Havia alto acoplamento, duplicação de código, e baixa coesão. Qualquer benefício de se ter um microsserviço passou a ser inexistente, mas mantivemos toda a complexidade de ter que manter várias bases de código separadas, e toda a dificuldade de administração da computação distribuída.

Portanto, eu diria que se você não tiver uma pessoa MUITO experiente no time, que irá parar tudo que ela está fazendo só para arquitetar bem os microsserviços, então faça um monolito.
Não subestime a quantidade de coisas que são necessárias de se aprender para se fazer corretamente um sistema orientado a microsserviços! DDD é só a ponta do iceberg, e só uma pessoa no time com esse conhecimento não será o suficiente!

... mas sigo dizendo que eu só me arrependo um pouco, porque continuo pensando que se tivéssemos feito uma arquitetura bem-feita, nós não teríamos o mesmo problema, e teria sido a melhor decisão para a saúde do projeto.