Recentemente a discussão sobre microsserviços retornou das profundezas da escuridão, sob temas superados, e reforçados em inúmeras oportunidades ao longo dos últimos anos.

Afinal, banco de dados compartilhado? Pode?

E monorepo? Faz sentido?

E o que Sam Newman diz sobre isso tudo?

Será que ele mudou o discurso ao longo do tempo?

Será que já não seria hora de falarmos sério sobre isso?

Tentar fazer resumo com IA tende a ser uma forma excelente para produzir uma compreensão completamente rasa e deturpada sobre os posts que escrevo aqui.

Já recebi comentários no LinkedIn e foram verdadeiros shows de horrores, pois, em geral, trago perspectivas e olhares diferentes onde o chatgpt tende a resumir de uma forma que deixa o principal de fora.

Voltando às origens

Ao falarmos de microsserviços temos de voltar no tempo e entender suas origens.

Convido a olhar alguns cases, demonstrados em apresentações específicas, livros e suas revisões editoriais, e posts, daqueles que guiam o mercado.

Minha opinião está presente apenas no argumento central do texto. E uso dos mais variados conteúdos para defender essa posição.

O case da Netflix

Aqui no gaGO.io quando abordei Cloud Native | 2 – A relação com Microservices, usei a apresentação do Adrian Cockcroft no GOTO 2014 contando sobre seu case de Microsserviços na Netflix.

Nessa apresentação temos o primeiro grande case de Microsserviços publicado com tantos detalhes. Estivemos diante do que considero o paciente zero dessa epidemia.

O texto é longo, mas essa análise é importantíssima, pois Cockcroft nos apresenta de mão beijada o real motivo para a adoção de uma arquitetura tão mais cara e tão mais complexa.

Dessa apresentação conseguimos aprender muito, inclusive que resiliência é uma escolha premeditada e deliberada, uma escolha profissional e não um evento casual. Escolher ser resiliente à queda da Amazon foi o que permitiu à Netflix ficar disponível para seus assinantes em todo o mundo durante uma queda da AWS em 2012. Tal queda parou a internet, exceto a Netflix.
Mas para que isso fosse possível foi necessário ter uma segunda cloud, projetar para ter redundância, e ter todo o custo de bancar essa decisão.
É importante ter isso em mente antes de julgar algo como overengeenering, ou mesmo quando nos deparamos com o minimalismo porco, ou o exteme go-horse travestido de ágil.

A definição de Fowler e Lewis

Antes da apresentação de Cockcroft, mas no mesmo ano, Martin Fowler e James Lewis definem Microsserviço no que talvez seja o post sobre microsserviço mais lido e mais referenciado de toda a internet.

O artigo de Fowler aponta mais players trabalhando com microsserviços:

• Amazon
• Netflix
• The Guardian
• o Serviço Digital do Governo do Reino Unido
• realestate.com.au
• Forward
• comparethemarket.com

O texto narra que:

Aqueles que conhecemos que são de alguma forma pioneiros no estilo arquitetônico incluem Amazon, Netflix, The Guardian, o Serviço Digital do Governo do Reino Unido, realestate.com.au, forward e comparethemarket.com. O circuito de conferências em 2013 estava cheio de exemplos de empresas que estão migrando para algo que seria classificado como microsserviços–incluindo a Travis CI. Além disso, há muitas organizações que há muito tempo fazem o que chamaríamos de microsserviços, mas sem nunca usar esse nome. (Muitas vezes isso é rotulado como SOA–embora, como dissemos, SOA venha em muitas formas contraditórias.14)
Fowler e Lewis | Microservices

e complementa

SOA dificilmente é a raiz desta história. Lembro-me de pessoas dizendo “fazemos isso há anos” quando o termo SOA apareceu no início do século. Um argumento era que esse estilo tem suas raízes na forma como os programas COBOL se comunicavam por meio de arquivos de dados nos primeiros dias da computação empresarial. Em outra direção, pode-se argumentar que os microsserviços são a mesma coisa que o modelo de programação Erlang, mas aplicados a um contexto de aplicação empresarial.
Fowler e Lewis | Microservices

Difícil discordar de Fowler, mas enquanto é fácil encontrar uma ligação quase direta com SOA, é um esforço descomunal fazer a mesma conexão com COBOL.

Em relação ao SOA, Microsserviço sempre me pareceu uma versão pautada na realidade, na solução de problemas de projetos.

Enquanto hoje, compreendo SOA como uma concepção utópica, acadêmica e uma propaganda para vender plataforma de big tech, cujo único problema que se presta a resolver é o de faturamento dessas grandes produtoras de ferramentas e consultorias.

Portanto, ouso não concordar com Fowler nessa nota de rodapé.

Fowler continua…

Os aplicativos monolíticos podem ser bem-sucedidos, mas cada vez mais as pessoas estão se sentindo frustradas com eles – especialmente à medida que mais aplicativos estão sendo implantados na nuvem. Os ciclos de mudança estão interligados – uma mudança feita em uma pequena parte do aplicativo requer que todo o monólito seja reconstruído e implantado. Com o tempo, muitas vezes é difícil manter uma boa estrutura modular, tornando mais difícil manter alterações que deveriam afetar apenas um módulo dentro desse módulo. O dimensionamento requer o dimensionamento de todo o aplicativo, em vez de partes dele que exigem maiores recursos.

Essas frustrações levaram ao estilo arquitetônico de microsserviços: construir aplicativos como conjuntos de serviços. Além do fato de os serviços serem implementáveis ​​e escaláveis ​​de forma independente, cada serviço também fornece um limite de módulo firme, permitindo até mesmo que diferentes serviços sejam escritos em diferentes linguagens de programação. Eles também podem ser gerenciados por equipes diferentes.

Não afirmamos que o estilo de microsserviço seja novo ou inovador; suas raízes remontam pelo menos aos princípios de design do Unix. Mas acreditamos que poucas pessoas consideram uma arquitetura de microsserviços e que muitos desenvolvimentos de software estariam em melhor situação se a utilizassem.
Fowler e Lewis | Microservices

Se ele soubesse o impacto desses poucos parágrafos na vida das pessoas, acredito que teria reescrito de outra forma, com muito mais cerimônia, considerando muitos mais aspectos antes de taxar monolitos, como parece fazer ao olhar inadvertido.

O entusiasmo de Newman

Um entusiasta de Microsserviços, por volta da mesma época começava a escrever um livro que virou uma febre de recomendações: Building Microsservices ou Construindo Microsserviços, em PT-BR.

O livro “Building Microservices” foi publicado em 2015 pela O’Reilly Media. O objetivo do livro foi fornecer uma visão abrangente de como criar e operar sistemas baseados em microsserviços, destacando tanto os aspectos técnicos quanto os organizacionais. Sam Newman aborda a transição de arquiteturas monolíticas para arquiteturas baseadas em microsserviços.

O livro foi bem aceito pela comunidade e vem sendo considerado um guia para entender e implementar microsserviços, chegando a ser considerado leitura obrigatória para aqueles que desejam entender os princípios e práticas dessa arquitetura.

Entretanto, com o rápido avanço das tecnologias e práticas, partes do livro podem parecer desatualizadas, especialmente em áreas como orquestração de containers e ferramentas específicas.

Essa primeira versão do livro serviu como mecanismo de propaganda para microsserviços, e uma parcela dos leitores acabaram a leitura defendendo Microsserviços para absolutamente tudo, como se estivéssemos diante do Santo Graal da Arquitetura de Software, algo que enfim superasse as demais propostas arquiteturais, principalmente as monolíticas.

Tivemos uma grande revisão em 2021, e agora que endereçaram muitos desses tópicos.

Mas afinal, que problemas microsserviços resolvem?

Ambos, Fowler + Lewis e Cockcroft nos apresentam problemas sobre como as bases de código ficam complexas de se manter e evoluir.

A dor, o problema, o motivo que eles reportam estão diretamente ligados aos problemas para lidar com ciclos de evolução e mudança.

Sabemos que conseguimos, com microsserviços, alcançar benefícios técnicos, como escalabilidade, resiliência, mas nenhum deles é usado como ARGUMENTO em momento algum.

Eles falam da capacidade de colocar features em produção.

E não de benefícios adjacentes como capacidade de escala,
resiliência, observabilidade, paralelismo, eficiência.

O pilar central da adoção de microsserviços é a

independência.

A independência destrava a capacidade de entregar mais features, responder à mais demandas de negócio, gerando menos impacto em suas dependências.

A falta de clareza sobre o argumento central, independência, produz como efeito colateral uma enxurrada de pensamentos equivocados e discussões inúteis sobre o tema.

Muitas dessas discussões culminam em implantações imaturas, precoces e principalmente, descabidas.

Enquanto a adoção de microsserviços for pautada por argumentos técnicos frágeis, como resiliência, escalabilidade, desempenho, capacidade de trabalhar com múltiplas linguagens e frameworks, não há muita chance de sucesso sem que primeiro seja experimentado um ou mais fracassos que demandem revisão dos fundamentos.

Com alguma sorte, conseguirão, após alguns fracassos, não desgastar a arquitetura e o termo, antes do seu sucesso.

Na maior parte das vezes o termo vira persona non grata para muitos que participaram dessa jornada.

Mas por que esses argumentos são frágeis?

De um lado, muitos dos benefícios exclusivamente técnicos, como escalabilidade, resiliência, e confiabilidade podem ser obtidos tanto em monolitos quanto em microsserviços.

Claro que com esforços diferentes, com formas e limites diferentes.

Mas pode ser ainda pior: A ausência de comunicação de rede entre essas partes, faz algumas demandas como resiliência, por exemplo, ou tolerância à indisponibilidade sequer existam na escala em que existem em microsserviços, quando estamos tratando de monolitos.

Alguns dos problemas resolvidos com microsserviços
são decorrentes da própria adoção de microsserviços.

Sem considerarmos a independência como ponto central, concessões levianas são realizadas. E como resultado, os objetivos de facilitar o desenvolvimento, testes e implantação de releases independentes nunca são obtidos.

Em termos práticos, é muito divertido para o time de tecnologia, entretanto a área de negócio nunca experimenta aquilo lhe foi vendido meses ou até anos antes do início do processo de adoção de microsserviços.

Não é o fim

Ao chegarmos nesse cenário, precisamos voltar às bases antes que seja tarde.

Há luz no fim do túnel. Nesse estágio, há tanta gente envolvida e comprada em uma ideia errada e simplista sobre microsserviços, que chega a ser difícil abortar a adoção, seria um atestado de incapacidade e um recibo de incompetência.

Nessa fase, ainda há como recuperar, bastando voltar ao princípio da independência e tomar as decisões difíceis que foram evitadas ou negligenciadas ao longo da jornada.

Mas e quando o monolito não escala?

Em geral o monolito não escala por erros de implementação, por problemas técnicos resolvíveis.

Esses erros são ocasionados por falta de conhecimento e/ou supervisão, que podem ter como origem:

• Times imaturos (times inteiros só com juniores)
• Ausência de seniores
• Sobrecarga nos seniores existentes
• Falta de fluxo de supervisão de juniors e plenos
• Má definição de autonomia e liberdade
• Falta de gestão de requisitos não funcionais e criação de regras
• Problemas na contratação e na avaliação de hard skills.
• Problemas com cargos e salários, fazendo com que não sênior assumam a posição de senioridade.

Há muitas formas de se chegar a um cenário onde devs sem preparo, escrevem códigos que não escalam, e os colocam em produção. Eu listei apenas os mais comuns, que me vêm à cabeça.

O problema da escala está, raramente, relacionado à arquitetura.

• Em geral os problemas são:
  • o uso de variáveis, listas, cache estáticas/singleton
  • adoção de memory cache
  • uso de sessão sem configuração de cluster

esses são os principais motivos para a não escala em uma aplicação web .NET típica, por exemplo.

Os times não alcançam boa parte desses objetivos
por falta de conhecimento e/ou impossibilidade.

Mas há um agravante no desejo por escala: A maioria das vezes a demanda por escala é imaginária.

A maioria absoluta dos projetos que tomei conhecimento precisa de algo entre 2 e 10 instâncias, e nada mais.

Claro que “MAIORIA”, não significa “TODOS” – Deveria ser óbvio, mas não é.

E claro, se você é um banco ou um e-commerce, não estou falando para você. Se você tem um produto/projeto que lida com milhares de usuários simultaneamente, temos um cenário bem diferente.

A demanda por escala até existe, mas não demanda muitas instâncias, sem nenhuma necessidade de dinamismo, sem necessidade de reconfiguração.

Para cada 1 aplicação que realmente precisa de escala, em nível profissional, milhares não demandam.

Conclusão

Sem a compreensão de que Independência é pilar da arquitetura de microsserviços, times que tentarem adotá-la, cometerão os mesmos erros do passado, e, portanto, terão os benefícios da arquitetura bloqueados, parcialmente ou até totalmente.

O caminho para superar esse desconforto da independência é assumir, mesmo que hipoteticamente, em um exercício mental, que estamos diante de uma verdade absoluta, para conseguirmos destravar as perguntas que realmente farão diferença nessa jornada.

Enquanto nos mantivermos travados e relutantes a respeito da independência, perdemos a capacidade de fazer as perguntas cujas respostas preencherão as lacunas que nos falta.

Continua… essa é apenas a parte 1 de 3