Micro-serviços em sua essência são mais uma estratégia de componentização e, sinceramente, acho muito difícil criticar qualquer tentativa de se chegar a este objetivo. Gosto muito da estratégia, mas algo “nela” me incomoda bastante. Sabe o quê? A maneira como muitas vezes a vejo ser vendida.
Neste post exponho algumas falácias que vejo repetidas vezes em apresentações e posts. Acredito que seja um esforço fundamental pois a desonestidade intelectual (muitas vezes acidental) dos defensores de qualquer posição comprometem significativamente aqueles que, iludidos, adotam equivocadamente aquilo que lhes foi transmitido. Sendo assim, vamos às falácias.
Uma aplicação monolítica é uma coisa, e uma mal feita, outra
Aplicações monolíticas não são bugs e a prova é a quantidade imensa de casos de sucesso acumulados ao longo da história da computação: temos mais de meio século de experiência em arquiteturas deste tipo. Negar este passado é loucura ou desonestidade intelectual (para dizer o mínimo).
O que esquecem de mencionar aqueles que defendem este ponto de vista é que sempre há uma medida. Se o sistema for excessivamente extenso, naturalmente este será dividido em unidades fisicamente independentes. Esta divisão ocorrerá de forma evolutiva ou mesmo durante o processo arquitetural.
Reparem que usei a palavra extenso e não complexo. Complexidade independe do tamanho da aplicação e pode ocorrer tanto em pequenas aplicações de linha de comando quanto micro-serviços quanto aplicações monolíticas.
Bons argumentos em defesa de aplicações monolíticas você encontra neste post (leitura obrigatória). Outra leitura muito interessante sobre a estratégia monolítica encontramos neste texto do Chris Richardson, que inclusive expõe alguns pontos negativos.
E, bom: que tal irmos direto pra fonte e citar o Martin Fowler que foi um dos primeiros a escrever sobre o assunto e um dos principais responsáveis pela sua popularização:
não perca tempo considerando micro-serviços, a não ser que você tenha um sistema muito complexo para ser gerenciado como um monolito (tradução minha)
Esta dicotomia monolitos/micro-serviços é em si muito pobre. Sinto muita falta em apresentações de comparativos entre micro-serviços e outras estratégias de componentização que são simplesmente ignoradas.
A falsa novidade
Hoje para mim fica claro que micro-serviços não são uma novidade apesar de serem vendidos como tal. Os vejo como uma visão diferente do SOA. Um excelente texto sobre isto é este do Steve Jones. Também escrevi sobre isto, mas meu texto não é tão bom quanto o dele.
Historicamente é mais uma tentativa de componentização através de computação distribuída. Já vimos isto com o EJB, SOAP, CORBA, RPC, DCOM, OSGi, XDR e tantas outras tecnologias que vieram antes.
Em todas estas abordagens você tinha os pontos abaixo com graus variados de dificuldade na obtenção dos objetivos:
- Processamento distribuído
- A tentativa de se ter independência tecnológica (DCOM, EJB e OSGi conseguem isto através de algumas
gambiarrasestratégais) - Estratégias para se lidar com a ausência de um ou mais componentes externos
- Monitoramento
Talvez a novidade seja o ponto de vista muito influenciado pela emergência da cloud (Larry Elison tinha um ponto de vista interessante sobre a nuvem apesar de muito criticado) que viabiliza economicamente a estratégia.
(quando você estuda a história da computação, novidades vão se tornando cada vez mais raras, e fica muito nítido que esporadicamente nos vendem o velho com um novo nome)
A velha falácia do espantalho
Aqui entra a desonestidade intelectual em sua forma mais pura. São apresentados exemplos absurdos envolvendo arquiteturas monolíticas: coisas que apenas um completo imbecil faria e que não fazem parte do cotidiano de praticamente ninguém.
Alguns exemplos: “usar um servidor de aplicações pesadíssimo para hospedar uma aplicação mínima”, “uma aplicação monolítica contendo altíssimo acoplamento entre seus componentes” (o que ocorre em sistemas de qualquer escala). Na Wikipedia tem um texto legal sobre isto.
São argumentos que distorcem grotescamente o argumento do outro visando com isto ridicularizar o “oponente” diante dos demais.
Me lembram muito aquelas propagandas exageradas que passam de madrugada na TV, como… estas:
Normalmente desconfio de argumentos que tem como base a presença de alguém que não possua um cérebro fazendo bobagem.
A solução perfeita
Você questiona pelos custos da abordagem (seu lado feio) e simplesmente não obtém resposta. Ou então obtém uma resposta como “na realidade, escrever aplicações monolíticas é que é errado”.
Sério que existe uma solução perfeita e esta se chama micro-serviço? Sério que alguém realmente acredita nisto? Obviamente há custos envolvidos que não podem ser negados: você está lidando com uma solução distribuída, e todas as dificuldades que envolvem este modelo se manifestam aqui. Quer uma lista rápida? Vamos lá:
- Latência de rede
- A possibilidade da falha de uma dependência remota
- O custo do próprio protocolo que nem sempre é feito para se obter máximo desempenho (HTTP, JSON, XML)
- A necessidade de um monitoramento mais forte
- A necessidade de se ter um componente de descoberta de endpoints
E aqui ainda não mencionei os custos relacionados às mudanças culturais que sua equipe deverá passar, ou mesmo das complexidades envolvidas quando se possuí um ambiente tecnologicamente heterogêneo dentro de uma instituição.
Negar os custos é desonesto. E uma desonestidade maior ainda quando te dizem que estes problemas podem ser minimizados usando-se uma solução que você vende.
Aliás, é mais que desonesto: é irresponsável.
Uma visão muito ingênua de escalabilidade
Você realmente acredita que basta incluir mais instâncias do seu micro-serviço para que ele escale? Escalabilidade vai muito além disto. Envolve arquitetura, boa qualidade de código, boas estratégias de otimização.
Escalabilidade vertical é realmente tão limitada assim? Qual o contexto? É curioso: esta palavra essencial, contexto, simplesmente não é mencionada. Por falar nisto…
A ausência de contextos
Nunca vi uma estratégia que, em si, seja ruim. Agora: uma estratégia no contexto errado, sim. Algo que sempre me surpreende em apresentações ruins sobre micro-serviços é o quão negligenciado este ponto é.
Se seu cliente possuí uma forte limitação de infraestrutura, será que micro-serviços realmente são uma boa opção? E se sua equipe não se adequa à aplicação dos micro-serviços? Sua equipe que é ruim ou você que é um tirano?
Se não me mostrar o contexto, a conversa acaba ali. É simples assim e não há muito o que dizer a este respeito.
Concluindo
Micro-serviços são uma estratégia interessantíssima, mas infelizmente correm o risco de serem vistos em breve como uma falácia devido ao modo como é descrita. Este post é quase uma continuação de algo que escrevi recentemente sobre palestrantes e acredito que seja um bom exemplo do que quis dizer naquele momento.
Caso se interesse pelo que penso sobre micro-serviços, tenho dois posts neste blog sobre o assunto que podem ser lidos aqui e aqui.
Ótimo post Kiko,
E tem gente usando micro-serviços como desculpa para falta de modularização em uma aplicações monolíticas. O argumento usado é quase sempre o de se quebrar o monolítico vc força fronteiras entre módulos. É estranho pensar assim, pq, se o time não consegue pensar as fronteiras de módulos dentro de uma base de código única, o que leva a pensar que com micro-serviços vc teria uma melhor modularização? Talvez o efeito “físico” de ter módulos em outras aplicações conforte alguém.
Oi Luiz, obrigado!
Muito bom post, Kiko.
Todas estas falácias e hype me preocupam, principalmente em discussões onde você pergunta como enviar um e-mail e pessoal responde algo como “usa um micro-service para modularizar” sem nem ao menos ter criado e mantido um serviço desses na vida.
Sabe, arquitetura distribuída é difícil. Quando se decide trabalhar de forma distribuída tudo se muda na forma como implementamos nosso código e comunicação entre componentes. É diferente de desenvolver uma app monolítica onde todos os componentes se encontram na mesma JVM.
Enfim, o pior é o que esse hype cria: sistemas (complexos) para mantermos nos próximos anos. Você sabe né, todo mundo pensa que é um Netflix ou Twitter.
Oi Rafael, obrigado.
Como consultor sinto que todos temos a obrigação moral de falarmos a respeito pra evitar os prejuízos gigantescos que esta falta de honestidade intelectual pode causar (vai além do hype)
Exatamente! O problema é que todo mundo pensa que é um Netflix ou Twitter, logo cai no famoso anti-pattern “sledgehammer for a fly”.
Microservice é o novo scrum, kanban, agile, tdd, clean code, devops, container, SOA, REST e qualquer outra palavrinha que todos falam que utilizam, não sabem o porquê, mas é cool. É cool dar palestra, escrever post, fica bem na fita para gerência na empresa, para os amiguinhos nas redes sociais e ao final de tudo isso o código continua uma merda.
Oi Pedro, assim como qualquer novidade
Poderia fazer um post com sua visão sobre a galera que vende noSQL como a solução para escabilidade, performance. Esta quase virando sinônimo kkk
É uma bela ideia!
E acho que já escrevi alguma coisa sobre isto, vou ver se encontro aqui :)
Acho que existe uma definição extremamente bem sucedida do que é micro-serviços, do Martin Fowler e James Lewis, nesse artigo http://martinfowler.com/articles/microservices.html.
Deixando bem claro que micro-serviços não é SOA, o termo antigo Service-Oriented Architecture não se aplica ao desenho dessa abordagem de arquitetura. Podemos refazer o termo para Service-Oriented Api, seria mais adequado possivelmente.
Pois micro-serviços são em sua excelência, independentes e não dividem recursos, em SOA você precisa de exatamente o contrário. Pois eles são baseados no pattern ESB / Meet to the middle.
Aplicação monolíticas, não são ruins, mas primeiro temos que pensar o que significa uma aplicação que segue essa abordagem:
Ela divide recursos
Ela depende de tecnologias e/ou troca de mensagens heterogêneas
Ela não é difícil de escalar, ela não “escala”, como o termo é abordado hoje em aplicação para cloud. Ela se multiplica e divide recursos entre elas. Você cria mais servidores, com todas as suas capacidades, instala as aplicações em nodes (geralmente não lightweight) e espera que eles atendam a capacidade gerada.
Enfim, ela não é ruim, ela simplesmente é direcionada a tipos de produtos que se encaixam nessa perspectiva. Por exemplo:
Produtos corporativos que tem usuários definidos, modelos de dados estruturados, capacidade e limites definidos. Dentro de uma margem de risco. Ou seja, se a sua corporação tem características como essa, você pode seguir essa abordagem sem problemas, inclusive com muito sucesso. Inclusive no futuro você pode até mesmo fatiar em micro-serviços independentes e seguir a abordagem Monolith First http://martinfowler.com/bliki/MonolithFirst.html
Agora quando falamos em produtos que devem ter número desconhecido de usuários e recursos, elas não vão deixar de atender, mas o tredof entre custo, operacionalização e manutenibilidade vão fazer ela fracassar a médio prazo.
Não é atoa que Netflix, Facebook, Twitter, AllState, Humana, Linkedin, JPMorgan, CITI Group, Soundcloud, Gilt e etc. Mudaram para essa abordagem. Isso por que eles fracassaram, quando tentaram continuar com essa abordagem monolítica, pois o produto deles teve o comportamento completamente mudado com o advento do omnichannel, partner api, social e etc. E agora vemos bancos como Bradesco e ITAU indo para o mesmo caminho. Portanto não são uma falácia, são execuções reais da abordagem de micro-serviços.
Vemos mais um exemplo na indústria de telco. O Siebel, CRM mais usado por eles no Brasil. Tem sérios problemas de custo a médio e longo prazo. Fui gerente de arquitetura de software em 2 empresas de Telecom no Brasil. Nas duas o Siebel era um problema sério com relação a sua capacidade.
Mesmo sendo modular em muitos casos da sua arquitetura interna, era necessário multiplicar todas as suas capacidades cada vez que precisamos “escalar” o mesmo.
Gerando custos estratosféricos, principalmente de operação, mas a industria de telco no Brasil com o advento das OTTs (Over The Top, aka whatsapp por exemplo) acabaram com a previsibilidade de uso de recursos da capacidade disponível. E o Siebel acabou se tornando um gargalo.
O que uma dessas empresas decidiu fazer, foi simplesmente ir para cloud com ele, não que ele mudou para micro-serviços ou coisa do tipo. Simplesmente o custo operacional foi repassado para Oracle.
Existem outras dezenas de vantagens em usar micro-serviços, principalmente por que hoje temos recursos para gerenciar esse tipo de abordagem, como você citou descobrimento de endpoints (Netflix Eureka é um exemplo). Isso sem contar os inúmeros projetos open-source que foram criados e hoje suportam essa abordagem.
Acho que é importante como você descreve no artigo, não tomarmos bandeiras, aplicações monolíticas não são ruins. Elas funcionam desde que o produto que elas esperam oferecer esteja dentro de suas capacidades. E se no longo prazo, o custo de se manter ela ficar complicado (humano e financeiro) pode-se tentar uma outra abordagem como a dos micro-serviços.
Eis um belo comentário que enriquece o texto.