Por que mantemos Ruby on Rails no GitLab – New Stack

By | Junho 13, 2022

Quando David Heinemeier Hansson criou Ruby on Rails (entrevista), foi guiado por sua experiência com PHP e Java. Por um lado, ele não gostou do modo como a vastidão e a rigidez do Java tornaram os frameworks da Web Java complexos e difíceis de usar, mas apreciou sua integridade estrutural. Por outro lado, ele gostou da acessibilidade inicial do PHP, mas preferiu as zonas úmidas em que esses projetos geralmente se transformavam.

Java Difícil de usar, bem estruturado
PHP Acessível, desarrumado

Estas parecem ser escolhas exclusivas: ou você se torna acessível e confuso, ou você é bem estruturado e difícil de usar, escolha seu veneno. Costumávamos fazer uma distinção semelhante, e igualmente difícil, entre sistemas operacionais de classe de servidor, como Unix, que eram estáveis, mas difíceis de usar, e sistemas operacionais de cliente, como Windows e MacOS, que eram acessíveis, mas frequentemente travavam. .

Todos aceitaram essa dicotomia como dada por Deus até que a NeXT colocou uma GUI bonita, acessível e suave em uma base sólida do Unix. Hoje, as “classes de servidor” do Unix executam não apenas belos desktops GUI, mas a maioria dos telefones e smartwatches.

Assim, acessibilidade e demolição mostraram-se independentes, exceto em casos históricos, e o mesmo foi demonstrado para acessibilidade e desordem em frameworks web: são eixos independentes.

Difícil de usar Acessível
Desleixado PHP
Bem estruturado Java

E esses eixos independentes abriram um espaço aberto muito desejável no canto inferior direito: um framework web acessível e bem estruturado.

Com seu legado Smalltalk sólido e metaprogramável e boa integração com Unix, Ruby provou ser a ferramenta perfeita para o criador Ruby DHH preencher o canto inferior direito da tabela com Rails: um framework web extremamente acessível, produtivo e bem estruturado.

Difícil de usar Acessível
Desleixado PHP
Bem estruturado Java Ruby nos trilhos

Quando o co-fundador do GitLab, Dmitriy Zaporozhets, decidiu que queria trabalhar em software para executar seu (e seu) servidor de controle de versão, ele também veio de um background PHP. Mas ao invés de se ater ao famoso, ele escolheu Rails.

A escolha de Dmitry pode ter sido premonitória ou acidental, mas serviu extremamente bem ao GitLab, em parte porque David conseguiu atingir seus objetivos para Rails: acessibilidade com boa arquitetura.

Por que Modular?

Sid Sijbrandij

Sid é cofundador, CEO e CEO da GitLab, Inc., uma plataforma DevOps. Sid passou quatro anos construindo submarinos recreativos para o U-Boat Worx e, enquanto no Ministério da Justiça e Segurança da Holanda (Ministerie van Justitie en Veiligheid), trabalhou no projeto Legis, que desenvolveu vários aplicativos inovadores da web para ajudar a elaborar leis. . Ele viu Ruby pela primeira vez em 2007 e se apaixonou tanto por ele que aprendeu a programar sozinho. Em 2012, como desenvolvedor Ruby, conheceu o GitLab e revelou sua paixão pelo código aberto. Pouco tempo depois, Sid comercializou o GitLab, que cresceu para mais de 30 milhões de usuários registrados de startups a empresas globais.

Na seção anterior, a modularidade foi assumida como uma propriedade desejável, mas como também vimos, é perigoso apenas supor coisas. Então, por que e em que contextos a modularidade é realmente desejável?

Em seu trabalho de 1971.Sobre os critérios para desmontar o sistema em módulos David L. Parnas deu as seguintes vantagens (desejadas) de um sistema modular:

  • O tempo de desenvolvimento deve ser “encurtado porque grupos separados trabalhariam em cada módulo com pouca necessidade de comunicação”.
  • Deve ser possível fazer “mudanças ou melhorias drásticas em um módulo sem alterar os outros”.
  • Deve ser possível estudar o sistema um por módulo.

A importância de reduzir a necessidade de comunicação foi mais tarde enfatizada por Fred Brooks em “O mês do homem mítico”, Com comunicação adicional, uma das principais razões para o velho ditado de que “adicionar pessoas a um projeto de software posterior faz isso mais tarde”.

Não precisamos de microsserviços

A modularidade era geralmente tão ilusória quanto muito procurada, e a arquitetura padrão da maioria dos sistemas era Uma grande bola de lama. Compreende-se, portanto, que os designers se inspiraram provavelmente no maior sistema de software que existe: a World Wide Web, que é modular conforme a necessidade; não pode funcionar de outra forma.

Organizando seus sistemas de software locais usando processos separados, microsserviços que são combinados usando um DESCANSO estilo arquitetural, ajuda a impor limites de módulo através do sistema operacional, mas a um custo significativo. Esta é uma abordagem muito difícil de alcançar a modularidade.

A dificuldade e o custo de executar o que agora é um sistema distribuído gratuitamente é significativo, e alguns dos problemas de desempenho e confiabilidade foram documentados em equívocos de computação distribuída. Em suma, o custo de desempenho e confiabilidade é significativo, pois as chamadas para funções que duram nanossegundos e nunca falham são substituídas por operações de rede que são três a seis ordens de magnitude mais lentas e falham. Os erros se tornam muito mais difíceis de diagnosticar se tiverem que ser rastreados por meio de vários serviços com pouco suporte de ferramentas.

Para executar um microsserviço com sucesso, você precisa de uma organização DevOps bastante sofisticada. Isso realmente não faz diferença se você estiver trabalhando em uma escala que exige essa sofisticação de qualquer maneira, mas é muito provável que você não é o Google.

Mas mesmo que você pense que pode gerenciar tudo, é importante notar que toda essa complexidade aleatória está no topo da complexidade original essencial do seu problema; microsserviço não faz nada para reduzir a complexidade. Mesmo as melhorias de modularidade esperadas não são nem um pouco garantidas, você geralmente as obtém bola de barro arranjada.

Monorashin

Ao tornar a boa arquitetura acessível e produtiva, o Rails permitiu que o GitLab desenvolvesse um monólito modular. Um monólito modular é o completo oposto de uma bola de lama distribuída: um programa bem estruturado, bem arquitetônico e altamente modular que funciona como um processo e como tedioso tanto quanto possível.

Embora estruturar o GitLab como um monólito tenha sido extremamente útil para nós, não somos dogmáticos sobre essa estrutura. A arquitetura segue as necessidades, e não o contrário. E embora o Rails seja uma tecnologia excelente para nossas necessidades, ele tem várias desvantagens, e uma delas é o desempenho. Felizmente, apenas uma pequena fração da maioria das bases de código é realmente crítica para o desempenho. Usamos nosso próprio Guitarras um daemon escrito em Go para lidar com operações git reais e PostgreSQL para persistência sem armazenamento.

Abra o núcleo

Por último, mas não menos importante, nosso monólito modular gira nosso núcleo aberto modelo de negócios de apenas uma boa teoria para prática realidade. Embora o Rails não consiga isso sozinho – esses seriam nossos maravilhosos colaboradores e engenheiros – ele estabelece a base certa.

Colher a verdade benefícios open source, o código fonte disponibilizado deve ser acessível aos contribuidores. Para manter a integridade arquitetônica diante de contribuições de diversas fontes e manter uma linha clara de demarcação entre componentes abertos e fechados, o código deve ser muito bem estruturado. Soa familiar?

Não seria melhor ter uma interface de plugin adequada? Ou melhor ainda, uma interface de serviço no estilo microsserviço? Em uma palavra: não. Essas abordagens não apenas impõem barreiras à implementação e integração que vão além de “eu fiz uma pequena alteração no código-fonte”, elas geralmente impõem restrições arquitetônicas com muita rigidez. Antecipar todos os pontos futuros de expansão é uma tarefa tola que, felizmente, não embarcamos e nem precisamos.

Com nosso monólito modular irritante, os usuários e outros desenvolvedores de terceiros podem contribuir e contribuem para as melhorias do produto principal, dando-nos uma força tremenda, juntamente com um ritmo incomparável e escalabilidade de inovação.

Deixe uma resposta

O seu endereço de email não será publicado.