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

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.

Elemar Júnior

Microsoft Regional Director e Microsoft MVP. Atua, há mais de duas décadas, desenvolvendo software e negócios digitais de classe mundial. Teve o privilégio de ajudar a mudar a forma como o Brasil vende, projeta e produz móveis através de software. Hoje, seus interesses técnicos são arquiteturas escaláveis. bancos de dados e ferramentas de integração. Além disso, é fascinado por estratégia e organizações exponenciais.

Talvez você goste também

Carregando posts…
4 Comentários
  1. Lucas

    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

    1. Julio Borges

      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.

    2. Renan Aragão

      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.

  2. Portella

    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.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *