云计算泥石流
曾几何时，“上云“近乎成为技术圈的政治正确，整整一代应用开发者的视野被云遮蔽。就让我们用实打实的数据分析与亲身经历，讲清楚公有云租赁模式的价值与陷阱 —— 在这个降本增效的时代中，供您借鉴与参考。
云基础资源篇
云商业模式篇
下云奥德赛篇
云故障复盘篇
RDS翻车篇
云厂商画像篇
【转载】
序
世人常道云上好，托管服务烦恼少。
我言云乃杀猪盘，溢价百倍实厚颜。
赛博地主搞垄断，坐地起价剥血汗。
运维外包嫖开源，租赁电脑炒概念。
世人皆趋云上游，不觉开销似水流。
云租天价难为持，开源自建更稳实。
下云先锋把路趟，引领潮流一肩扛。
不畏浮云遮望眼，只缘身在最前线。
曾几何时，“上云“近乎成为技术圈的政治正确，整整一代应用开发者的视野被云遮蔽。DHH 以及像我这样的人愿意成为这个质疑者，用实打实的数据与亲身经历，讲清楚公有云租赁模式的陷阱。
很多开发者并没有意识到，底层硬件已经出现了翻天覆地的变化，性能与成本以指数方式攀升与坍缩。许多习以为常的工作假设都已经被打破，无数利弊权衡与架构方案值得重新思索与设计。
公有云有其存在意义 —— 对那些非常早期、或两年后不复存在的公司，那些完全不在乎花钱、有着极端大起大落不规则负载的公司，对那些需要出海合规，CDN服务的公司而言，公有云仍然是非常值得考虑的选项。
然而对绝大多数已经发展起来，有一定规模与韧性，能在几年内摊销资产的公司而言，真的应该重新审视一下这股云热潮。好处被大大夸张了 —— 在云上跑东西通常和你自己弄一样复杂，却贵得离谱，我们真诚建议您好好算一下账。
最近十年间，硬件以摩尔定律的速度持续演进，IDC2.0与资源云提供了公有云资源的物美价廉替代，开源软件与开源管控调度软件的出现更是让自建能力唾手可及 —— 云下开源自建，在成本，性能，与安全自主可控上都会有显著回报。
我们提倡下云理念，并提供了实践的路径与切实可用的自建替代品 —— 我们将为认同这一结论的追随者提前铺设好意识形态与技术上的道路。不为别的，只是期望所有用户都能拥有自己的数字家园，而不是从科技巨头云领主那里租用农场。这也是一场对互联网集中化与反击赛博地主垄断收租的运动，让互联网 —— 这个美丽的自由避风港与理想乡可以走得更长。
云基础资源篇
EC2 / S3 / EBS 这样的基础资源价格，是所有云服务的定价之锚。基础资源篇的五篇文章，分别剖析了 EC2 算力，S3 对象存储，EBS 云盘，RDS 云数据库，以及 CDN 网络的方方面面：质量、安全、效率，以及大家最关心的一系列问题。
在当下，硬件重新变得有趣起来，AI 浪潮引发的显卡狂热便是例证。但有趣的硬件不仅仅是 GPU —— CPU 与 SSD 的变化却仍不为大多数开发者所知，有一整代软件开发者被云和炒作营销遮蔽了双眼，难以看清这一点。
许多软件与商业领域的问题的根都在硬件上：硬件的性能以指数模式增长，让分布式数据库几乎成为了伪需求。硬件的价格以指数模式衰减，让公有云从普惠基础设施变成了杀猪盘。让我们用算力与存储的价格变迁来说明这一点。
对象存储是云计算的定义性服务，曾是云上降本的典范。然而随着硬件的发展，资源云（Cloudflare / IDC 2.0）与开源平替（MinIO）的出现，曾经“物美价廉”的对象存储服务失去了性价比，和EBS一样成为了杀猪盘。
硬件资源的价格随着摩尔定律以指数规律下降，但节省的成本并没有穿透云厂商这个中间层，传导到终端用户的服务价格上。 逆水行舟，不进则退，降价速度跟不上摩尔定律就是其实就是变相涨价。以S3为例，在过去十几年里，云厂商S3虽然名义上降价6倍，但硬件资源却便宜了 26 倍，S3 的价格实际上是涨了 4 倍。
EC2 / S3 / EBS 是所有云服务的定价之锚。如果说 EC2/S3 定价还勉强能算合理，那么 EBS 的定价乃是故意杀猪。公有云厂商最好的块存储服务与自建可用的 PCI-E NVMe SSD 在性能规格上基本相同。然而相比直接采购硬件，AWS EBS 的成本高达 120 倍，而阿里云的 ESSD 则可高达 200 倍。
公有云的弹性就是针对其商业模式设计的：启动成本极低，维持成本极高。低启动成本吸引用户上云，而且良好的弹性可以随时适配业务增长，可是业务稳定后形成供应商锁定，尾大不掉，极高的维持成本就会让用户痛不欲生了。这种模式有一个俗称 —— 杀猪盘。
近日，Basecamp & HEY 联合创始人 DHH 的一篇文章引起热议，主要内容可以概括为一句话：“我们每年在云数据库（RDS/ES）上花50万美元，你知道50万美元可以买多少牛逼的服务器吗？我们要下云，拜拜了您呐！“
在专业甲方用户眼中，云数据库只能算 60 分及格线上的大锅饭标品，却敢于卖出十几倍的天价资源溢价。如果用云数据库1年的钱，就够买几台甚至十几台性能更好的服务器自建更好的本地 RDS，那么使用云数据库的意义到底在哪里？在有完整开源平替的情况下，这算不算交了智商税？
本来我相信至少在 IaaS 的存储，计算，网络三大件上，公有云厂商还是可以有不小优势的。只不过在腾讯云 CDN 上的亲身体验让我的想法动摇了。
云商业模式篇
FinOps关注点跑偏，公有云是个杀猪盘
自建能力决定议价权，数据库是自建关键
搞 FinOps 的关注减少浪费资源的数量，却故意无视了房间里的大象 —— 云资源单价。云算力的成本是自建的五倍，块存储的成本则可达百倍以上，堪称终极成本刺客。对于有一定规模企业来说，IDC自建的总体成本在云服务列表价1折上下。下云是原教旨 FinOps 的终点，也是真正 FinOps 的起点。
拥有自建能力的用户即使不下云也能谈出极低的折扣，没有自建能力的公司只能向公有云厂商缴纳高昂的 “无专家税” 。无状态应用与数仓搬迁相对容易，真正的难点是在不影响质量安全的前提下，完成数据库的自建。
公有云毛利不如挖沙子，杀猪盘为何成为赔钱货？
卖资源模式走向价格战，开源替代打破垄断幻梦。
服务竞争力逐渐被抹平，云计算行业将走向何方？
业界标杆的 AWS 与 Azure 毛利就可以轻松到 60% 与 70% 。反观国内云计算行业，毛利普遍在个位数到 15% 徘徊，至于像金山云这样的云厂商，毛利率直接一路干到 2.1%，还不如打工挖沙子的毛利高。这不禁让人好奇，这些本土云厂商是怎么把一门百分之三四十纯利的生意能做到这种地步的？
在云计算的世界里，服务等级协议（SLA）曾被视为云厂商对其服务质量的承诺。然而，当我们深入研究这些由一堆9组成的 SLA 时，会发现它们并不能像期望的那样“兜底”：与其说是 SLA 是对用户的补偿，不如说 SLA 是对云厂商服务质量没达标时的“惩罚”。
你以为给自己的服务上了保险可以高枕无忧，但 SLA 对用户来说不是兜底损失的保险单。在最坏的情况下，它是吃不了兜着走的哑巴亏。在最好的情况下，它才是提供情绪价值的安慰剂。
存算资源降价跟不上摩尔定律发展其实就是变相涨价。但能看到有云厂商率先打起了降价第一枪，还是让人欣慰的：云厂商向 PLG 的康庄大道迈出了第一步：用技术优化产品，靠提高效率去降本，而不是靠销售吹逼打折杀猪。
软件吞噬世界，开源吞噬软件。云吞噬开源，谁来吃云？与云软件相对应的本地优先软件开始如雨后春笋一般出现。而我们，就在亲历见证这次范式转移。
最终会有这么一天，公有云厂商与自由软件世界达成和解，心平气和地接受基础设施供应商的角色定位，为大家提供水与电一般的存算资源。而云软件终将会回归正常毛利，希望那一天人们能记得人们能记得，这不是因为云厂商大发慈悲，而是因为有人带来过开源平替。
下云奥德赛篇
下云先锋：David Heinemeier Hansson，网名 DHH，37 Signal 联创与CTO，Ruby on Rails 作者，下云倡导者、实践者、领跑者。反击科技巨头垄断的先锋。
我们翻译了下云先锋 DHH 的十篇博客文章，合辑为《下云奥德赛》，记录了他们从云上搬下来的完整旅程。后续更新《是时候放弃云计算了吗？》提供了额外五篇最新更新。
DHH 下云已省下了近百万美元云支出，未来的五年还能省下上千万美元。我们跟进了下云先锋的最新进展，新挑选了五篇博文，译为中文以飨读者。
10-27 推特下云省掉 60% 云开销
10-06 托管云服务的代价
09-15 下云后已经省了百万美金
06-23 我们已经下云了！
05-03 从云遣返到主权云！
05-02 下云还有性能回报？
04-06 下云所需的硬件已就位！
03-23 裁员前不先考虑下云吗？
03-11 失控的不仅仅是云成本！
02-22 指导下云的五条价值观
02-21 下云将给咱省下五千万！
01-26 折腾硬件的乐趣重现
01-10 “企业级“替代品还要离谱
2022-10-19 我们为什么要下云？
下云之后，DHH 的几个业务都保持了 99.99% 以上的可用性。Basecamp 2 更是连续两年实现 100%可用性的魔法。相当一部分归功于他们选择了简单枯燥、朴实无华的，复杂度很低，成熟稳定的技术栈 —— 他们并不需要 Kubernetes 大师或花哨的数据库与存储。
程序员极易被复杂度所吸引，就像飞蛾扑火一样。系统架构图越复杂，智力自慰的快感就越大。坚决抵制这种行为，是在云下自建保持稳定可靠的关键所在。
DHH 与 X马斯克的下云举措在全球引发了激烈的讨论，有许多的支持者，也有许多的质疑者。面对众人提出的问题与质疑，DHH 给出了自己充满洞见的回复。
在硬件上省下的成本，会不会被更大规模的团队薪资抵消掉？
为什么你选择下云，而不是优化云账单呢？
你有没有试过用“云原生”应用的方式上云？
那么安全性呢？你不担心被黑客攻击吗？
不需要一支世界级超级工程师团队来干这些吗？
这是否意味着你们在建造自己的数据中心？
谁来做码放服务器、拔插网络电缆这些活呢？
那么可靠性呢？难道云不是为你做到了这些吗？
那国际化业务的性能呢？云不是更快吗？
你有考虑到以后更换服务器的成本吗？
那么隐私法规和GDPR呢？
那么需求激增时怎么办？自动伸缩呢？
你在服务合同和授权许可费上花费了多少？
如果云这么贵，你们为什么会选择它？
云故障复盘篇
2023年11月12日，也就是双十一后的第一天，阿里云发生了一场史诗级大翻车。根据阿里云官方的服务状态页，全球范围内所有可用区 x 所有服务全部都出现异常，时间从 17:44 到 21: 11，共计3小时27分钟。规模与范围创下全球云计算行业的历史纪录。
阿里云 11. 12 大故障两周 过去，还没有看到官方的详细复盘报告，结果又来了一场大故障：中美7个区域的数据库管控宕了近两个小时。这一次和 11.12 故障属于让官方发全站公告的显著故障。
11月份还有两次较小规模的局部故障。这种故障频率即使是对于草台班子来说也有些过分了。某种意义上说，阿里云这种周爆可以凭一己之力，毁掉用户对公有云云厂商的托管服务的信心
时隔一年阿里云又出大故障，并创造了云计算行业闻所未闻的新记录 —— 全球所有区域/所有服务同时异常。
阿里云不愿意发布故障复盘报告，那我就来替他复盘 —— 我们应当如何看待这一史诗级故障案例，以及，能从中学习到什么经验与教训？
双十一刚过，阿里云就出了打破行业纪录的全球史诗级大翻车，然后开始了11月连环炸模式 —— 从月爆到周爆再到日爆。话音未落，滴滴又出现了一场超过12小时，资损几个亿的大故障。
年底正是冲绩效的时间，互联网大厂大事故却是一波接一波。硬生生把降本增效搞成了“降本增笑” —— 这已经不仅仅是梗了，而是来自官方的自嘲。大厂故障频发，处理表现远远有失水准，乱象的背后到底是什么问题？
RDS翻车篇
我希望，未来的世界人人都有自由使用优秀服务的事实权利，而不是只能被圈养在几个公有云厂商提供的猪圈（Pigsty）里吃粑粑。这就是我要做 Pigsty 的原因 —— 一个更好的，开源免费的 PostgreSQL RDS替代。让用户能够在任何地方（包括云服务器）上，一键拉起有比云RDS更好的数据库服务。
Pigsty 是对 PostgreSQL 的彻底补完，更是对云数据库的辛辣嘲讽。它本意是“猪圈”，但更是 Postgres In Great STYle 的缩写，即“全盛状态下的 PostgreSQL”。它是一个完全基于开源软件的，可以运行在任何地方的，浓缩了 PostgreSQL 使用管理最佳实践的 Me-Better RDS 开源替代。
用户都已经花钱买了‘开箱即用’的云数据库了，为什么连 PITR 恢复这么基本的兜底都没有呢？因为云厂商心机算计，把WAL日志归档/PITR这些PG的基础功能阉割掉，放进所谓的“高可用”版本高价出售。
云数据库也是数据库，云数据库并不是啥都不用管的运维外包魔法，不当配置使用，一样会有数据丢失的风险。没有开启WAL归档就无法使用PITR，甚至无法登陆服务器获取现存WAL来恢复误删的数据。当故障发生时，用户甚至被断绝了自救的可能性，只能原地等死。
Kubernetes 作为一个先进的容器编排工具，在无状态应用管理上非常趁手；但其在处理有状态服务 —— 特别是 PostgreSQL 和 MySQL 这样的数据库时，有着本质上的局限性。
将数据库放入 K8S 中会导致“双输” —— K8S 失去了无状态的简单性，不能像纯无状态使用方式那样灵活搬迁调度销毁重建；而数据库也牺牲了一系列重要的属性：可靠性，安全性，性能，以及复杂度成本，却只能换来有限的“弹性”与资源利用率 —— 但虚拟机也可以做到这些！对于公有云厂商之外的用户来说，几乎都是弊远大于利。
对于无状态的应用服务而言，容器是一个相当完美的开发运维解决方案。然而对于带持久状态的服务 —— 数据库来说，事情就没有那么简单了。我认为就目前而言，将生产环境数据库放入Docker / K8S 中仍然是一个馊主意。
对于云厂商来说，使用容器的利益是自己的，弊端是用户的，他们有动机这样去做，但这样的利弊权衡对普通用户而言并不成立。
云厂商画像篇
这个系列多数来自云计算鼓吹者马工，为本土云厂商与互联网大厂绘制了精准幽默，
幽默滑稽的肖像。
点一个关注⭐️，精彩不迷路
阅读原文 最新评论
推荐文章
作者最新文章
你可能感兴趣的文章
Copyright Disclaimer: The copyright of contents (including texts, images, videos and audios) posted above belong to the User who shared or the third-party website which the User shared from. If you found your copyright have been infringed, please send a DMCA takedown notice to [email protected]. For more detail of the source, please click on the button "Read Original Post" below. For other communications, please send to [email protected].
版权声明：以上内容为用户推荐收藏至CareerEngine平台，其内容（含文字、图片、视频、音频等）及知识版权均属用户或用户转发自的第三方网站，如涉嫌侵权，请通知[email protected]进行信息删除。如需查看信息来源，请点击“查看原文”。如需洽谈其它事宜，请联系[email protected]。
版权声明：以上内容为用户推荐收藏至CareerEngine平台，其内容（含文字、图片、视频、音频等）及知识版权均属用户或用户转发自的第三方网站，如涉嫌侵权，请通知[email protected]进行信息删除。如需查看信息来源，请点击“查看原文”。如需洽谈其它事宜，请联系[email protected]。