A “maldição” dos sistemas monolíticos distribuídos

Elemar Júnior

Decompor sistemas em serviços sem combater adequadamente o acoplamento aumenta a complexidade e, frequentemente, resulta em monolíticos distribuídos. Ou seja, sistemas que acumulam tanto as dificuldades de sistemas distribuídos quanto as de monólitos que rodam em um único processo. Tudo isso, sem quaisquer vantagens para os times técnicos tampouco para o negócio.

Sabemos, com certeza, que estamos frente a um monólito distribuído quando todo deploy precisa ser do “sistema inteiro”, mesmo que sua composição seja serviços rodando em processos independentes.

Também há boas chances de estarmos lidando com um monólito distribuído quando há alto changing coupling. Ou seja, quando qualquer modificação em um serviço implica modificações em outros, mesmo que estes estejam em repositórios diferentes.

Monólitos distribuídos emergem rapidamente em arquiteturas com “serviços de dados”, geralmente produzidos tentativas bem-intencionadas de implementar REST, mas que não passam de “camadas sofisticadas” de persistência rodando em processos separados.

Também são monólitos distribuídos emergentes aqueles sistemas com frontend em repositório apartado daquele(s) onde está/estão o(s) serviço(s) com a lógica de negócio, mas onde todos os desenvolvedores precisam manter clones de todos os repositórios em suas máquinas e pelo menos duas instâncias da IDE abertas para “depurar o todo”.

Sistemas monolíticos distribuídos são efeito colateral da prática descuidada das disciplinas de arquitetura, não dedicando tempo e atenção suficientes na delimitação dos contextos, resultando na baixa coesão das funcionalidades para o negócio.

O antídoto para os monolíticos distribuídos passa pela resistência a “fragmentação” exagerada, que só aumenta a complexidade e a quantidade de código repetido. É essencial considerar a coesão sobretudo das funcionalidades.

Não podemos ignorar que uma das principais justificativas para a decomposição de um sistema em serviços é transferir parte da complexidade das atividades de desenvolvimento para a operação, onde poderá ser mitigada com automação. Se a atividade de desenvolvimento não fica mais fácil, adicinou-se apenas complexidade desnecessária e custos não justificados.

Em tempos onde todo mundo está ansioso para desenvolver sistemas com microsserviços, é necessário cuidado redobrado para não acabar “trazendo ao mundo” mais um monolítico distribuído.

Em resumo

O problema
A insistência na decomposição de monolíticos em serviços tem feito surgir uma categoria sofrível de sistemas: os monolíticos distribuídos. Ou seja, onde são acumulados tanto os problemas relacionados com monolíticos rodando em processo único quanto da operação de sistemas distribuídos.
O insight
A coesão, principalmente com relação as funcionalidades de negócio, deve ser obsessão nas atividades de elaboração da arquitetura. Não faz sentido manter frontend e backend em repositórios separados se eles forem mantidos pelos mesmos desenvolvedores. Também é preciso tomar cuidado para não implementar, simplesmente, arquiteturas com camadas de persistência distribuídas.

Compartilhe este insight:

Comentários

Participe deixando seu comentário sobre este artigo a seguir:

Subscribe
Notify of
guest
5 Comentários
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Lucas
Lucas
2 anos atrás

Muito bom os artigos de vocês, estou sempre lendo e sempre tomando uma porrada diferente. Faz total sentido o que diz acima, mas eu trabalho com angular ++ e dotnet core, tenho q trabalhar no back e no front pq só existe eu na empresa onde trabalho. Quase sempre estou com 2 vscode abertos, as vezes o ssms tambem. Eu gostei muito mais de trabalhar assim, pois conseguir ficar mais organizado e as vezes me sinto até mais produtivo, pq consigo dar uma focada em uma stack só durante um tempo. Sei que o foco do artigo é criticar a complexidade desnecessária. Mas qual seria a alternativa pra trabalhar com APIs e Spas, sem ter 2 repositórios diferentes? Um abraço, parabéns pelos artigos mais uma vez

Julio Borges
Julio Borges
2 anos atrás

Acaba que com a sua stack até que dá pra trabalhar no mesmo repositório, visto que ambas se desenvolve com a mesma IDE. Mais o maior problema é a complexidade de ter o código da mesma aplicação em dois repositórios separados, pois aumenta a possibilidade de se fazer uma implementação em um repo e deixar de fazer no outro repo.
Além disso o trackeamento das alterações é único quando temos um repositório apenas para front e back.

Portella
Portella
2 anos atrás

Exatamente por esse e alguns outros motivos que defendo não seguir uma determinada proposta de engenharia, arquitetura ou partner como verdade absoluta. Mas defendo ao mesmo tempo que é prudente estar sempre o mais próximo possível de tender a elas. E isso se conquista com capacidade abstração e construção de domínios com facilidade na compreensão além de alta diligência.

Renan Aragão
Renan Aragão
2 anos atrás

Eu prefiro manter em repositórios separados. Entendo que existe um acoplamento e muitos commits serão “redundantes”, mas também existem muitas preocupações no front que não é nada acomplada com o back sendo assim, para mim, projeto diferentes.

Franklin Hermes
Franklin Hermes
1 ano atrás

Olá Elemar, os links para eximia.tech citados estão indisponíveis, eles vão ser migrados para insights?

AUTOR

Elemar Júnior
Fundador e CEO da EximiaCo atua como tech trusted advisor ajudando empresas e profissionais a gerar mais resultados através da tecnologia.

NOVOS HORIZONTES PARA O SEU NEGÓCIO

Nosso time está preparado para superar junto com você grandes desafios tecnológicos.

Entre em contato e vamos juntos utilizar a tecnologia do jeito certo para gerar mais resultados.

Insights EximiaCo

Confira os conteúdos de negócios e tecnologia desenvolvidos pelos nossos consultores:

Arquitetura de Dados

Insights de um DBA na análise de um plano de execução

Especialista em performance de Bancos de Dados de larga escala
Arquitetura de Software

Estratégias para modernização do legado

Desenvolvedor .NET/NodeJs e especialista em Kafka com experiência em startups e grandes empresas
Infraestrutura e Nuvem

Migração para a nuvem, mais do que mudança tecnológica, implica em mudança da cultura organizacional

Engenheiro de nuvem, arquiteto de software e especialista em Containers e Devops

Acesse nossos canais

Simplificamos, potencializamos e aceleramos resultados usando a tecnologia do jeito certo

EximiaCo 2022 – Todos os direitos reservados

5
0
Queremos saber a sua opinião, deixe seu comentáriox
()
x

A “maldição” dos sistemas monolíticos distribuídos

Para se candidatar nesta turma aberta, preencha o formulário a seguir:

Condição especial de pré-venda: R$ 14.000,00 - contratando a mentoria até até 31/01/2023 e R$ 15.000,00 - contratando a mentoria a partir de 01/02/2023, em até 12x com taxas.

Tenho interesse nessa capacitação

Para solicitar mais informações sobre essa capacitação para a sua empresa, preencha o formulário a seguir:

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

O seu insight foi excluído com sucesso!

O seu insight foi excluído e não está mais disponível.

O seu insight foi salvo com sucesso!

Ele está na fila de espera, aguardando ser revisado para ter sua publicação programada.

Tenho interesse em conversar

Se você está querendo gerar resultados através da tecnologia, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse nessa solução

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

Tenho interesse neste serviço

Se você está procurando este tipo de solução para o seu negócio, preencha este formulário que um de nossos consultores entrará em contato com você:

× Precisa de ajuda?