这个介绍有四个部分。

首先我们将介绍 Rapid.Space, 它的创办人和创办的目标。

然后，我们将介绍 Rapid.Space 当前的架构和规模。

接下来，我们将介绍 Rapid.Space 与其他云解决方案相比较下的优势。

在第四部分，我们将介绍 Rapid.Space 如何协助软件开发者创建一个 SaaS 的平台。

最后我们提出了一个为期三个月的实施计划，即从现有的软件构建 SaaS 平台。

Rapid.Space 对您来说也许是一个全新的名字，我们将在这里介绍我们是谁以及我们的目标。

Rapid.Space 的目标是通过完全可逆性提供掌控权和信任。此目标提供了如华为，Palantir 或 AWS 之类的公司由于 IP 和法律政策相结合而无法提供的东西。

该目标适用于 Rapid.Space 定位的任何类型业务。

Rapid.Space 已经提供了可用于公共或私有云的可逆云平台。 该平台的所有组件都是开源的，包括硬件，这意味着任何客户都可以在其内部“克隆”该平台或请求第三方在无 License 费用的情况下运行该平台。

Rapid.Space 打算提供与 Palantir 类似规模的可逆大数据平台。 该平台的所有组件都是开源的，包括硬件，这意味着任何客户都可以在其内部“克隆”该平台或请求第三方在无 License 费用的情况下来运营该平台。

Rapid.Space 打算提供一个可逆的边缘计算平台，其中包括工业 4.0 所需的一切，包括 PLC，传感器，执行器。 同样，所有组件都是开源的。

Rapid.Space 打算提供一个可逆的 RAN 平台，该平台支持 4G / 5G，可用于私有和公共网络。 大多数组件都是开源的。 某些组件可能是获得许可的来源，这意味着任何客户都可以在内部"克隆"该平台并以一定的许可费用审计其源代码。

Rapid.Space 中除 VRAN 之外的所有东西都是开源的：软件（SlapOS），硬件（OCP）和业务流程。 VRAN 是基于许可的源堆栈，最终也可能会开源。

 Rapid.Space 手册 介绍了构建 Rapid.Space 节点并作为公共云或私有云运营的各个方面的资料。 与通常将操作流程保密的任何其他云提供商相比，这是一个主要区别。

Rapid.Space 是专为提供客户掌控权而设计。

Rapid.Space 的服务器由各个国家的企业所拥有，无任何资本关联。

因此，拥有 Rapid.Space 服务器的一家公司不可能"监视"另一家 Rapid.Space 服务器。 即使当地法律规定了这种可能，也只能允许该国政府"监视"位于自己国家的服务器。 但是，在 Rapid.Space 的情况下，A 国的政府无法监视 B 国的服务器，因为没有资本关系的公司无法互相命令。

负责协调全球所有服务器的 Rapid.Space 公司也无法访问用作服务器凭据的密码或证书。 这种方法有时被称为“零知识证明”。 无论何时使用 Rapid.Space 集中管理平台，都无法访问其他国家/地区的服务器或用户信息。

Rapid.Space 的基础架构正在不断增长。目前在欧洲和亚洲都有部署，很快美国也将开始进行部署。

根据早期评估，亚马逊 AWS 提供的85％的云服务实际上可以通过快速，低成本，高性能的云以及像SlapOS（75％的服务）和一些第三方免费软件（10％的服务）等各种开源堆栈实现 。

Rapid.Space 价格便宜，可确保在全球范围内提供服务（包括在中国），是完全可逆的（客户可以轻松退出 Rapid.Space），并且对开源技术开放并提供各种贡献。 这就是“超级开放”的优势。

Rapid.Space 的所有成本都是公开的，并在“Business Model of a Low Cost Cloud Operator”一文中进行了描述。 Rapid.Space 的价格基于电力，地产，硬件摊销，网络，运营管理成本（软件，人力），硬件维护，财务成本。 另添加了20％的保证金，以覆盖与云服务运营相关的所有其他风险。

除了现有的70多个服务，任何人都可以为 Rapid.Space 贡献自己的服务。

只要遵守 Rapid.Space 标准和流程，任何人都可以贡献服务器和数据中心来扩展 Rapid.Space 的全球覆盖范围。

Rapid.Space 也可以采用混合云的典型方式在本地部署。

像 Teralab 一样，任何人或企业都有可能运营一个完全私有的基础设施。

甚至可以在第三方公共或私有云（AWS，OVH，Azure，Alicloud，Hertzner，华为，VMWare 等）上部署 Rapid.Space 服务，并从所有 Rapid.Space 服务中受益，包括其 IPv6 骨干网络，CDN ，IaaS，PaaS 等。

基本上，Rapid.Space 中没有阻止程序，没有秘密，没有任何反竞争行为。

目前，欧洲的云价格最便宜。 与欧洲品牌相比，Rapid.Space 仅便宜30％至60％。

美国和中国的价格最昂贵。 Rapid.Space 比美国或中国品牌便宜2至20倍。

现在让我们讨论 Rapid.Space 如何帮助企业成为 SaaS 提供者。

现在，我们将通过3个月的实施计划来说明如何将现有软件转换为 SaaS。

第一个月包括创建一个结合了 OM（SlapOS 主服务器）和 devops（构建）的 POC。 第一个月以展示 demo 结束。

根据 demo，制定后续计划，最快在2个月内实现最简可行产品（MVP）。

一个团队完成 devops 脚本的定稿。 另一个团队完成专用的 OM 平台。

POC 的目标是在尽可能短的时间内演示整个系统。 这意味着将考虑最短的路线并简化整个系统。

将部署标准 SlapOS master 服务器，并为其配置示例主页，示例注册表单。 一个示例 SlapOS node 将部署在 Rapid.Space 上。

最难的工作是使用 buildout 语言编写第一个软件版本（SR）。 不严格需要的所有东西都将被消除：负载平衡器，高可用性等。这里的目标是创建 SR 的“单片”版本，该 SR 可以自动开通“多合一”系统。

在 POC 的最后，可以演示完整的订单和操作流程：订阅，付款，服务开通，访问，控制台，监测，支持，开票。

然后向开发人员介绍 buildout 语言和 WebRunner 环境。 我们会解释 buildout 文件是如何编写的，以及我们每天如何对其进行测试：集成测试，部署测试。

SlapOS 中的一个关键概念是封装：相同的配置文件定义了如何构建，部署，开通，监测，记帐......和测试。

根据 POC1 的结果，我们定义了2个月的延期以实现最小可行产品（MVP）。 这个词的大部分内容包括使用额外的组件来扩展SR，实施灾难恢复，高可用性，改善监测，实施作为计费基础的资源核算，扩展部署测试，封装集成测试并确保所有代码（源代码和二进制代码） 缓存良好。

完成所有这一切可能需要2个月到1年的时间，具体取决于预期的自动化程度和难度。 这就是为什么我们建议专注于2个月计划和 MVP 的原因。 否则，它可能会一直持续下去。

在 SlapOS Master（OM）上，我们只需要完成网站（FAQ，HowTo，公司信息，产品信息），实施计费规则并确保电子邮件对用户来说足够清晰。

MVP 完成后，可以开始考虑下一步。 由于适当的监控取决于商业部署的实际经验，因此肯定需要扩展现有的 buildout 文件。 需要为新服务创建新的 buildout 文件。 OM 平台可能会获得与营销或用户支持自动化相关的额外功能。

许多尝试构建 SaaS 的公司因为许多不同原因而失败：

• 他们忘记了 OM 平台的主要角色，无法自动化操作；
• 他们使用太多“Best-of-Breed（BoB）”工具，从而导致无法稳定集成；
• 他们使用不稳定的云平台，例如......;
• 缺乏解决网络拥堵的弹性网络；
• 他们尝试做太多。

Rapid.Space 可以协助降低除最后一条以外的大多数风险。 如果尝试做太多事情，项目有很大可能失败。

这其中最大的难点是：弹性（自动灾难恢复）和高可用性。 与其尝试一次性全部解决这些问题，不如一步一步来，找到最初可能并不完善但最终是最稳定解决方案，然后再将它们扩展到完美。

首先，请确保每天进行可靠的备份和还原测试。

然后，实施初始功能以实现高可用性。 在大多数现代系统中，高可用性是在应用程序级别而不是系统级别实现的。 它可以通过复制数据库（SQL 或 NoSQL），通过在不同节点上多次部署相同服务，使用负载均衡器等来实现该功能等。

始终记得，现场的完美总是会碰到 Linux 内核的不完善之处，并且每次 Linux 内核升级时都可能需要中断服务器和服务。

这个为期3个月的计划的目标之一是降低对第一个 MVP 的过高期望，并确保可以在该时间范围内将稳定的服务作为 SaaS 进行商业化。 POC 的目的是检查软件的当前状态，并定义接下来两个月的方向。 通常两个月就足够了。 但是，如果某些软件极其复杂，则可能需要更多时间首先简化该软件（最佳解决方案）或编写非常复杂的 devops 脚本（风险最高）。