关于过气网红编程措辞 Ruby，我们此前曾发过一篇文章去回顾其大受追捧的过往，并谈论了它每况愈下的生存状态。不过人气并不能直接解释措辞质量差，一方面 Ruby on Rails（用 Ruby 写的开源 Web 运用程序框架）仍是实现原型设计演示的好方法，能帮助开拓者在几天之内更稳妥地构建起最小可行性产品，另一方面，市场对付 Rails 和 Ruby 开拓者还是存在刚性需求。
近期，GitLab 就发布了一篇文章阐述它们坚持利用 Ruby on Rails 的缘故原由。环球有许多盛行网站都是基于 Rails 构建的，只管本日 Rails 有日落西山之势，但技能选型还得图个“得当”。从 GitLab 的角度看，他们本身没有繁芜的运行体系，也不须要用微做事，在这样的情形下，Ruby on Rails 对他们而言反而是最佳选择。
2004 年 7 月，Rails 的创始人 David Heinemeier Hansson 从 37signals 公司的项目管理工具 Basecamp 分离出 Ruby on Rails，并且以开源办法发布。
David 曾在一个采访中回顾他创造 Ruby on Rails 的心途经程，个中最大的影响来自他利用 PHP 与 Java 的深度履历。一方面，他不喜好 Java 那种冗长、僵化、导致 Java Web 框架既繁芜又难以利用的设计办法，但他讴歌 Java 良好的构造完全性。另一方面，他喜好 PHP 易于上手的友好特性，但也创造 PHP 过于混乱，难以供应顺畅的项目开拓轨道。
当时的情形便是，必须在两种都不足好的方案中做选择：要么是易于上手却混乱不堪，要么是构造良好却难以利用。这种困境不禁让人遐想起做事器级操作系统（例如稳定却难以利用的 Unix）和客户端操作系统（例如简便易懂却常常崩溃的 Windows 和 MacOS）间的经典难题。
当初大家都以为现实便是这样残酷，只能陷入二选一的困难决议。但后来 NeXT 在 Unix 的坚实根本之上却开拓出一套俊秀、易用且流畅的 GUI。如今，“做事器级”Unix 不仅能够运行起俊秀的 GUI 桌面，乃至还能搭载在大部分手机、智好手表当中。
以是事实证明，易用性和稳定性之间并不是非此即彼的关系。Web 框架中的易用性和混乱性也是如此——明明是两条并行的车道，为啥非得纠缠在一起？
以是，David 看到的一个空想的平衡点是：既民平易近、又构造良好的 Web 框架。凭借其踏实、支持元编程的 Samlltalk 特性，再加上良好的 Unix 集成效果，Ruby 证明了自己完备可以在合营 Rails 之后成为那个精确答案。
回到 GitLab 本身，当联合创始人 Dmitriy Zaporozhets 在决定开拓自己的版本掌握做事器软件的时候，他实在也是 PHP 开拓背景，但他没有坚持自己熟习的方法，而是选择了 Rails。
对此，Sid Sijbrandij（GitLab 联合创始人 &现任 CEO）表示了肯定：Dmitry 的判断是有先见之明（或许也有有时性），但不管怎么说，GitLab 也因此发展得不错。这里的部分缘故原由可归功于 Rails 在良好架构与民平易近之间找到了平衡。
“我们不须要微做事”在 1971 年揭橥的文章《关于将系统分解为模块时，所应遵照的标准》中，David L. Parnas 将模块化系统的上风总结如下：
有望“缩短开拓韶光，由于各独立小组可以在每个模块上事情，彼此之间险些不须要沟通。”有望“对单一模块做出重大变更或改进，且不影响其他模块。”有望每次只学习系统中的一个模块。
Fred Brooks 在后来的《人月神话》中也强调了减少沟通需求的主要意义，认为额外的沟通开销正是“在项目后期再增加人手，反而会进一步拖慢项目进度”的紧张缘故原由之一。
Sid Sijbrandij 认为，模块化虽然受到高度追捧，但也每每神秘莫测。因此，设计师们只能从当现代界上规模最大的软件系统中汲取灵感——万维网。考虑到万维网的基本特性，它只能选择模块化构建办法。
利用独立的进程组织本地软件系统，再利用 REST 架构风格将各微做事组合起来，这样确实有助于通过操作系统逼迫划定模块边界。虽然这是种行之有效的严格模块化实现办法，但对应的本钱也相称沉重。
Sid Sijbrandij 进一步说道，目前分布式系统也面临着类似的实现寻衅与高昂本钱，人们迟迟找不到在分布式打算中保障性能与可靠性的有效方法。
“简而言之，为了担保性能与可靠性，我们只能把原来以纳秒为衡量单位、且永不失落败的函数调用，更换成以毫秒乃至秒为衡量单位、而且随时可能失落败的网络调用。而且我们常常须要在险些没有工具支持的情形下，跨多项做事开展跟踪，于是故障诊断变得更加困难。只有相称成熟的 DevOps 组织才能成功运行起微做事架构。总之，请大家明确一点——我们不是谷歌，我们可能搞不定那么繁芜的大规模运行体系。”
而且纵然是真能管理起来，还有另一个问题要把稳：架构本身的繁芜度，是不是已经超出了问题本身的原始繁芜度。微做事并不能降落繁芜性，以是想象中的模块化改进终极带来的很可能只是一团永久理不清头绪的乱麻。
模块化单体架构凭借着良好架构加民平易近、再加高效操作，Rails 帮助 GitLab 开拓出了模块化单体架构。模块化单体与分布式架构完备相反：它强调程序该当具有良好的构造、架构以及更高的模块化水平，个中每个进程都能稳定运行且尽可能保持大略。
Sid Sijbrandij 表示，虽然将 GitLab 构建成单体最符合项目预期，但对付详细构造取舍也绝不能太过教条。总之，架构要为需求做事，而非需求为架构做事。
虽然 Rails 确实能帮助 GitLab 有效达成目标，但它也有一些缺陷，特殊是在性能方面。所幸的是，GitLab 大多数代码库中只有极小一部分须要重视性能。“以是我们用 Go 自己编写了 gitaly 守护进程以处理实际 git 操作，并利用 PostgreSQL 处理非 repo 持久性数据。”Sid Sijbrandij 坦言道。
Sid Sijbrandij 表示，模块化单体架构把 GitLab 的“核心开放”（Open Core）商业模式从理论真正转化为现实。只管 Rails 本身并不能实现这一点，这是那些出色的贡献者和工程师们完成的，但 Rails 还是为这些成功奠定了根本。
开源运动的“圣经”《大教堂与集市》里提到，为了发挥开源的真正上风，贡献者必须能够随时访问源代码。另一方面，为了在吸收各种贡献的同时保持架构完全性，就须要在开放组件和封闭组件之间划开定清晰的分边界、担保代码构造良好。
如此一来，有些人可能会想问，GitLab 为什么不开拓一套得当的插件接口呢？或者干脆建立基于微做事的做事接口？对付这类问题，Sid Sijbrandij 的回答是武断的：没必要。由于这些方法不仅会在支配和集成层面，显著提升源代码轻微改动的实现难度，同时也会带来过于严格的架构履行约束。“谁能预测出未来统统可能的扩展点？根本不可能，我们也压根不打算给自己找这个麻烦。”
“凭借着这些无聊的模块化单体，用户及其他第三方开拓商一样能为核心产品做出贡献、并帮助社区积累起巨大的影响力，同时保持着无与伦比的创新速率与可扩展性。”或许在 GitLab 看来，有时候，平平淡淡才是真。
参考链接：
https://about.gitlab.com/blog/2022/07/06/why-were-sticking-with-ruby-on-rails/
https://corecursive.com/045-david-heinemeier-hansson-software-contrarian/
