无服务计算，厂商究竟在打什么算盘
一说到无服务计算（Serverless computing），很多人脑海中马上浮现出几个熟悉且令人兴奋的词汇：“瞬间启动”、“弹性扩缩容”和“按量计费”等等。如今，随着公有云的普及，几乎每过一段时间我们都会听到有新的无服务计算产品问世。同时，许多知名的云服务产品，如 AWS Aurora、AWS Redshift、Databricks 等，都陆续推出了它们的无服务版本。一时间，无服务计算迅速成为了行业内的焦点，无论是创业公司还是大型厂商，都在探索推出无服务产品的可能性，甚至在近期备受瞩目的大模型领域，也涌现出了许多关于无服务机器学习平台的讨论。
无疑，无服务计算的理念极具魅力。它所推崇的特性精准的抓住了用户的痛点。毕竟，几乎没有哪家公司愿意花费过多精力来管理运维，也没有哪家公司希望为基础服务支付过高的费用。当然，仅仅有个好的理念还不够。对于任何一个产品来说，是否能真正得到广泛的采纳和实施，最终还是取决于它是否能满足买家与卖家双方的利益需求。
在本文，我将从商业和技术的角度来深入探讨无服务技术，希望给大家带来更全面的认识。
尽管云计算这一概念已经深入人心，但并不是所有公司都愿意拥抱云服务。由于各种各样的原因，不同公司对使用云服务都有自己的看法，并且有不少公司因为监管、风控等要求，根本就无法接入云平台，更不用说使用云服务。在具体谈论无服务计算之前，我们先聊聊市面上的软件服务种类。
我们先从私有化部署模式开始讲起。私有化部署即指客户将软件服务直接部署在自己的服务器或数据中心上。在这种部署方式中，企业对自己的数据以及软件服务拥有 100% 的完全控制权。这为企业提供了高度的数据安全性保证。当然，自己可以掌控数据安全，也就意味着自己同样也需要对自己的安全负责。私有化部署模式的缺陷也很明显，即部署与运维成本相当高。企业不但需要购买大量的服务器，而且还要琢磨如何在自己的服务器上安装想要的软件。一旦出现故障或需要升级，企业可能需要与供应商进行频繁的沟通，甚至可能需要供应商的现场支持。
在全托管模式中，数据面板与控制面板均在公网中；在 BYOC 模式中，数据面板在用户的云网络环境下，而控制面板在公网中。
云的出现便是为了解决私有化部署的痛点。在云上，大家默认使用的模式便是云上全托管模式，或者被称为公有 SaaS。云上全托管意味着客户使用供应商在公有云上提供的软件服务。在这种情况中，企业所使用的软件以及自己的数据都会被放在云端。这种模式将企业对软件运维的压力几乎降为 0，但这也意味着企业可能面临一系列安全和隐私问题。毕竟，由于软件厂商对软件具有管理的权利，从理论来说（尽管实际上几乎不可能发生）厂商可以访问到用户的数据，万一出现数据泄漏等情况，后果不堪设想。
为了解决企业对全托管模式在安全方面的顾虑，不少厂商开始推出私有 SaaS，也就是 BYOC，即 Bring Your Own Cloud 模式。从字面意思来看，可能有些难以理解。但简单来说，大家可以将其想像成让企业在云时代实现私有部署的方式。BYOC 模式要求客户企业已经拥有某个云服务提供商（比如 AWS、GCP 等）的账户，而软件系统厂商会将软件部署在客户企业的云账户下。这样一来， 数据的所有权完全由企业所掌握，而厂商仅拥有客户系统的管控平台的访问。这样一来，厂商访问数据的权限被限制到最小，从而大幅降低了数据泄漏的风险。当然，BYOC 模式对于厂商来说在运维方面提出了不少要求。在这里我们就不展开讨论。
最后一种模式便是我们今天要着重讨论的话题，即 Serverless，或称无服务。无服务可以被认为是全托管模式的进一步延伸。在这种模式下，所有的服务都由供应商在云上部署，而客户仅仅是使用这些服务，无需关心后台的运维工作。也就是说，用户不再需要考虑自己使用了多少计算资源与存储资源，只需要为自己所使用的服务付费。
使用数据库系统打个比方。对于全托管模式下的云数据库服务来说，用户需要知道自己的云数据库实际占用了几台机器、有多少个 CPU、使用了多少 memory。而对于 Serverless 的云数据库来说，用户不再需要知道这些资源，只需要直接使用即可，在使用之后，云数据库厂商会按照所消耗掉的资源量来收费。
Serverless 模式最大的好处就是带来极大的便利性，同时可能可以为用户节省大量成本。与此同时，Serverless 让用户更少的关心底层细节，理论上可以做到自动根据负载量进行弹性扩缩容。然而，Serverless 根据实现方式不同，可能会带来潜在性能与安全性的风险，而这需要用户在使用前进行更加谨慎的评估。我们在下一段详细阐述。
有一些厂商尽管核心服务并不卖 Serverless，但是允许用户的部分负载 Serverless 化。有两个比较经典的例子。数据库厂商 Databricks 只出售 BYOC 模式的服务，但是其仍然允许用户使用 Serverless 服务来对部分查询进行加速。这一模式在 AWS Redshift 中也被使用。Redshift 尽管是全托管模式，但是用户如果希望针对某条查询进行加速，那么便可以使用 concurrency scaling 方式，从共享资源池中获取资源，瞬时对复杂查询进行弹性计算。
对于用户来说，Serverless 是一层非常高层的抽象：只要让用户不感知到底层部署模式与运行方式，从用户角度看，那就是 Serverless。Serverless 有各种实现思路，而各种思路会影响性能、安全性、成本等多个方面。最主流的实现方式有两种：容器模式与多租户模式。
在基于容器模式的 Serverless 实现中，每个用户实际获得独立的由容器隔离的集群，而用户并不需要知道集群配置细节；在基于多租户模式的 Serverless 实现中，多个用户共享一个超大集群，而资源隔离由系统来执行。
Serverless 最简单的实现思路是直接利用云上的 Kubernetes 对容器进行编排，并在容器层来进行资源隔离处理。这种实现方式实际上与传统的全托管方式无异，只不过是从用户角度来讲，用户不再需要知道底层细节。这种 Serverless 实现方式尽管不需要考虑如何进行底层资源隔离，但对产品的封装与自动运维提出了非常高的要求。由于用户不再需要对资源进行管控，Serverless 服务提供商需要根据用户的负载来动态进行资源分配。如果能够真正做到按需分配资源，则可以为用户节省大量成本。然而，系统动态扩缩容本身在实现上就有不少挑战，而按照运行时情况进行资源调度更是难上加难。如果实现不够理想，那么不仅会造成资源浪费，甚至有可能由于资源匮乏而造成服务宕机。
多租户模式是另一种实现 Serverless 的经典思路。我们所熟知的一些 OLTP 数据库厂商所提供的 Serverless 服务都是选择了这种架构。这样的架构要求数据库本身来做资源隔离，也就是直接在数据库系统层面来做多租户之间的资源隔离。在提供服务时，可以认为厂商直接开了一个巨大的实例，不同用户都在同一实例中分享资源。这种实现方式对系统内核的资源管控与隔离提出了极高的要求，但其可以做到资源的高效利用。毕竟，相比于基于容器的实现来说，多租户模式让不同用户共享同一份资源，而不是为每个用户分别管控资源。理论来说，多租户模式是资源利用率最高的实现方式。
当考虑到用户在选购软件系统时的逻辑，一切从他们的需求和预期出发。
对于只能接受私有化部署的用户来说，当与软件厂商签署合同之后，真正的工作才刚刚开始。客户可能需要组建专门的技术团队来部署和管理这个系统，确保它能够在自己的内部网络中顺利运行。如果你对早期 IBM 与 Oracle 的服务有所了解，应该会知道客户需要为软件配置专业人员。而对于软件厂商，每个客户的环境都是独特的，因此需要提供高度的定制化服务。这无疑增加了双方的工作量和成本。
而转向云服务后，整个过程变得更加简洁。云提供了无以伦比的便利性与弹性，消除了客户对自己购买硬件与维护硬件的烦恼，允许他们根据实际需求灵活地调整服务规模。而为了能够取得如此的便利性弹性，云服务厂商所做出的最大突破便是将一切服务标准化，并让用户建立信任并接受标准化。
如果我们把私有化部署、BYOC 模式、全托管模式、Serverless 模式这四种模式全部罗列出来，就会发现用户在做选择时，实际上是在便利性、弹性、性能、安全性与价格这五个方面在做权衡。
从便利性角度来讲，私有化部署极其不方便，用户需要在购买并配置硬件的基础上再购买与配置软件；BYOC 模式便利性中等，因为用户需要维护自己的云账户，做一些轻量级运维；全托管模式便利性高，用户只需选择购买服务的规格即可；Serverless 模式便利性极高，因为用户甚至无需选择规格，做到完全按量付费。
从弹性来讲，私有化部署几乎不具备弹性，用户一般需要购买特定的机器来安装相应软件；BYOC 与全托管模式都可以在云上做到弹性，但在 BYOC 中，由于数据面板在用户侧，在做弹性扩缩容时会需要在用户账号中动态申请或释放资源，从技术与政策角度可能会有一定限制；而全托管模式与 Serverless 模式在弹性这一块几乎没有任何限制，可以做到极高弹性。
从性能角度来讲，基于多租户的 Serverless 模式要求不同用户同时分享存储与计算资源。共享资源可能造成性能互相影响，因此性能相比于独占模式来说可能处于劣势。而在其他实现方式中，每个用户都拥有自己独立的计算存储资源，能够得到高性能保障。
从安全性来讲，私有化部署模式没有太多安全风险；BYOC 模式由于数据存放在用户侧，因此安全性也相当高；全托管模式与基于容器的 Serverless 模式很显然存在一定的安全性风险；而基于多租户的 Serverless 则具有相对更高的安全性风险，这是因为其数据访问并非在物理上进行隔离。
从价格来讲，私有化部署成本相当之高，因为用户不仅需要投入资金购买硬件与软件，同时需要配备相应的运维团队；BYOC 与全托管模式从厂商角度来讲，定价模式一般保持一致，因此价格也相差无几；Serverless 模式由于可以根据用户负载自动调节资源使用，并且可以共享资源，因此做到了价格的大幅降低。
从这五个方面考虑，我们应该不难得出一个推断：小型公司可能更倾向于牺牲某些性能和安全性来降低成本并获得便利性与弹性，而大型企业，考虑到它们庞大的用户基础和数据资产，会优先保障性能和安全性。
对于软件服务提供商，核心目标始终是盈利。从商业角度看，无论提供哪种服务，厂商最终的目的都是希望将利润最大化。当我们审视上面一章节的表单时，我们应该不难发现，如果希望从 Serverless 服务中赚到钱，那么所提供的服务必须具有广泛的吸引力和市场需求。当然，这不仅仅是因为 Serverless 服务的客单价可能低于（或者远低于）其他种类的服务，也是因为从厂商角度来说，提供 Serverless 服务要比传统的全托管或 BYOC 模式所支付的基础成本更高。
我们可以想象一下，Serverless 的核心卖点之一便是弹性。为了确保用户可以随时获得所需的资源，并享受到瞬时启动的体验，厂商一般都需要维护一定数量的预备资源，这通常称为"热池"或"warm pool"。维护预备资源的成本得有厂商自己买单。相比之下，如果只是售卖全托管服务或者使用 BYOC 模式，那么基础资源的费用都是由用户承担的，厂商所赚到的钱即为基础费用之上的软件服务费用。
当然，如果 Serverless 服务拥有大量用户，那么相比于传统云服务来说，软件厂商会发现有更多的盈利机会。他们可以通过各种方式提高收益，例如资源共享、元数据节点共享或超售策略。超售策略基于的是一个简单的事实，即尽管用户可能预留了大量资源，但在实际使用中，总有一部分用户不会充分利用他们的配额。这为软件厂商提供了一个卖出更多资源的机会。
Serverless 与传统托管模式在商业模式方面的不同。
上图表述了 Serverless 与传统托管服务在商业模式方面的不同。在传统托管模式下，厂商的成本与营收比例相对比较固定，且随着客户数的增长而线性增长。而对于 Serverless 来说，当在客户数不多的情况下，厂商基本都是在做着亏本的生意，只有在客户数达到一定规模之后，营收才可能高于成本。但与传统托管服务很不一样的点是，当厂商的利润率可能会随着客户数的提升而显著提升，出现超线性增长。这也许就是为什么 Serverless 的故事在创投圈里非常吃香的原因。
但我们应该可以很容易想象到，并非所有软件都适合做成 Serverless 服务。从市场接受角度来说，只有那些已经被广泛接受的技术才有可能从 Serverless 中真正获得利润。同时，由于 Serverless 用户量大，出线上故障的几率一定也是更大。因此，一般来说 Serverless 服务适合商业化那些历史悠久且更加成熟的系统，如 MySQL、PostgreSQL 等，从而大大降低系统的故障率。
Serverless 化
由于本人一直在从事流处理方面的开发与商业化工作，因此时常会考虑如何将如 RisingWave 这样的流处理数据库做成云服务提供给用户。而由于流处理数据库相对于传统数据库来说较为独特，很适合作为案例来讨论如何进行 Serverless 化。
我们先从用户角度考虑。上文提到，用户经常会从便利性、弹性、性能、安全性、和价格这五个方面考虑所需要的服务模式。从便利性、安全性与价格这三个角度来看，流数据库并没有什么过多特别之处。而从弹性与性能这两个角度来看，流数据库的差异化便体现出来。流数据库的核心概念是物化视图，而其表示的是对数据流进行的连续不断的增量计算。而数据流可能会随时间而有较大幅度的变化，因此弹性至关重要。而由于其进行的是连续不断的计算，且用户可能对计算结果的新鲜度非常敏感，因此需要系统持续保持高性能。从本文前面的表格中我们可以看到，基于多租户的 Serverless 模式由于会共享资源，导致性能干扰，因此可能并不适合流处理。因此，想要将流处理系统进行 Serverless 化，更可靠的方式应该是采用容器进行实现。而也如上文提到的，基于容器的 Serverless 实现方式需要通过用户负载来进行动态资源调度，要高效利用资源并不容易。从用户基数来讲，不得不说流处理技术还远没有到达像 PostgreSQL 与 MySQL 这样的普及程度，因此想要获得超线性增长并不容易。
总的来说，从用户与厂商双方面的诉求来分析，我们不难得出一个结论：流处理系统厂商暂时比较难通过 Serverless 来获得最大收益。
当然，这种局面可能会随着时间的改变而改变。在流处理领域，基于 Apache Flink 的商业化公司 Decodable 便提供了基于容器的 Serverless 服务。与流处理系统紧密相关的消息流队列系统背后的商业化公司，如 Redpanda、StreamNative (Apache Pulsar) 等，都在考量提供 Serverless 服务的可能性。其中，Redpanda 的 Serverless 服务即将上线，而 StreamNative 所商业化的 Apache Pulsar 从内核上便支持多租户能力，想必提供 Serverless 模式只是时间问题。
近几年，云上 Serverless 服务这一理念逐渐崭露头角，吸引了大量开发者和企业的目光。它所带来的众多优点，如弹性伸缩、成本效益和运维简化，使得越来越多的项目考虑采纳这一模式。然而，每一种技术都有其适用的场景，Serverless 并非例外。它不一定适合所有的软件系统和业务需求。在决策过程中，企业和开发者需要明确其局限性。总体来说，厂商是否应该开发 Serverless 产品，以及用户是否应该购买 Serverless 产品，都应该经过对自身情况与市场的整体分析之后再做出决定。
吴英骏，流数据库公司RisingWave（risingwave.com） 创始人&CEO。博士毕业于新加坡国立大学计算机系，为前 Amazon Redshift 工程师和前 IBM Research Almaden研究员。常年担任数据库三大顶会SIGMOD/VLDB/ICDE的评审委员会成员。技术交流可以关注公众号“RisingWave中文开源社区”或者添加微信“risingwave_assistant”。
【亚马逊云科技生成式 AI 构建者大会】启动报名啦！
开发者技术嘉年华，干货 and 趣味 全都要！
前沿技术：全面揭晓亚马逊云科技生成式 AI 的发展态势和研究成果
大咖云集：与大咖零距离探讨生成式 AI 的热点技术话题与热门应用场景
成功案例：掌握生成式 AI 的精选案例与创新思路
动手实践：资深导师协助深度学习 AI 算法和模型构建技巧
面向 Builder：提供开源工具，助力开发者快速进阶
读者福利
微信扫码关注该文公众号作者