上云还是下云,最大挑战是什么?| 对话章文嵩、毕玄、王小瑞
近半年来,公有云领域频频发生阿里云、滴滴等平台崩溃事件,与此同时,马斯克的“X 下云省钱”言论引起了广泛关注,一时间,“上云”和“下云”成为热议话题。
在最近举办的 AutoMQ 云原生创新论坛上,AutoMQ 联合创始人兼 CEO 王小瑞作为圆桌主持人,与 AutoMQ 联合创始人兼 CSO 章文嵩、贝联珠贯创始人兼 CEO 林昊(毕玄)两位技术大咖,围绕上云与下云的趋势之争,以及面临的挑战展开思想碰撞。
章文嵩:我觉得上云肯定是大势所趋。因为云是给客户创造价值的,就云计算的本质来说是资源的聚合与复用,通过超卖的方式实现成本的降低,从而帮助客户实现成本节省,同时也为云厂商创造盈利机会。以一个简单的例子来说明,原本 A 用户和 B 用户分别在白天和晚上使用机器,每个时段都需要花费一个单位的成本。然而,云厂商的出现让 A 和 B 都不再需要购买机器,而是通过租赁的方式,付给云厂商较低的费用如 0.6,使得云厂商的收入 1.2 超过了 1 个单位的成本,实现了盈利,客户也省钱了。通过错峰使用,A 用户和 B 用户仍然可能没有消耗掉全部的计算资源,云厂商有机会还能将未使用的资源卖给其他用户,实现了资源的高效复用。另外还有研发资源的复用,随着系统规模的增大,边际成本降低,云计算成为一个能够持续创造价值的解决方案。
比如美国的一份报告说明,在所有的 IT 支出里面,2022 年美国云计算的渗透率将近 10%,而 Gartner 预测到 2026 年,这一比例将上升至 20%。在中国,尽管 SaaS 行业发展尚未成熟,但 IaaS 和 PaaS 模式已经在云厂商中得到广泛应用。以阿里云为例,过去两年一直保持盈利,阿里云所有云资源的收入加在一块,大概是一年 1000 亿左右,阿里云市场份额占比 30%-40%,整个中国云市场的规模约为 3000 亿。通过工信部公布的中国整体 IT 行业的收入 10 万亿,可以得知中国云市场渗透率大概 3% 。
当然中国未来 SaaS 空间会很大,所以美国如果四五年后达到 20% 的云渗透率,那中国有可能到 10% 以上的渗透率,未来 50% 甚至 70% 以上的渗透率,所以我觉得上云是大势所趋。
毕玄:创业后,我接触到了更真实的情况。以前代表阿里云拜访客户时,客户因我可能促使他们购买更多阿里云产品而避免说实话。现在作为中立方,客户更愿意分享真实想法。从整体趋势上来看,我坚信云计算有巨大增长空间。尽管中国云市场增速下降,甚至阿里云是比前两年有下滑,但这有很多综合原因,总体上我觉得云肯定还会继续增长。
许多公司衡量云成本的方法很简单,即比较线下机器支出和搬到云上的费用。但考虑到人工成本,难以简单对比。大公司即使迁移到云上,人工成本仍然存在,因基础设施管理人员短期内难裁员。我之前跟某互联网头部公司的人聊到底是要往云上搬,还是继续保持自建的话题,核心还是要搬到云上,充分发挥云的弹性,而不是静态使用。
纯静态用对大公司来讲成本难以平衡。弹性使用云,尤其是按量计费,就像现在中国按量计费比包年包月其实单价贵很多。在折扣谈判中,按量付费和包年包月分开谈,通常包年包月方案能获得更低的折扣,因为按量收入不确定性较大。
另外一个问题是中国的按量错峰效应不够明显,云厂商对此不太热衷。尽管按量计费可能增加成本,但之前通过推演,我们发现在折扣谈判后,每天使用 8 小时左右能够实现成本打平。
一些大公司进行了假设推演,从线下切换到按量计费和完全弹性系统,能显著节省成本。然而,由于技术改造较多,很多公司不愿采用这种方式,但我认为这是技术的趋势,很多公司一定会越来越弹性。
对于大部分中小企业而言,云计算的灵活性比成本更为重要,因此它们更自然地采用云服务。从成本角度来看,随着技术的演进,整体用云的成本将逐渐降低,比自建更具优势。同时,云计算的应用不断增加也是因为壁垒的存在。在 AI 时代,大多数企业首选使用云而不是自建,因为自建的门槛较高,而云服务为业务快速创新提供了重要支持。
章文嵩老师补充 : 云厂商的核心追求指标是超卖率,因为超卖率是能够真正提高整个业务的经营效率。如果客户愿意购买包年包月,但又因为在一年 365 天中,很多时间客户并不需要使用这些资源,实际上增加了云厂商的利润。关键在于客户要有弹性,根据需求变化使用云,以节省成本,而不是根据峰值去保留资源。
在上云方面,我这边是有个规模公式的,当基础设施规模较小时,在云上购买资源非常便宜;但随着基础设施规模的增大,成本上升的速率略有增加。自建的成本虽然一开始较高,但随着规模的增大,其斜率逐渐降低。两种模式的斜率不同,必然存在一个交叉点。在这个交叉点左侧,规模较小的情况下,使用云的成本较低,而自建的成本较高。然而,当规模超过一定阈值时,由于自建的起点较高但斜率较低,自建可能更加划算。云厂商针对交叉点右侧提供让利打折的机会,因为对于云厂商来说,已经投入的人力和各方面成本会随规模的进一步扩大而降低,使得边际成本更低。
回到 Twitter 事例,Twitter 原来有三个数据中心,波特兰、Sacramento 和亚特兰大,应该做了类似的三活。马斯克挑战团队在仅六天内把三个数据中心缩减为两个节点,结果在平安夜他与工程师们直接关闭了位于 Sacramento 的一个数据中心,通过货车把服务器拉到波特兰数据中心。现在应该是双活架构,波特兰数据中心的服务器就富裕出来,把云上的资源优化并迁移了一部分到波特兰数据中心中,这一举措实现了约 10 亿美元的巨额成本节约,但他更多的成本节约主要来自人力资源方面。将员工数量从 8000 人裁减至 2000 人,美国工程师平均年薪 30 万美元,裁员的工资节约了近 18 亿美元,所以在总体运营成本上取得了显著的 60% 节约。然而,有些文章直接写 Twitter 下云节省 60% 了云资源成本,媒体的这个表达不正确,也容易误导观众。
章文嵩:作为曾在阿里云工作多年的前员工,我找相关同学了解到,故障的根本原因在于一个全局鉴权服务存在软件缺陷,导致正常鉴权请求被拒绝,而且没有很好的故障恢复预案。虽然有时候故障不可避免,但云厂商确实还有很多改进空间。
首先,像全局依赖的中心系统应该是多区域多活的。当一个区域发生故障时,不应该影响其他区域的服务,流量应该迅速转移到其他可用的区域。这种架构可以最大程度地减少单点故障带来的影响。另外,即便是软件缺陷,我们也需要有充分的预案。在多个区域同时因为软件缺陷而宕机时,我们应该能够快速将其重启并拉起,以缩短止损时间。另外,提前演练这些预案是至关重要的,当触发潜在的软件缺陷时,有了相应的预案,一旦出现问题,重启就能够快速恢复服务。而不是在事发现场去查找问题,浪费宝贵的时间。
另外,我认为云厂商也会因为这些不可靠的故障而承担一定代价的。通常,云厂商们都会按照一定的规则进行赔付,一般是不可用时长大概是 100 倍赔付规则,他们也会不断改进,避免再次陷入相同的故障。
我相信随着云技术的不断改进,云系统会变得越来越可靠。云厂商的技术能力和系统可靠性在各方面都远远高于自建系统。一般情况下,自建系统可能规模较小,故障发生时都不太引人注意,但云厂商由于有大量客户在上面使用,故障的影响就更加显著。然而,正是因为有这么多的客户在不断使用云服务,云系统会得到更多的锤炼,变得越来越可靠。而且一定会比自建的系统可靠性高非常多倍,这是毋庸置疑的。
毕玄:对于故障问题,我认为云厂商相对来说故障次数要比自建系统更少。但云厂商通常因为集中化的特性,一次故障的影响面较大。相比之下,自建系统的故障可能并不为人所知,实际上累积的故障次数比云厂商会更多。
总体而言,我认为用云是更好的选择。这实际上是一个自有团队的问题。许多公司还会选择使用云厂商 PaaS 的服务,因为很难找到具有专业技能的人才。在中国,从事基础设施技术的工程师数量相对较少,人才储备有限。这类人才通常待遇较高,我接触到的很多中小型客户群体,他们希望由专业公司提供服务,而不是自己搭建,因为自己搭建的话,一方面做不好,另一方面人才难以留住,这是一个非常现实的问题。
因此,我认为在这些方面,云厂商的壁垒会越来越高。至于稳定性这个话题,没人敢说永远不会发生故障的。实际上,所有云厂商都曾出过严重的故障,没有一家例外,只是影响的程度取决于客户规模的大小。有时候我们会看到,阿里云发生故障时,有人回应说另一家云更好,也有人回应说另一家云可能存在更多问题,只是你不知道而已。总的来说,我相信云厂商的人才密度会更好,因此我也认为使用云服务总体上会更安全、更稳定。
毕玄:从我接触的一些客户来看,许多企业在迁移到云平台后往往对云成本一无所知,尤其是大型集团公司。相较于繁琐的 IDC 流程,云的便利性导致一些公司对于机器的创建者和用途一无所知。因此,首次迁移到云上时,许多公司可能简单地将资源放上去,但缺乏对资源创建和用途的了解。这可能导致付费后公司在月底账单出来时才发现一些资源的存在,无法追溯。尽管这些费用必须支付给云厂商,但实时监控账单变化对成本管理至关重要。
另外,我们认为在云上有很多复杂的用法,而许多公司目前还无法很好地应对。例如,资源包是一种优化成本的方式,实际上,在采购资源包的情况下,可能比原来的折扣更便宜。资源包的本质是为你提前准备好一些资源,当然,这需要一些算法,但技术含量并不是很高。有些公司购买存储资源包,就像购买手机流量一样,预先准备了一定量的资源,而这个资源在购买后必须在下个月内使用,否则不能退款。但如果公司确信能够充分利用这些资源,那么这笔钱肯定比折扣更便宜。
我们知道对于很多公司来说,更省钱的方式是大量启用弹性化的机制,就像许多公司采用无服务器架构(Serverless)的方式一样。当然,这涉及许多新技术的投入,在一些公司中推动这一点可能并不那么容易。虽然这可以大幅降低成本,但要将其推广并真正应用到实践中是一项庞大的工程。相比之下,之前提到的改变采购策略、调整策略等相对来说更为简单,只需要进行一些调整即可。
此外,公司还需要了解成本结构。在过去,成本分析可能并不被认为是非常重要的事项,但我们最近与一些金融、汽车等行业的客户进行合作时发现,他们非常关心集团公司的资金花在哪些部门,这些部门的业务情况,比如与业务 ROI 是否对齐。我们提到 IBM 之前收购的一家公司,主要做是做成本分析和分摊,以及与业务挂钩。例如,如果一个业务的目标是每日活跃用户(DAU),它将查看 DAU 的增长情况以及当月的 IT 支出变化情况,如果没有达到预期,管理层将进行问责。因此,这种产品在国外非常受欢迎。
在中国,企业逐渐关注业务状态,对 ROI 等因素越发在意。对于 IT 结构,我将其分为业务系统、大数据和人工智能(AI)三类。业务系统的优化方案往往与业务方的具体情况紧密相关,涉及较大的实施代价。而大数据和 AI 在降成本方面展现出通用方案的可能性,这也是我们公司(贝联珠贯)主要专注的领域。在大数据方面,我们公司产品能帮客户降低 30%-40% 成本,AI 方面虽然目前降成本效果有限,但通用方案已实现 10% 的成本降低。
总体而言,大部分公司目前最大的 IT 投入是业务系统,而大数据和 AI 投入较大的主要是头部公司。尽管大数据和 AI 很热门,但在 IT 支出上占据更高比例还需要时间。因此,我认为业务系统优化应根据实际情况进行。
章文嵩:我有一个想法,除了明确成本,更重要的是将其与公司业务深度结合。以淘宝为例,作为一个买卖交易平台,其核心是交易。我们是否能算出每一笔交易的 IT 支出?比如通过计算一个月内的所有 IT 支出以及完成的订单数量,我们可以得知每一笔交易的成本。
对于滴滴这样的出行平台,同样适用。它是一个撮合交易的平台,供需匹配也是其中的一环。我们可以计算每一笔交易的平均成本是多少钱。对于视频网站,观众每分钟观看视频,我们花费了多少钱呢?这实际上是可以提炼出来的,将其与业务深度结合,老板们更容易理解。
比如,淘宝的客单价是多少?假设是 200 多块钱。而我们只花了几分钱的 IT 成本。其中的成本结构是什么样的?是谁支付的?过去与现在相比,哪些地方可以不断优化,持续降低运营成本?另一方面,例如从单活变为双活,这是增加的新投资,所有这些都需要清晰阐述。实际上,将成本结构与业务深度结合,不仅有助于运营优化,而且对于公司的客户沟通也非常有帮助。我在淘宝和滴滴的经验告诉我,通过将账单与核心业务本质结合,管理者能够清晰地理解 IT 成本和业务的关系。这确实是一种非常有效的方法。
章文嵩:弹性是最关键的,系统能不能有随着业务需求进行弹性的能力?因为任何一家公司的业务需求都不是全天候平稳的,会有早晚高峰,甚至午休时的购物高峰。因此,如果我们按照需求曲线的最高点来分配资源,显然是不划算的,因为我们会为闲置的资源花费大量的资金。最理想的情况是,根据需求曲线的波动,我们的花费能够完全匹配需求曲线下的面积。
实际上,这需要弹性,而弹性的能力并非易事,需要有一些共性的组件。如果每家公司都自己做弹性,涉及研发的方方面面,需要大量投入。然而,不同的企业,比如 A 企业和 B 企业,在弹性方面需要的一些公共组件是相似的。如果有一家企业已经实现了这些组件,那么 A 企业和 B 企业可以复用,这提高了效率。同时,做这些组件复用的企业也能够获利,因为它可以服务多家客户。每家公司实际上只需在某些模块上进行弹性改造,而不必对所有东西都进行改造。比如,像我们 AutoMQ 云原生的 Kafka,它在第一天就天然具备弹性,能够随着业务规模或云数仓自动伸缩,这样的组件是非常好的云原生创业机会。
在云上部署时,为了获得弹性,我们要尽可能地复用一些标准组件,这对研发方面的投入是最低的,效率是最高的。当然,像之前提到的 Spot 实例,由于它们的特点是云厂商的库存资源,价格较低,但这样的 Spot 实例是随时可能被回收的。因此,如果应用程序能够适应,可能采用无状态的 Serverless 架构是一个解决方案,即使被回收了也没关系,其他地方可以接管过来。这实际上对应用程序提出了更高的要求,但在一些情况下,利用 Spot 实例这样的资源是可行的。
毕玄:以前我在阿里带中间件团队的时候,我们一直在找降低成本的方向。给管理层汇报对于我们来说是一个很重要的任务,因为要说服管理层进行技术投入是非常重要的。从 2017 年左右,成本就成为我们的核心议题。就像正明(章文嵩)刚刚提到的,高层看待成本的指标就是——阿里的 1000 笔交易成本,也就是每完成 1000 笔交易,今年花了多少钱,明年花多少钱,后年花多少钱,他们只会问你这个问题。至于成本背后的含义,你可以有很多种理由,比如解释成本高的原因是我前面有一群人,交易效率不行,他们要更多的精细化运营等等,所以导致我要投更多机器。老板不会关心这些东西,他只关心你到底怎么给我降下去,方案是什么?所以过去我们在这方面每年都受到很大的挑战,这种偏业务型的指标确实挺好。
此外,现在实施成本控制的方案,我认为在云上,弹性一定是永远的第一方案。因为你要回答高层的另一个问题,成本到底做到什么叫合理?如果你解释不清楚这个问题,那这个成本就永远都可以降,对老板来讲你觉得投 10 亿合理,老板说 10 亿太多,投 1 亿,这个是要有逻辑的,你需要向老板证明,如果我们每天的业务请求量是这样的,我所需的成本就是这个请求量覆盖的面积,这笔钱是必须花的。
以前我们做中间件,这就是成本优化能做到的极致。这个极致从现在的技术表现上来看就是 Serverless,只不过 Serverless 现在要做到偏在线型的应用,全部 Serverless 化还是有相当大距离的。
我们在阿里曾经推演过,如果我们只为面积付费,我们单笔交易成本应该能降到现在的 1/10。所以按照这个你推演了一个极致,老板每年就对你都不满意了,因为老板按照我们的逻辑推演后认为,成本应该降到现在的 1/10 才是合理的。我们明白技术上存在各种问题,所以现在 Serverless 肯定是大趋势。然而,观察当前的 Serverless,主要由云厂商和中立厂商提供,为大家设计了通用的 Serverless 方案。在这个 Serverless 的背后,可能是采用了按量付费的机器,很多创业公司和国外的成本优化公司采用类似的逻辑,先将应用投放到 Spot Instance 上运行,然后不够了再切换到按量付费,最后才考虑包年包月。这三层逻辑关系在国外为什么能够实现折扣券的存在呢?我们认为是因为国外许多应用的整体 IT 水平相对更高,业务的无状态能力更强,更容易进行迁移。在大数据和人工智能领域,许多公司背后都是通过大量使用这种逻辑来实现的,实际上,他们屏蔽了这一切,不需要你知道 Spot、按量、包年包月的背后逻辑,他们将这些逻辑完全封闭,卖给你时你觉得价格更便宜,但实际上他们仍然具有竞争优势。
在这三层逻辑基础上,我们觉得是还可以加另外一个逻辑的,另外一个逻辑就是我们以前在阿里做的混部。在很多公司推行这个方案时,我们采用了类似国外公司的弹性策略,先 Spot,再按量,再包年包月。我们的逻辑是先混部,再 Spot,再按量,最后是包年包月。这是因为混部相当于价格是 0,而 Spot 实例是需要支付费用的。另外,Spot 实例的回收可能会导致问题,因为云厂商可能会多次回收实例。我们曾有客户经历被回收了 10 次,而其任务需要连续两个小时完成,无法中断。并非所有任务都支持断点功能,因此它如果两个小时之内被收回掉了,再购买一个 Spot Instance,在重来了 10 次以后它那个价格比按量和包年包月还高,所以这个时候你要处理很多乱七八糟的问题,包括跟云厂商,甚至有商务谈判等等,这种都不一定是技术问题。
所以我们认为,实际上在技术层面,如果你按照这个方案推进,选择一个第三方或者具有研发投入能力的公司,我们觉得也可以自己投资。我们与一家大型公司合作,按照这个逻辑进行四层弹性方案,就像我刚刚说的混部 -Spot- 按量 - 包年包月,他们实施了这个方案,一年应该省下近 3000 万,按照这个方案推进,当然这可能需要一些业务投入。
章文嵩:自建的基础设施服务需要相应的研发投入。之前提到的自建和云服务的成本的交叉点,云厂商可以通过让利来提高吸引力。比如以一个拥有 5 万台服务器的互联网服务为例,考虑到硬件、托管和网络带宽资源等成本,每台机器年均花费约 2 万元,总计约 10 亿元。然而,自建还需要额外投入构建分布式系统、操作系统和数据库等,以及维护一个六七百人的研发团队,人员成本高达 5 亿。
对比阿里云的规模,其年收入约 1000 亿元,阿里云应该是 2 万人,人员的成本估计要花掉 200 多亿,机器成本约占据 6、700 亿元,毛利约 300 亿元。如果扣除市场营销、人工成本费用,这个业务还是赚钱的,赚的不多,200 多亿人员成本对应一年六七百亿基础设施支出,阿里云是很有规模优势的,还有产品服务丰富度的优势。
对于规模较大的互联网企业,比如 5 万台、 10 万台机器,云厂商应对于这种体量的互联网用户,应该用这样的策略,了解他的成本结构,给他一个无法拒绝的 Offer。比如云厂商知道企业自建的成本结果是 15 亿,给企业 12 亿元的价格。这样对云厂商来说,规模采购会有一些成本的节约。此外,对于人员成本,如果云厂商能够保持较低的增长,尤其是在已有研发基地的情况下,也可以在整体利润中获得优势。
所以,自建的成本很高且对社会无益,因为云厂商已经做得比自建要好。除非你的体量能达到百万台的机器规模,那就自建。
毕玄:正如正明(章文嵩)所指出的,自建成本是许多公司在构建基础设施时面临的重大挑战。小红书等公司目前仍主要依赖云服务,这仅是考虑中的一种方案。相比之下,快手采用了大量自建,而云厂商若能真正影响中国头部互联网公司,其增长将是显著的,因为头部公司基本上都未完全迁移到云上。
即便是头部互联网公司,如快手、美团、滴滴,虽然主要是自建基础设施,但也在一定程度上使用云服务。然而,这几家公司已经是中国顶级的互联网公司了,但自建团队仍然是一个复杂的问题,需要体系化的团队,而不仅仅是雇佣一两个人,还有 IDC 选址、服务器、网络、芯片等多方面的人才需求等问题。
自建机房遇到的第一个问题是招不到人,即便明确知道需要招聘哪些人才,但实际面临的招聘难度非常大。以操作系统为例,拥有这方面经验的人才相对稀缺,而且他们多分布在大型科技公司中。招聘这些人不仅难度大,而且在大型科技公司中跳槽也相对困难。这些公司规模庞大,面临的问题多,因此有更大的发展空间。
总体而言,这些公司虽然有足够的财力和意愿进行自建,但实际的执行过程非常痛苦。这凸显了人才密度是一个关键问题,不仅在中国,在国外也是一个有限的资源。
圆桌对话环节在意犹未尽中画上圆满的句号,三位大咖对话涵盖了上云趋势、系统可靠性、成本治理以及下云挑战等关键议题。为业界提供了深刻的见解和实践经验。
由章文嵩与王小瑞老师创立的 AutoMQ 公司的 AutoMQ Kafka RC 版本发布了全新特性,包括多云兼容性适配,Spot 实例强制回收容灾、裸设备 WAL 等。也带来了新版本的全新指标,新版本除了有十倍的成本优势外,支持 4 分钟内完成从 0 到 1GiB/s 的极致弹性,同时在追赶读的场景下有读写隔离的天然优势。AutoMQ 即将发布完整的基准测试白皮书,将会揭秘更多的技术指标。欢迎大家体验!
谷歌新年大裁员,引硅谷裁员潮!OpenAI正式推出GPT Store,但第一批应用已被像素级抄袭;腾讯服务器深夜崩溃 | Q资讯
微信扫码关注该文公众号作者