你当初被谁“忽悠”上了云，现在又在被谁“忽悠”温度控制阀原理下云？
第一批吃螃蟹的总是互联网公司，其中最典型的当属 Netflix。从 2008 年因数据库损坏决定上云，Netflix 用了 7 年的时间完成了上云迁移，并关闭所有的流媒体服务数据中心。如果没有云服务，随着业务规模的不断扩大，Netflix 就需要投入庞大的运维和研发团队来处理与其核心业务不直接相关的事务。这个案例每年都会被 Amazon 拿出来对外宣讲。
到了 2016 年，美国联邦调查局（Federal Bureau of Investigation，FBI）在结构会议上解释了自己如何利用云计算来管理安全。虽然并没有直接鼓励大家用云，但带来影响就是互联网之外的企业之后也开始尝试上云。
国内上云情况与国外基本相似，只是晚了几年。2009 年，阿里云成立；次年，腾讯云正式对外提供云服务；百度智能云更是到了 2015 年才正式对外开放运营；华为云虽然 2005 年就已经成立，但当时也主要做政务云和私有云，规模很有限。
出来卖云但自己不用的话，国内用户不会买账。因此，头部互联网企业引领的国内上云潮逐步开启，走在前头的依然是互联网企业。经过云厂商多年 " 市场教育 "，国内对上云似乎已经达成了共识，现在甚至政企成为发展主力。
但在 2023 年，随着推特和 Ruby on Rails 之父 David Heinemeier Hansson（DDH）联合创建的 37Signals 宣告 " 下云 "，业内展开了一场关于上云还是下云的讨论。但是纵观国内，其实还没有企业公开宣告自己要完全下云，这场讨论在国内最后实际上变成了一场对云厂商声势浩大的声讨。
一、云厂商带来的各种 " 坎儿 "
一定程度上，企业遇到的大多数用云问题都是云厂商带来的。
磐吉云数 CEO 冯若航在直播节目里分享了自己 15 年时的经历：上云之前，部门自己拥有的几百台服务器的机房，一年成本大概 1000 万，上了阿里云大数据全家桶后，每年计算花掉 3000 万、存储 4000 万，效能没有出现变化的情况下，成本却翻了七倍。
虽然他没有详细解释花费项目，但已经说明了在很多人眼里，云厂商毫无 " 性价比 "。云厂商到底做错了什么？
被误解的弹性
弹性本来就是一件不容易做到的事情，不管是对用户、企业，还是云厂商来说。而云厂商手握巨大的资源池，可以为不同的用户调度资源，这让弹性成为可能。但要把弹性真正用起来还差很多。
事实上，现在并不是所有产品都是弹性的，大多数云产品还处于云托管阶段，即把传统软件架构通过再部署的方式上云，只有少数产品是按量付费的，比如 S3 按照存储量和请求 API 次数收费。
这里面有一定的技术原因。
当前阶段，业务重度依赖的开源产品大多数还是 10 年前诞生的成熟开源产品，这些产品对云计算模式不友好。比如，很多开源软件并不是面向多租户设计的，而是从大企业内部孵化出来的、面向内部业务的，并没有多租户需求。
如果把这些软件搬到云上就要对其架构进行重构或者改变其接口行为，但一般云厂商不会这么做，因为后续还有兼容性等问题。但重构这些产品对云厂商来说，研发成本、运维成本，甚至后续迭代的成本都会很高。结果就是，每个用户独占一套集群，成本很高，也做不到按资源使用粒度计费。在云上部署一个开源软件要三台机器起步，如果真正按请求付费，云厂商大概率要赔钱。
第一天就诞生在云上的产品就没有这种问题。产品经理清楚地知道这个产品要服务数万个、甚至几十万用户，他第一天就会考虑接入成本优化问题。因此，这类产品基本都是按量付费的模式，比如 Amazon 的 SQS、S3、Lambda。近两年面向云原生设计的开源产品，商业化模式也比较友好。
云托管的技术架构也限制了云厂商的定价策略。绝大多数云产品按实例或规格售卖，特别是以开源产品为内核的云产品。云厂商把这些开源产品（甚至包括数据库）拿去做云托管然后包装成一个云产品去售卖，这些产品的 " 按量付费 " 是按小时粒度进行按量付费，比如 4 核 8G 每个月 1000 元，然后再按照小时计费，如果下个小时释放了就不收费。
云厂商追求的是超卖率，通常用户选择包年包月方案能获得更低的折扣。但实际上，用户不可能在不用的时候就把这个实例或者规格释放掉，即使没用也会把资源保留在那里，这就带来了更多的消耗。所以，用户实际上并没有享受到这种按量计算方式带来的弹性好处。
当然，这对厂商来说也并非好事。除了短暂的流量高峰，其他时候的资源闲置会造成巨大浪费。此外，云厂商还要为 " 按需使用 " 预留出大量的资源。
另一方面，对于真正按量付费的云服务，用户也要付出一定的使用成本。比如以前的软件架构不可能是基于 S3 设计的，所以传统架构直接搬到云上，S3 的 API 肯定用不起来。
总体说来，只有相对成熟、规模较大、已经形成事实标准的产品价格才更为便宜，只是这样的产品数量有限，单向调节阀原理还集中在 IaaS 和数据库范畴，大量云产品并不是真正的按量付费。
这也表明了，云计算还处于不成熟的阶段，未来云厂商还是需要通过技术架构去降本，比如把更多云产品优化成真正的 Serverless 或弹性架构，真正规模化优势释放给用户。毕竟，" 贵肯定不是云计算。"
但目前国内云计算市场格局还在不断变化，整个价格体系仍有一定的不确定性。今年 4 月，阿里云宣布核心产品价格全线下调 15％至 50％，存储产品最高降幅达 50%，被称为是 " 阿里云史上最大规模降价 "。之后，腾讯云，京东云、移动云、天翼云等纷纷跟进。同样的降价策略到了双十一时再次上演。
相对地，国外厂商已经过了大规模 " 价格混战 "。2014 年左右，国外云厂商经历了一场激烈的价格战，数百家云厂商竞争激烈，最终剩下主要的三四家。
但种种因素叠加，云厂商其实也很难盈利。头部的 Amazon 用了 9 年才首次公布盈利，阿里云则用了 11 年。
多而杂的云产品
另一个事实是，国内大部分云产品缺乏竞争力，基于开源软件做商业化和产品化的做法就决定了这点。
现在的云产品数量非常多，大的云厂商有上百个。虽然一定程度上，这么多产品确实是云厂商为满足用户真实需求而研发的，尤其是那些研发运维能力较弱的团队很依赖云托管产品，但这也是国内厂商一味 " 参照 " 国外产品的后果。
国内云厂商基本都是 " 先做起来再说 "，并没有考虑产品的顶层设计。国内厂商还喜欢 " 一站式 " 包揽所有问题的解决，后果就是各种产品自成一体，能力同质和重复，甚至会出现内部竞争。
一方面，上百个产品很多是在重复研发、运维、部署等，最终让整个投入变得特别大。另一方面，每个云产品都做得很重、有完整的生命周期，这需要专业团队负责到底，现实却是一个产品可能只有几个人负责，这几个人能把商业化做好就已经不错了，很难兼顾到接入成本、使用体验等。
更重要的是，上百个产品里，真正能够承担起营收规模的可能只有少数十几个，大部分产品规模小、做得一般，却消耗了大量的人力。当然，云厂商们近两年也在进行调整策略，淘汰了一些需要维护却难以带来效益的产品，更加聚焦在自己的 " 拳头 " 产品上。
反观国外云厂商，他们更注重通过标准化或提供更多自定义能力来服务企业。其次，国外云厂商的生态位是就绪的，当整个生态就缺这么一款产品时，放进去就能形成级联优势。比如 Amazon 每个产品的体验、UI、文档、交互做得几乎一模一样，功能也做得比较克制，更倾向通过多个云产品的组合实现相关功能。
国内云厂商为适应快节奏的市场需求，产品从研发到推出和运营的周期通常较短。但在追求速度和追求质量之间需要取得平衡，不能过于偏向速度。尤其 ToB 业务从第一天就面向企业，用户对服务的质量要求很高。
在这方面，很多云厂商还有很大的改进空间，但肯定不是要求客户妥协，也不是通过降低服务质量、以低价策略来取胜。
二、成本，终归是企业的事
" 我们相信了市场营销。之前各种营销宣传的亮点均在于它将更便宜、更简单、更快速。事实上，只有最后一个承诺真正实现了。"DHH 很多次解释自己公司选择下云的原因时这样说道。
为了拿到订单，销售人员可能会向客户推销一些他们实际上并不需要或是过度设计的产品，比如不是所有业务都需要异地双活、两地三中心等高可用架构。云厂商的过度承诺提高了用户的期望，让用户有了错误的期待，但上云的种种问题却没有及时被告知。
很多在云厂商工作过的人都提到，许多公司在首次上云后只是简单地将资源放上去，但对资源的创建和用途并不了解。这导致企业只有在月底云厂商给出账单时才发现一些资源使用存在问题，但已无法追溯和挽回。
用云的时候一定要非常保守、非常克制，但实际上企业太相信 " 按需付费 " 了。
过去几年的高速发展，让企业更关注云到底能不能帮助解决问题，对成本反而没那么上心。云厂商跟着互联网一起快速增长的同时，很多东西也没做好，牺牲了质量换速率。如今在 " 降本增效 " 大背景下，大家要去看成本了，才发现要考虑这么多问题，实际上是增长掩盖了这些问题。
大多数互联网公司的主要成本通常集中在 CPU、存储和带宽，其中 CPU 占 30%～40%，剩下的多数是各种各样的存储，包括对象存储、云盘存储、文件存储等，还有使用云产品的费用。近几年，GPU 和 GPU 所需的高性能设备成本也逐渐上涨，此外还有一些像安全产品、专线费用等更细致的项目。实际上这些项目成本多达几十项，甚至上百项。企业要想梳理清楚这些成本并不容易。
在 2021 年之前，云厂商只是事后生成账单，并没有考虑到让企业更加可控地管理成本。而且这个账单也很难对应到具体业务。每个产品至少有四、五个计费项，如果用几十个产品，就是数百个计费项，假设公司有几十个业务，则很难判断每个业务花多少钱。
现实中，企业存在相当大的资源浪费。比如业务变化对 CPU 的使用情况是不同的，但不及时调整策略就会产生很大的浪费；又如后端并非必须要记录大数据，长期保存这些日志对公司收益无益反而会增加成本。
为了适应降本增效的大趋势，各家云厂商，甚至独立的第三方、开源社区等，都陆续推出了一些 FinOps 工具。但现在的 FinOps 工具主要针对 CPU 等主要成本项目，其他科目的计费工具比较少，并不能满足企业对网络、存储及更深层次 PaaS 等不同产品成本的分析需求。
几个建议
现在的降本更多还是要依靠企业自己。作业帮基础架构负责人董晓聪介绍，他们现在一方面给产生成本的项目 " 瘦身 "，比如基础研发与业务线共同定期梳理计算、存储等开销，只保留有价值的部分；另一方面，利用每年硬件厂商释放的一些红利，周期性地进行主力机型替换。
更重要的是，他们建立了更全面的 FinOps 成本管理体系，主要包括成本洞察、成本优化和成本运营三方面：
清晰地记录成本账单，像各产品科目、业务之间是否共享服务等都要明确。他们会生成多种类型的账单，包括云厂商支付账单以及内部研发部门的实际使用账单，这些账单会被归结到具体业务线，计算其使用回报率（ROI）；
通过容器增加集群负载、离线混部等提升利用率和使用效率，引入了各种新技术进行成本优化；
通过年度预算机制和每月审查，找出浪费或与预算不匹配的地方，并进行优化等。这些措施帮助企业许多业务线的成本节省了 40%，预计未来每年会有千万级别优化。
AutoMQ 联合创始人兼 CTO 周新宇则借助 FinOps 思想，强制作出一些资源创建前置管理的规定，比如用 S3 时不能用公网、用 EC2 时必须用 Spot 实例等，还有其他的节省规划。同时，借助开源工具 Infracost 进行成本实时监控，他们可以在 PR 里面清晰地了解到一旦某代码合并到主干后，云账单会增加或会减少多少，这样企业可以在每一次代码提交时候就能量化云资源成本，而不是季度结束后才收到一个账单。
另外，用户使用云产品要养成一个习惯，就是先去看它的计费项，即什么地方会收钱，其次要看这个产品的限制和边界是什么。由于技术不够完备，很多云产品都有用户想象不到的限制，比如资源数量或单个资源带宽等。因此，用户不仅要算钱，还要看自己的需求在不在产品服务范围内。
Datastrato 创始人兼 CEO 堵俊平则建议，企业要制定更为有效的产品采购策略和选择策略，避免盲目地被销售人员引导。企业选产品的时候不要只看广告，也不能完全依赖第三方报告，而要关注实际场景，找出适合自己工作负载情况的产品。企业可以利用产品推广期提供的免费试用，按需使用一段时间，发现产品不合适时可以迅速切换或回退。
三、有完美方案吗？
不能否认的是，用好云本来就是一件很有难度的事情，除了本身的技术问题，更难的是与千变万化的业务结合。
云厂商做云产品时，要面对数十万用户和各种各样的场景，一个能满足所有流量模型的体系化产品肯定是非常复杂的，云厂商的职责之一就是抹平这些差异，当然这方面云厂商做得并不好。
对企业来说，只做基本操作、处理简单的业务场景还可以应付，一旦涉及到大规模应用，企业在以 K8s 为基础的云架构在运维和管理方面就会遇到相当复杂的问题，一些原有调度器组件可能无法满足需求，需要企业做自定义组件的开发，甚至包括对 K8s 底层结构做深度调整。
完全自建，不是普通玩家的游戏
但完全下云、自建 IDC 这种方式也并不能解决问题。
国外比国内更早提下云，是因为国外的 IDC 和云的价格差异较大，国内云厂商比传统 IDC 更有价格优势。国外的 IDC 服务运营机构通常也提供更为全面的服务，企业可以将很多 ToB 的云管理能力外包。此外，国外做 ToB 云端软件企业更加成熟、工具链相对更为完备，企业自建可以获得更好的体验。
但是，自建 IDC 是有门槛的：对于百万级机器规模以内的企业，无论从扩展性、更高效运维，还是更先进的基础设施角度，云计算是成本效益最优的选择。
一旦企业规模超过百万级，尤其是在拥有相对完善的机房设施和系统运维团队情况下，有的大型企业，如快手和拼多多，就会逐步考虑从云上迁移到自建 IDC，这个阶段的企业在采购和供应链方面也拥有了一定的优势。
AutoMQ 联合创始人兼首席战略官章文嵩在直播节目里就算过这样一笔账：考虑到硬件、托管和网络带宽资源等成本，每台机器年均花费约 2 万元， 5 万台服务器的话就要花费约 10 亿元。此外，自建还有构建分布式系统、操作系统和数据库等的额外投入，而维护一个六七百人的研发团队的成本就高达 5 亿。
其实，在使用云的基础能力方面，IDC 和云没有太大区别。IDC 的基本构建包括租用机房、购买机器、搭建交换设备、申请公网 IP、引导流量到负载设备以及在机器上部署服务等。IDC 可以看作是一个基础建设的雏形，云计算大大简化了这个过程，用户只需点击即可创建一个高性能的 VPC 网络，无需处理排线等问题。
上云和自建 IDC 的关键区别在于，像操作系统内核这样的基础设施，云厂商通常有规模庞大的内核团队来不断升级稳定性，而自建 IDC 可能使用开源内核，企业需要自己承担内核维护的各种成本。
但自建 IDC 最大的问题可能是没人。一个完整的自建系统通常需要三个团队：研发、测试和运维。这意味着企业通常需要基于开源软件从零开始构建技术栈，这要求工程师熟悉开源软件技术栈的使用和运维，并不断跟踪社区的动态。要找到胜任下云工作的运维人员相当有挑战，这一领域的人才需要长期积累的经验和技能，优秀的 SRE 人才更是难得一见。而硬件工程师的稀缺性更不用说。
因此，除非企业是为了核心业务、愿意且能够投入足够的资源（包括招聘高水平的工程师、购置硬件和维护系统等），以及具有成本效益时选择自建才是合适的。
现在业内基本共识是刚成立的创业公司或新开展的业务一定是上云。对于存量业务上云还是自建，当业务和团队在相当一段时间里都比较稳定、并满足上述条件时，自建机房未尝不可。当团队不稳定或者业务有增长机会时，考虑分阶段增量式上云更为稳妥。
多云、混合云可以吗？
相对于完全下云，另一种中庸的方式是多云和混合云。
在多云和混合云的情况下，业界通常提供了相应的解决方案，甚至逐渐形成了标准化的方案。多云可以解决云厂商锁定问题，并通过平衡云服务的采购来优化成本，获取更多议价空间。
不过，多云的选择也没有统一标准，企业需要考虑的因素有很多，比如要结合自己的业务特性和成本方面考虑选择、要确保数据在不同云上不会形成孤岛、仔细评估和选择产品等。
有的企业可能一开始使用某个云厂商的产品，但后来发现其他云厂商有更好、更稳定的产品，这种情况下，企业可能会调整其多云策略来获取更好的服务。还有企业并购后做业务整合时，可能考虑多云策略来协同工作；另外在国际化和出海业务中，企业需要根据不同地区的情况选择云服务。
另外根据 IDC 最新报告，混合云已经成为市场中主流的云基础架构部署形态。混合云架构是本地、私有云和第三方公有云平台的统筹安排，对多云协同管理和跨云一致性进行了更多的优化，从而得到更多大型政企的青睐。当然，混合云架构带来的复杂度、安全等问题也需要引起重视。
多云、混合云都是一个渐进的过程，像今日头条尽管采用了火山引擎，但仍有一部分业务会在阿里云上运行。
云厂商的 " 下云费 "
但是，无论选择下云还是多云，云厂商都设置了门槛，比如数据出口费。数据出口费针对的就是企业上传数据的云存储位置移动或转移，与云存储和计算费是分开的。也就是说企业上云畅通无阻，转移或离开云还要最后被 " 砍一刀 "。
有数据显示，数据出口费用已经影响到 34% 的云存储使用企业。DHH 就表示，他们下云的 " 出口费 " 在 30 万至 40 万美元之间。
谷歌云日前率先宣布取消了这笔费用，并抨击了这种做法：某些传统厂商利用本地软件垄断来创造云垄断，使用限制性许可的做法来锁定客户并扭曲竞争。具体方式包括限制客户的合作对象和合作方式；如果客户决定使用某竞争对手的云服务，则收取 5 倍的费用；并限制必备软件与竞争对手云基础设施的互操作性等。
" 这些限制并没有什么技术基础，但可能会让客户的支出增加 300%。" 谷歌云平台主管 Amit Zavery 坦承，取消这些收费最终会让用户更容易转向竞争对手，但不公平的许可对市场竞争构成了更大的威胁。
虽然谷歌这一决定背后肯定有其他利益考虑，但就像 DHH 说的：谁在乎！用户想要的只是自由上下云而已。
四、结束语
如今，上云进程最快的就是互联网或者泛互联网的企业、国内有出海业务的企业、一些新的制造业如汽车。这些企业有一些特征：数据量大、业务创新快、高增长、有典型的互联网企业特征。云计算对这些企业来说价值巨大，因为他们能用非常低的资源保有成本应对未来高增长的业务预期。
但根据受访专家估算，国内上云的进度应该是小于 10% 的，因为对很多企业，尤其传统企业来说，上云不会带来更多的价值。可以看如下的 " 价值公式 "：
新技术决策带来的价值 = 新价值 - 旧价值 - 迁移成本
很明显，IT 设施的决策成本和迁移成本是巨大的，这种情况下要吸引这类型企业上云就要价值足够大，并且是数量级优势，否则打动不了企业作出重大的架构改变。只有精准命中痛点，企业才会义无反顾地上云。
但现在云计算的种种问题确实还没有一个完美的解决方案，企业更多还是选择各种方式并存的策略。云技术还需要不断进行持续的迭代，这种迭代是多方面的，包括产品功能的不断完善、通过规模化优势优化成本等。
未来，云厂商欠下的种种技术债势必是要还上的，而企业要做的上云功课也必须得补上。
采访嘉宾（按姓名首字母排序）：
堵俊平，Datastrato 公司创始人兼 CEO，Apache 软件基金会 Member，LF AI & DATA 基金会前主席，前华为云与计算开源总经理，前腾讯开源联盟主席。在云计算、大数据与人工智能、开源等领域有超过 15 年的研发和管理经验。
董晓聪，作业帮基础架构负责人，阿里云 MVP、腾讯云 TVP。曾在百度、滴滴等公司负责架构和技术管理工作，擅长业务中台、技术中台、研发中台的搭建和迭代。2019 年加入作业帮，主要负责架构研发、运维、DBA、安全等工作。主导完成作业帮技术体系的云原生重塑，全面推动公司在质量、效率、安全、成本等方面的建设。
周新宇，AutoMQ 联合创始人 & CTO，是 Apache 软件基会成员，Apache RocketMQ 联合创始 & PMC 成员。目前致力于引领消息和流存储走向云原生时代，利用云的能力为 Kafka 带来十倍的成本优势，是云原生上云理念的倡导者。
发布评论