SaaS 正在 Rails 化
作者 | Keith Horwood
译者 | 弯月
以下为译文：
我喜欢思考计算机的发展前景。我和我的小团队经营着一家名为 Autocode 的公司，该公司成立于2020年7月。我们关注的商机之一就是所谓的“ SaaS 的 Rails 化”，我相信它将成为接下来的十年中，软件的开发以及购买方式的主要推动力。我希望通过本文总结一下我的想法，而且我认为了解一些软件开发的历史，对于预测未来的发展非常重要。
自1989年万维网问世以来，每隔十年，构建与交付 Web 软件的方式就会发生一次重大转变。1990～2000年间，我们看到了 Web 开发的大规模工业化，人们纷纷使用了 PHP 和 Apache HTTP Server 。2000～2010年间，软件包管理与框架的采用，比如 RubyGems、Ruby on Rails 、PyPI 以及 Django ，大幅降低了软件开发的难度。2010～2020年间，我们看到了云强势袭来：Docker 、编排服务环境 Kubernetes 的诞生，AWS Lambda 引入了零运维、事件驱动以及按需计算，让分布式与可扩展计算变得触手可及。
我相信，在接下来的十年中，我们可能会看到的一些转变得益于我们从之前的三十年中汲取的经验。简而言之，“SaaS的Rails化”指的是开发、软件包管理与云计算在商业 SaaS 生态系统中的应用。这将成为 SaaS 产品及其 API 之间以及整个 Web 编程环境之间标准的交互方式。
过去：Rails 的 SaaS 化
在深入探讨“ SaaS的Rails 化”之前，我认为我们应该先来谈一谈已经发生的事情，即 Rails 的 SaaS 化。从2000年末到2010年初，一些有抱负的企业家开始注意到，虽然 Ruby on Rails 生态系统非常出色，但开发人员仍然面临着许多可怕的难题。建立一个在线商店非常困难。在应用中添加付款需要银行卡，而且还需要通过合规性检查。添加短信更加是几乎不可能。
Shopify 等公司借鉴了 Ruby on Rails 生态系统的概念，提供了有效的互联网零售模块。只需单击一个按钮，即可开新店，出售产品。此外，你也可以通过代码和模型自定义店铺。尽管在这种情况下通常我们都不会想到 Stripe 和 Twilio ，但二者确实在 RubyGems ，PyPI 和 NPM 生态系统领域的大规模变现方面取得了成功：“安装这个 gem ，你出钱，我们来干活。”
Ruby on Rails 生态系统涌现的这些创新为在线商务开辟了一个全新的领域。这种 SaaS of Rails 是与 API 经济概念并行运行的现象，二者的共同之处在于，包管理生态系统是 API 主要的分发和集成点。
未来：SaaS 的 Rails 化
如今第三方 SaaS API 无处不在，部分归功于 Rails 的 SaaS 现象。为了构建完整的商业产品或者是附带项目，开发人员的工作可能不再是启动开发环境、下载软件并开始编写代码。如今的构建可能根本不是从代码入手，也许他们是从 Airtable 中的结构化数据着手的。也许他们想通过 Shopify 创办自己的在线业务。即便从代码着手，用户可能很快就会发现，他们需要通过 Stripe 添加付款。接着，他们还需要确保自己的软件可以将消息发送到通信渠道，例如 Slack 或 Discord 等。再或者他们需要使用 Auth0 在应用中添加身份认证的功能。
Rails 的 SaaS 化指的是已经发生过的事情：软件包的大规模商业化，而 SaaS 的 Rails 化指的是即将发生的事情：虽然 SaaS 的复杂度日益加剧，但我们可以通过重新集成和简化，将其变成标准、简单、可共享的组件和软件包。虽然我无法完全预估这种变革会带来什么影响，但我可以列举一些已初现端倪的变化。
首先，“软件开发人员”的定义已经开始改变， SaaS 应用的整合也越来越容易了。在九十年代， PHP 开发人员没有学历会遭人耻笑，但如今他们中的许多人都成为了千万富翁。接下来十年中出现的工具，在21世纪二十年代或三十年代也将有相同的经历。
其次，应用开发的创新领域正在呈指数增加。硅谷的投资人称之为“无代码”或“低代码”运动，但说到底我们还是离不开代码，因为只有代码才是最根本的实现和测试媒体。Zapier 集成无法共享，但你可以随意复制粘贴一小段 JavaScript 、 Ruby 或 Python 代码，并在其他地方运行。接下来十年的赢家将不止一家公司、一个框架或一款软件。
第三，构建 SaaS API 的 RubyGems 是一个良机。只要尝试过在 Stripe 或 Twilio 基础上构建 API ，你就会意识到， SaaS 集成非常糟糕。虽然有一些机器可读的 API 标准（如 OpenAPI 等），但这些标准只能解决一部分问题，而且很多人都不遵循这些标准。Discord 的 API 建立在有状态套接字连接上，而 Slack 的 API 基本上是无状态的 HTTP API 。Stripe 基本上就是采用了一个 OpenAPI 同等的规格，而 Shopify 是非标准的 REST ，又在其上加了一层 GraphQL API 。任何生态环境中的身份认证都需要完全不同的操作。
我之前提到过，“SaaS的Rails化”是我们考虑的主要方面。我们对构建“ SaaS 的 RubyGems ”尤其感兴趣，我们的使命就是提高人们编写代码的效率。我们要降低 Web 编程的难度。
简而言之，我们目标是降低发布代码、集成 SaaS 应用的难度。现如今我们只是一个小团队，只有4名成员，但我们构建了一个基于 Web 的 IDE 、运行时、合作平台，以及一个发布平台，可用于发布无状态、自动伸缩、长期运行的 Web 应用程序。甚至还可以在保存项目的时候自动设置 webhooks 。我们还开发了 CLI 和本地开发工具，供不想使用 Web IDE 的人使用。目前，用户只能通过 Node.js 构建和添加我们的标准库，但以后会支持更多语言。
有人认为我们的产品是“低代码”工具，但实际上我们是“全代码”工具。我们只是简化了认证和 API 管理。很幸运的是，我们得到了 Slack 、 Stripe 的支持，以及 GitHub 、 New Relic 、 Airtable 和 Shopify 的推荐。
其他选择？
我认为在未来十年内，“ SaaS 的 Rails 化”只是可能出现的转变之一。许多公司都在为计算的创新发展而努力。我们应该参考一些分布式计算和计算前端领域的成功案例。
Retool 等公司引领了前端应用的开发，他们为可视化开发提供了更好的组建管理和抽象。作为一名开发人员，这些公司让我想起了另一个更加专注于商业的框架：Ionic。Retool 吸取了许多过去十年的创新（即 React 生态环境），他们构建了一个更有效、更流畅的 Web 可视化开发工具。
另一方面， Repl.it 等公司在努力研究分布式计算技术，希望将来任何人都可以发布任何形式的软件。尽管这些工具在教育和学生中间非常流行，但该团队的野心非常大，他们计划让新一代的开发人员能够运行任何类型的服务器，同时又不需要担心如何设置 Python 和可执行文件。
上述这两家公司的发展非常快，而且他们都在考虑开发的发展前景。但他们只代表了冰山的一角。未来十年，开发工具将为软件开发带来全新的局面。而我们认为整个互联网就是一个可编程的接口。我们希望能够在这些新兴公司中找到自己的一席之地，但作为开发人员，你应该考虑一下你能够做出什么样的工具。毕竟，创新才是王道。
路漫漫兮其修远，让我们共同努力。
原文链接：https://keithwhor.medium.com/the-railsification-of-saas-e5d284fa44a1
声明：本文为 CSDN 翻译，转载请注明来源。