省流版

SaaS 还是 On-Premise（私有化） 之争随着云技术的发展，已经有了两全的解决方案：BYOC（Bring your own cloud）。

借助 BYOC（Bring your own cloud） 能力，企业可以将 SaaS 无人值守地运行在自己的 VPC（虚拟私有云） 里，同时兼顾数据安全和维护成本。无论你想选择一个完全数据自我控制的数仓还是你有一个打算通过 BYOC 部署给用户的软件需要一个数仓作为底层数据分析引擎， ClapDB 都是你最好的选择。

正文

在过去数十年里，国际或国内企业级软件行业头上始终悬着一把私有化部署之剑，就是On-Premise（私有化）部署，稍具规模的甲方往往希望乙方能够提供私有化部署的版本。但是大部分新兴企业级软件厂商都倾向于 SaaS 的方式交付软件。事实上，大家都不是傻子，甲方乙方都有自己的算盘。

甲方的担忧

我国有数据安全法，欧洲有 GDPR，美国有 HIPPA，各国对数据主权都有关于数据主权的规定，并且我国的某些行业，比如金融，医疗，都有更细致的数据安全要求。以及对于重要数据的 SaaS 化，甲方一般都心存疑虑（这个疑虑并非没有根据）。但是私有化往往需要较贵的成本（服务器+TCO）。

乙方的困境

SaaS 有利于保持产品版本的一致性，多版本下的软件质量很难得到保障。SaaS 也方便降低用户的上手难度，提高获客效率。

而且现代 SaaS 软件都是分布式程序，里面还依赖了很多复杂的中间件，往往需要专业的运维人员专门维护。而且SaaS 软件往往迭代很快，如果给用户更新的最新版是个颇为成本高昂的工作。这些都让甲方胜任是一件非常困难的事情，而且很难产生额外的收入。

乙方是草台班子么？

国内乙方存在大量的外包项目的产品化，还有相当比例的从互联网公司出来的技术团队。这两波人对于数据安全其实都不敏感。毕竟即使是最大的互联网公司 Facebook（现在改名 Meta）， Linkedin 都泄露了大量用户隐私数据。互联网公司因为长期监管减弱，并且野蛮生长，所以其实对数据安全问题并不敏感，也几乎没有工程实践方面的经验。而且乙方往往还依赖了大量的开源软件（这里暂且不讨论开源软件直接给用户部署的版权和法律问题）。所以从某种角度来说，小创业公司的数据安全工作很有可能是很“草台班子”的现状。因为大部分数据都在一些开源中间件里，特别是这些中间件几乎还都处于多租户共享使用的状态中。

多租户为什么不靠谱

大部分开源软件（mysql、elastic search、nginx、kafka）根本没有为多租户功能提供足够好的支持，所以这些基于开源软件的 SaaS 企业，大多数都简单的粗暴的在业务层实现多租户功能，没有对不同租户的数据和访问进行有效的权限隔离，更别说进行资源隔离了。

SaaS 的鼻祖 Salesforce 也长期让几万客户跑在同一个 Oracle 集群上，用一列 tenant id 在检索和更新的时候进行区分。

几乎所有的利用多租户方案的用户，用的都是这种不严谨的技术 trick，都很难叫技术的一种方案。因为它具有以下问题：

1. 资源并不会隔离，多租户会竞争资源，比如 cpu，memory，io，甚至还有锁。一个 noisy neighbor 可以拖垮整个系统。

2. 系统本身的权限管理非常粗放，一个用户名密码就能拿到所有租户的数据。

3. 研发规范也很粗放，到处的日志，dump，甚至监控工具都会泄露用户数据。

4. 他们对于数据的方案根本不能保证可审计，无法保证是否有内部研发或者运维工程师出于某种目的在管理层不知情的情况下非法获取用户数据。

甲方的无力感

因为对乙方情况的不确定性，甲方被迫要求乙方私有化部署到自己的云上或者 IDC 里。但是因为系统的运维是半自动的，所以甲方要接手这种软件的运维难度相当高，特别是当软件升级的时候，甲方往往会陷入系统停摆的状态。

如果甲方有专职的工程师负责运维这些企业级 SaaS 或者其他软件，往往也会面临一些原厂都没有面对的问题，因为甲方可能有更复杂的网络环境，不同的硬件，不同的访问习惯等等。

总之，甲乙双方都会感觉遇到了困难，钱没少花，效果还不太好。

Bring your own cloud

基于云计算的 BYOC（Bring your own cloud）技术是解决此类问题的一个新疗法。

BYOC 可以利用云的标准化，为每个用户单独部署一整套 fully-managed 软件。

我们先来看看它成立的前提：

1. 云提供了足够好的隔离性，无论是资源还是访问安全。

2. 云提供了相对标准化的基础环境，无论是网络还是服务器类型，都有办法保证在所有甲方处部署的资源都是保持一致，避免兼容性问题。

3. 云提供了大量全托管的高可用基础服务，可以不依赖人工运维来实现 HA 和 durability。

BYOC 能做到什么

1. 将数据存储于企业的自有云账户中，提供更好的数据安全和数据主权。

2. 不再需要通过多租户模式和别的用户共享存储和计算，以及泄露数据的风险。

BYOC 要做哪些适配

并不是任何软件都可以通过 BYOC 来进行部署，如果架构过于复杂，有多重依赖的服务存在，或者依赖了极难运维分布式服务。都会让 BYOC 极难实现，例如大部分传统软件的 k8s operator 并不能真的保证这些软件顺畅地运行在 k8s 上。在  云是一台新电脑^[1] 里我们讨论过，要把云看做一台计算机。要做针对云的架构改造和优化才能方便进行 BYOC 能力的实现。

BYOC 带来的问题

BYOC 虽然是 fully-managed service，但是一旦遇到问题，软件开发商来进行调试的时候会比较麻烦，所以要有更好的 log 输出和调试功能支持。

BYOC 业界已经有案例了么？

有，基础软件领域已经有好几个不错的玩家了

1. Databricks

2. StarTree

3. Redpanda

4. StreamNative

以上软件，特别是 databricks，作为世界知名的数据仓库厂商，已经通过 BYOC 为客户提供了全新的产品体验并且获得了市场的认可。

以上的例子可以看出，基础软件往往是用户整个系统的基础，所以跨公网或者 vpc 访问的安全性和延迟往往是用户无法接受的，有的时候 BYOC 才能真的击中用户的痛点，解决用户的数据安全诉求。

ClapDB 如何做 BYOC

ClapDB 遵循 云优先架构^[2] 一文里提到的云优先架构。在恕我直言，你的业务不配用服务器^[3] 一文里我们讨论了 serverless 技术的先进之处，通过简化架构，ClapDB^[4] 可以 all in serverless 技术。可以直接使用 IaC^[5] 技术全自动部署和更新整个系统。

下面这行命令绝对是你见过的最干净利落的数据库部署方式。

clapctl deploy -n your_cluster_name

当然如何安装 clapctl 以及如何配置你的 credential，请详见 ClapDB Getting Started^[6]。

无论你试图拥有一个拥有完整数据主权的云上数据仓库，还是你打算将你的产品用 BYOC 的方式部署给你的用户，但是你需要一个也支持 BYOC 的数据分析引擎。ClapDB 都是你的最佳合作伙伴。

参考资料