Why GitLab Technology Picks Are So Different: Sticking With the Outdated Ruby on Rails Framework

Compilation｜Nuka-Cola, Yan Shan

Regarding the popular influencer programming language Ruby, we previously wrote an article looking back at its highly sought-after past and discussing its declining state of existence. Popularity isn’t a direct indicator of poor language quality, though. On the one hand, Ruby on Rails (an open-source web application framework written in Ruby) is still a great way to implement prototyping demos and help developers more securely build in a matter of days. Minimum Viable Product, on the other hand, there is still a rigid market demand for Rails and Ruby developers.

GitLab recently published an article explaining why they stick with Ruby on Rails. There are many popular websites in the world built on Rails, and although Rails has the trend of sunset today, the technology selection has to be “right”. From GitLab’s point of view, they don’t have a complex operating system themselves, and they don’t need to use microservices. In this case, Ruby on Rails is the best choice for them.

Where Ruby on Rails wins

In July 2004, Rails founder David Heinemeier Hansson spun off Ruby on Rails from Basecamp, 37signals’ project management tool, and released it as open source.

In an interview David reviewed his journey to creating Ruby on Rails, the biggest influence came from his in-depth experience with PHP and Java. On the one hand, he dislikes Java’s verbose, rigid design that makes Java Web frameworks complex and difficult to use, but he appreciates Java’s good structural integrity. On the other hand, he likes the friendly nature of PHP’s ease of use, but also finds PHP too confusing to provide a smooth project development track.

The situation was that you had to choose between two options that were not good enough: either easy to use but cluttered, or well-structured but hard to use. This dilemma is reminiscent of the classic conundrum between server-class operating systems (such as the stable but hard-to-use Unix) and client operating systems (such as the easy-to-understand but often crashing Windows and MacOS).

At the beginning, everyone felt that reality was so cruel, and they could only fall into a difficult choice of two. But then NeXT developed a nice, easy-to-use and smooth GUI on top of the solid foundation of Unix. Today, “server-grade” Unix can not only run beautiful GUI desktops, but can even be installed in most mobile phones and smart watches.

So it turns out that ease of use and stability are not an either-or relationship. The same goes for ease of use and confusion in web frameworks – two parallel lanes, why do they have to be intertwined?

So David sees an ideal balance: a web framework that is both approachable and well-structured. With its solid, metaprogramming-enabled Samlltalk features, coupled with good Unix integration, Ruby has proven itself to be the right answer with Rails.

Going back to GitLab itself, when co-founder Dmitriy Zaporozhets decided to develop his own version control server software, he also had a background in PHP development, but instead of sticking to his familiar approach, he chose Rails.

In this regard, Sid Sijbrandij (GitLab co-founder & current CEO) affirmed: Dmitry’s judgment was prescient (and perhaps accidental), but in any case, GitLab has developed well because of it. Part of the reason here can be attributed to Rails finding a balance between well-architected and approachable.

“We don’t need microservices”

In his 1971 article “On Standards to Follow When Decomposing Systems into Modules,” David L. Parnas summarizes the advantages of modular systems as follows:

• It is expected to “reduce development time as separate groups can work on each module with little communication between each other.”

• Expect “significant changes or improvements to a single module without affecting other modules.”

• Expect to learn only one module in the system at a time.

Fred Brooks also emphasized the importance of reducing communication needs in his later “Myth of Man-Month”, arguing that additional communication overhead is one of the main reasons why “adding manpower later in the project will further slow down the progress of the project”.

Sid Sijbrandij believes that modularity, while highly sought after, is often mysterious. As a result, designers can only draw inspiration from the largest software system in the world today – the World Wide Web. Considering the fundamental nature of the World Wide Web, it can only choose a modular construction.

Organizing the local software system using separate processes and composing the microservices together using the REST architectural style really helps enforce module boundaries through the operating system. Although this is an effective and strictly modular implementation, the corresponding cost is also quite heavy.

Sid Sijbrandij further said that distributed systems are currently facing similar implementation challenges and high costs, and people have been slow to find an effective way to ensure performance and reliability in distributed computing.

“In short, in order to ensure performance and reliability, we can only replace function calls that are measured in nanoseconds and never fail with network calls that are measured in milliseconds or even seconds and can fail at any time. .And we often need to trace across multiple services with little to no tooling support, making troubleshooting more difficult. Only a fairly mature DevOps organization can successfully run a microservices architecture. Anyway, let’s be clear – —We are not Google, we may not be able to handle such a complex large-scale operation system.”

And even if it can be managed, there is another question to pay attention to: whether the complexity of the architecture itself has exceeded the original complexity of the problem itself. Microservices don’t reduce complexity, so imagined modular improvements may end up in a mess that will never be sorted out.

Modular Monolithic Architecture

With good architecture, approachability, and efficient operation, Rails helped GitLab develop a modular monolithic architecture. A modular monolith is the exact opposite of a distributed architecture: it emphasizes that programs should have good structure, architecture, and a higher level of modularity, where each process runs stably and is kept as simple as possible.

Sid Sijbrandij said that while building GitLab as a monolith would best meet the project’s expectations, it must not be too dogmatic about specific structural trade-offs. In short, architecture should serve requirements, not requirements serving architecture.

While Rails does help GitLab achieve its goals effectively, it also has some drawbacks, especially when it comes to performance. Fortunately, only a tiny fraction of most of GitLab’s codebase is performance-conscious. “So we wrote our own gitaly daemon in Go to handle the actual git operations, and PostgreSQL for non-repo persistent data,” admits Sid Sijbrandij.

Sid Sijbrandij said the modular monolithic architecture really transformed GitLab’s “Open Core” business model from theory to reality. Even though Rails alone doesn’t make it happen, it’s the amazing contributors and engineers who do it, Rails sets the stage for these successes.

The Cathedral and the Bazaar, the “bible” of the open source movement, states that in order to realize the true benefits of open source, contributors must have ready access to the source code. On the other hand, in order to receive various contributions while maintaining architectural integrity, it is necessary to draw a clear demarcation line between open and closed components, and ensure that the code is well-structured.

In this way, some people may want to ask, why didn’t GitLab develop a suitable plug-in interface? Or simply build a service interface based on microservices? To these kinds of questions, Sid Sijbrandij’s answer is adamant: no need. Because these methods will not only significantly increase the difficulty of implementing minor changes to the source code at the deployment and integration level, but also bring too strict architectural implementation constraints. “Who can predict all possible expansion points in the future? It’s impossible, and we don’t plan to trouble ourselves with this at all.”

“With these boring modular monoliths, users and other third-party developers alike can contribute to the core product and help the community amass a huge impact, while maintaining unparalleled innovation speed and scalability.” Perhaps in GitLab’s view, sometimes, the plain is the truth.

The text and pictures in this article are from InfoQ