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/
推荐阅读
- 未来革命性的五大核心技术，中国目前处于什么水平？
- Beyond重映演唱会1.4亿人背后：云平台视听修复技术正在升级
- 计算机应用技术就业方向有哪些？
- 纳米技术在生活中的运用有哪些？
- 中长跑的技术要求是什么？
- 医学检验技术是干嘛的？
- 纳米技术运用在哪些方面？
- 纳米技术有哪些用途？
- 黑木耳的培植方法,黑木耳的种植技术-
- 社会有哪些手艺可以学,当下社会学什么技术手艺好-