Monólitos de escala vs. microsserviços de escala

Um dos argumentos comuns para o uso de microsserviços é a melhor escalabilidade. Mas me pergunto se esse argumento é realmente válido.

Digamos que tínhamos um aplicativo composto por 10 microsserviços, sendo que nove deles tinham cada uma duas instâncias (para redundância) e uma delas com quatro instâncias para lidar com a carga (escalabilidade). O argumento pró-microsserviço é que você pode escalar esse miroserviço independentemente dos outros serviços.

No entanto, digamos que todos os 10 microsserviços eram módulos em um único monólito e que várias instâncias (por exemplo, 22 como a soma acima) foram implantadas. O sistema deve ser capaz de lidar com a carga da parte crítica, porque há instâncias suficientes para isso. Se as instâncias não contiverem lógica do programa, a única desvantagem seria que o binário e a quantidade de RAM necessária seriam um pouco maiores. Mas, novamente, a diferença não deve ser muito grande na maioria dos casos - pelo menos não em comparação com o restante da pilha (pense no Spring Boot). A vantagem de um monlito em escala seria um sistema mais simples sem (a maioria das) falácias de um sistema distribuído.

Estou esquecendo de algo?

microservices

— Deamon
fonte

Qual é o tamanho de um monólito que você está falando? Porque acho que poderia ser mais do que uma quantidade "ligeiramente maior" de RAM. Sem mencionar o tempo de implantação - a correção de um bug pode levar 22 implantações em vez de 4. Mas talvez o seu monólito seja pequeno e as implantações não demorem muito tempo, as migrações de banco de dados não demoram muito e assim por diante.

— Thomas Owens

Eu não contei linhas de código, mas o monólito teria vários milhares de linhas de código (não um sistema gigante). O ponto de partida da minha consideração foi que o tamanho do código real do aplicativo é pequeno comparado a grandes estruturas como Spring e Hibernate. O número de implantações realmente pode ser menor do que nos microsserviços, porque se você tivesse duas instâncias, já teria redundância básica e mais instâncias seriam para escalabilidade.

— deamon

@ Deamon Esteja ciente de que, com a abordagem do monólito, não há partes do código totalmente mortas em cada instância, apenas códigos raramente usados. Agora, o próprio código pode consumir apenas uma pequena quantidade de memória, mas se ele usar muitos objetos acumulados na memória, essa quantidade poderá crescer substancialmente.

— 30519 Frank

Observe que a sobrecarga básica de "obtenção de código de execução" não é necessariamente tão grande quanto você pode conhecer em seus aplicativos Java, onde frequentemente a jvm inteira faz parte da imagem de serviço.

— 25419 Frank

Respostas:

O objetivo dos microsserviços não é reduzir a carga do processador. De fato, devido à sobrecarga de comunicação e repetição de funções que costumavam ser códigos de utilidade global, geralmente aumenta um pouco a carga do processador.

O ponto de abolir um monólito é muito mais para ser capaz de manter, implantar e executar um sistema complexo de funcionalidade em tudo . Quando seu sistema atinge um determinado tamanho, compilação, teste, implantação etc., um monólito se torna caro demais para ser possível, mantendo um tempo de atividade decente. Com os microsserviços, você pode atualizar, reiniciar ou reverter um sistema aos poucos.

Não se engane, não escrevemos microsserviços, porque é inerentemente uma solução melhor para agrupar as coisas livremente em interfaces remotas. De fato, a perda do tipo forte e da verificação de consistência que um monólito poderia fornecer geralmente é uma grande desvantagem. Fazemo-lo porque precisamos, porque a complexidade superou-nos e está a tirar o melhor partido de uma situação subótima.

— Kilian Foth
fonte

Acordado. A razão para mudar para uma arquitetura de microsserviço é principalmente política. Carga distribuída, desacoplamento são consequências, não causas. O benefício real dos microsserviços está no SDLC e na Governança. Além disso, a arquitetura é a resposta lógica a uma necessidade que, na maioria dos casos, vem da estratégia de mercado da empresa. O tempo de colocação no mercado é mais curto do que as arquiteturas monolíticas para que a empresa está autorizada a adoptar novas estratégias, mudar de um para outro sem problemas e rapidamente

— LAIV

É por isso que alguém também não deve ir diretamente aos microsserviços para aplicativos médios e pequenos. A sobrecarga e a complexidade adicionada ao sistema podem muito bem acabar custando mais tempo, dinheiro e qualidade do que um sistema monolítico nessas escalas.

— 9788

»Fazemos isso porque precisamos, porque a complexidade superou-nos e está tirando o melhor proveito de uma situação subótima.« Sim. Para mim, isso é demais!

— Thomas Junk

Eu tenho que discordar da última parte da resposta. micro-serviços são inerentemente melhores do que um monólito, porque eles utilizam mais de um computador

— Ewan

@ewan Você também pode usar mais de um computador com monólitos.

— deamon

Você está mais correto. Se você tiver serviços rápidos carregados igualmente, poderá instalá-los em todas as caixas. Não é tão "legal" quanto ter uma caixa por serviço, mas economiza dinheiro.

Contudo. assim que houver um desequilíbrio, digamos que o serviço 5 consiga 100% da CPU por 2 minutos, você deseja mover esse serviço para sua própria caixa para que não bloqueie todos os outros serviços se for executado.

Se as chamadas para o serviço atingirem o tempo limite devido ao carregamento, apenas algumas funções do seu aplicativo falharão em vez de todas.

Agora você pode fazer o mesmo com um monólito bem modularizado. Instale todos os serviços, mas apenas direcione o tráfego do serviço 5 para um deles. Embora não esteja encaminhando o tráfego do serviço 5 para as outras caixas.

Mas, geralmente, os monólitos, por sua própria natureza, não são uma coleção frouxa de serviços que são instalados na mesma caixa. Haverá na memória chamadas entre os módulos, o que causará a falha do aplicativo.

— Ewan
fonte

O objetivo dos microsserviços é 1) separação de preocupações e 2) distribuição de carga. Essencialmente, isso nos libera para fazer o melhor serviço de caixa preta possível com tecnologias específicas para essa tarefa. Nossos serviços podem ser poliglotas - escritos em diferentes linguagens de programação em diferentes pilhas. Equipes diferentes podem trabalhar em cada serviço sem ter conhecimento de como os outros trabalham além do contrato de sua API. Isso, em conjunto, permite uma base de código muito mais simples para cada serviço, mais fácil de depurar, entender e ajustar para desempenho.

— Lewis A Sellers
fonte

Eu concordo parcialmente. Meu argumento não era sobre argumentos para microsserviços em geral, mas sobre escalabilidade. No meu caso específico, os microsserviços são todos escritos na mesma tecnologia, por exemplo. Portanto, embora seja possível usar uma tecnologia diferente para cada uma, simplesmente não é o caso aqui. Eu queria verificar se não perdi um ponto importante sobre escalabilidade.

— deamon