O desempenho de um sistema está ao nível dos seus processos.

Os repositórios de código são a base da organização da nossa organização e colaboração no desenvolvimento de software.

A escolha de mono ou multi-repositório é, portanto, estruturante e impactante, daí seu debate na comunidade.

Fomos capazes de compartilhar sobre este tema durante a mesa redonda “Como a escolha de mono ou multi-repositório pode melhorar a sua qualidade?”

O objetivo deste artigo é dar um passo atrás em relação aos desenvolvimentos que levaram ao surgimento de mono e multi-repositórios.

Então, vamos falar sobre monólito, microsserviços e perspectivas em torno desse tema muito debatido.

O mono-repo era historicamente a única opção possível

Alguns dos chamados sistemas legacy já fazem parte dos museus.

O tempo em que todos necessariamente conheciam esses sistemas, suas telas verdes, começa a desaparecer.

Teríamos até a tendência de querer esconder a posse de tal sistema para poder atrair talentos recentes.

Resumindo, a maior parte desses sistemas legacy está enraizada no Mainframe e em outros AS400s.

Construídos e operados em uma plataforma única e centralizada, seus componentes são construídos em uma base comum.

Além disso, o ecossistema estava longe de fornecer ferramentas como Git, Jenkins e de poder adotar CI/CD.

O contexto, a maturidade do ecossistema e a falta de interoperabilidade foram todos fatores reunidos para colaborar exclusivamente no modelo de mono-repositório.

Monolith com mono-repo tinha seu conjunto de desafios

Lembre-se de que os desafios eram de correr batches em janelas de tempo havendo fortes restrições de recursos.

Também era difícil entregar evoluções em paralelo, confrontando o fator limitante de sua organização. 

A integração de um novo membro na equipe também foi dificultada pelo volume de informações a serem integradas e pela complexidade do sistema. 

Já poderíamos ter falado sobre Cognitive load.

Era globalmente difícil conter a entropia de tal sistema, a complexidade tinha que ser gerenciada, sendo inevitavelmente encontrada neste monolith.

Essas várias questões e necessidades de negócios levaram à criação de sistemas mais distribuídos.

O ecossistema evoluiu para arquiteturas distribuídas que permitem multi-repo

Assim, surgiram novas plataformas e meios de comunicação.

Notamos, por exemplo, o aparecimento de chamadas de procedimento remoto, como Corba, que então evoluíram para protocolos de serviço da web mais padrão.

Lembre-se de que o objetivo deles era enfrentar os desafios de aceleração, paralelizando serviços entre equipes diferentes.

Em segundo lugar, o SOA apareceu com a promessa de reutilização de serviços para acelerar e capitalizar os investimentos.

É neste ecossistema que surgiram as arquiteturas multi-repos, suportando uma distribuição da complexidade do sistema como um todo.

Então, eramos salvos?

Nem tanto.

Sistemas distribuídos e multi-repo vieram com seus problemas

Essa famosa reutilização implementada por fortes acoplamentos de serviço síncronos criou arquiteturas frequentemente chamadas de código-esparguete.

Embora frequentemente associada a microsserviços, estou convencido de que qualquer tipo de arquitetura pode ser mal implementada.

As arquiteturas spaghetti não são apenas para microsserviços, podemos também desenhar muito mal um batch em Mainframe.

Antoine Craske

Então os mono-repos se tornaram completamente obsoletos?

Eles sobrevivem em um bom número de organizações ainda têm um Mainframe nos principais processos de negócios hoje em dia.

A distribuição de aplicativos, de fato, tornou o assunto dos repositórios um assunto global do sistema de desenvolvimento de software.

Os problemas frequentemente encontrados estão relacionados a escolhas puramente tecnológicas para decidir sobre um modelo ou um outro.

Decidimos ter um repositório por equipe e tecnologia, o que poderia ser mais lógico?

A perda de visão do sistema como um todo e de seus objetivos é o que falta na ponderação do modelo a ser retido.

Depois vieram os microsserviços.

Os riscos de microsserviços e multi-repo por padrão

Os microsserviços se tornaram uma moda, um de-facto standard a seguir para estar atualizado.

Sendo por natureza ainda mais distribuídos e pequenos do que nossos famosos serviços SOA, o multi-repositório seguiu a tendência.

No entanto, podemos nos perguntar se o multi-repositório é o único modelo válido para microsserviços?

Não creio, de fato, que vários níveis de equilíbrio sejam possíveis.

Você pode escolher atribuir um repositório para cada microsserviço, perto de uma função, com a maior divisão.

Este tipo de escolha pode ser atraente à primeira vista, no entanto, deve-se ter em mente que certos elementos necessários para vários componentes serão difíceis de manter.

O Domínio, a arquitetura e a perspectiva organizacional devem estar alinhados

Podemos, portanto, preferir ter um repositório para cada aplicação principal, operando normalmente em sua área funcional, possivelmente resultante de um processo de DDD.

Esse tipo de agrupamento nos levará a uma maior consistência dentro de um aplicativo, que também frequentemente será mantido pela mesma equipe.

Interessante porque, ao falar sobre técnica, facilmente perdemos de vista o aspecto organizacional e humano do desenvolvimento de software. 

Tal como acontece com as tendências, os actores podem até acabar perdendo de vista o objetivo inicialmente perseguido.

Isso é a priori o que acontece muito com microsserviços, onde podemos facilmente “jump on the band-wagon”.

Vemos que tanto mono quanto multi-repositórios são possíveis até mesmo para arquiteturas de microsserviços.

Portanto, manter um passo atrás em seus desafios continua sendo a chave.

Quase poderíamos nos encontrar perdidos em tantas opções.

Um retorno ao equilíbrio está ocorrendo atualmente no ecossistema

Por vários anos, temos encontrado sucessos regulares em mono-repositórios e sem microsserviços.

Voltando de nossos extremos, é realmente mais fácil dar um passo para trás.

Colocamos o problema de forma mais clara.

Nossa escolha de mono ou multi-repositório deve estar alinhada com os objetivos do sistema, e evoluir para suportar seu desenvolvimento.

Antoine Craske

Concretamente, uma start-up iniciando seu produto com pouca maturidade em seu campo, com uma equipe pequena, estará bastante indicada para uma arquitetura mono-repositório.

Menos obviamente, uma empresa que fornece um produto como uma plataforma SaaS pode beneficiar de um mono-repo para promover visibilidade, colaboração e integração ponta a ponta de seu produto.

Ao contrário, uma empresa em crescimento e equipes de desenvolvimento em crescimento terão todo o interesse em distribuir seu sistema, organização e repositório.

Uma organização com um mínimo de existência terá acumulado tecnologias frequentemente diferentes e pode, por contexto, decidir por um único ou multi-repositório de acordo com sua trajetória de modernização.

O contexto é, portanto, fundamental na escolha do repositório, que deve ser capaz de evoluir de acordo com a organização.

Uma IA automatizando a nossa escolha tornaria nossa vida muito mais fácil.

A automação, IA e outros bots vão nos ajudar?

É possível que aconteça, de momento temos alguns progressos visíveis.

Por exemplo, vemos o surgimento de ferramentas que lidam automaticamente com a atualização de dependências comuns a diferentes projetos, como o dependabot.

A realidade é que os sistemas distribuídos continuarão sendo necessários e se tornarão mais complexos em sua integração, por exemplo, com dispositivos móveis e IoT.

A aparência dessas soluções é, portanto, semelhante à dos pipelines de CI/CD: uma necessidade real a um problema estrutural.

Para que a IA entre em ação, não devemos esquecer que a Data Science em produção está começando a se democratizar e que, de qualquer forma, requer muitos dados para ser aplicável.

No entanto, para algumas repetições existentes, um bom algoritmo estatístico já pode fazer o trabalho.

Teremos pelo menos mais tempo para escolher nosso mono ou multi-repositório, e se realmente precisamos de microsserviços.

Até lá, a Google continua a ser a organização com um dos maiores mono-repo.