云计算泥石流
曾几何时，“上云“近乎成为技术圈的政治正确，整整一代应用开发者的视野被云遮蔽。就让我们用实打实的数据分析与亲身经历，讲清楚公有云租赁模式的价值与陷阱 —— 在这个降本增效的时代中，供您借鉴与参考。
云商业模式篇
下云奥德赛篇
云厂商画像篇
世人常道云上好，托管服务烦恼少。
我言云乃杀猪盘，溢价百倍实厚颜。
赛博地主搞垄断，坐地起价剥血汗。
运维外包嫖开源，租赁电脑炒概念。
世人皆趋云上游，不觉开销似水流。
云租天价难为持，开源自建更稳实。
下云先锋把路趟，引领潮流一肩扛。
不畏浮云遮望眼，只缘身在最前线。
曾几何时，“上云“近乎成为技术圈的政治正确，整整一代应用开发者的视野被云遮蔽。DHH 以及像我这样的人愿意成为这个质疑者，用实打实的数据与亲身经历，讲清楚公有云租赁模式的陷阱。
很多开发者并没有意识到，底层硬件已经出现了翻天覆地的变化，性能与成本以指数方式攀升与坍缩。许多习以为常的工作假设都已经被打破，无数利弊权衡与架构方案值得重新思索与设计。
公有云有其存在意义 —— 对那些非常早期、或两年后不复存在的公司，那些完全不在乎花钱、有着极端大起大落不规则负载的公司，对那些需要出海合规，CDN服务的公司而言，公有云仍然是非常值得考虑的选项。
然而对绝大多数已经发展起来，有一定规模与韧性，能在几年内摊销资产的公司而言，真的应该重新审视一下这股云热潮。好处被大大夸张了 —— 在云上跑东西通常和你自己弄一样复杂，却贵得离谱，我们真诚建议您好好算一下账。
最近十年间，硬件以摩尔定律的速度持续演进，IDC2.0与资源云提供了公有云资源的物美价廉替代，开源软件与开源管控调度软件的出现更是让自建能力唾手可及 —— 云下开源自建，在成本，性能，与安全自主可控上都会有显著回报。
我们提倡下云理念，并提供了实践的路径与切实可用的自建替代品 —— 我们将为认同这一结论的追随者提前铺设好意识形态与技术上的道路。不为别的，只是期望所有用户都能拥有自己的数字家园，而不是从科技巨头云领主那里租用农场。这也是一场对互联网集中化与反击赛博地主垄断收租的运动，让互联网 —— 这个美丽的自由避风港与理想乡可以走得更长。
云基础资源篇
EC2 / S3 / EBS 这样的基础资源价格，是所有云服务的定价之锚。基础资源篇的五篇文章，分别剖析了 EC2 算力，S3 对象存储，EBS 云盘，RDS 云数据库，以及 CDN 网络的方方面面：质量、安全、效率，以及大家最关心的一系列问题。
云商业模式篇
FinOps关注点跑偏，公有云是个杀猪盘
自建能力决定议价权，数据库是自建关键
下云奥德赛篇
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 给出了自己充满洞见的回复。
阿里云 11. 12 大故障两周 过去，还没有看到官方的详细复盘报告，结果又来了一场大故障：中美7个区域的数据库管控宕了近两个小时。这一次和 11.12 故障属于让官方发全站公告的显著故障。
11月份还有两次较小规模的局部故障。这种故障频率即使是对于草台班子来说也有些过分了。某种意义上说，阿里云这种周爆可以凭一己之力，毁掉用户对公有云云厂商的托管服务的信心
时隔一年阿里云又出大故障，并创造了云计算行业闻所未闻的新记录 —— 全球所有区域/所有服务同时异常。
阿里云不愿意发布故障复盘报告，那我就来替他复盘 —— 我们应当如何看待这一史诗级故障案例，以及，能从中学习到什么经验与教训？
我希望，未来的世界人人都有自由使用优秀服务的事实权利，而不是只能被圈养在几个公有云厂商提供的猪圈（Pigsty）里吃粑粑。这就是我要做 Pigsty 的原因 —— 一个更好的，开源免费的 PostgreSQL RDS替代。让用户能够在任何地方（包括云服务器）上，一键拉起有比云RDS更好的数据库服务。
Pigsty 是对 PostgreSQL 的彻底补完，更是对云数据库的辛辣嘲讽。它本意是“猪圈”，但更是 Postgres In Great STYle 的缩写，即“全盛状态下的 PostgreSQL”。它是一个完全基于开源软件的，可以运行在任何地方的，浓缩了 PostgreSQL 使用管理最佳实践的 Me-Better RDS 开源替代。
云计算鼓吹者马工大放厥词说：云数据库可以取代 DBA。之前在《你怎么还在招聘DBA》，以及回应文《云数据库是不是智商税》中，我们便已交锋过。
当别人把屎盆子扣在这个行业所有人头上时，还是需要人来站出来说几句的。因此撰文以驳斥马工的谬论：《再论为什么你不应该招DBA》。
用户都已经花钱买了‘开箱即用’的云数据库了，为什么连 PITR 恢复这么基本的兜底都没有呢？因为云厂商心机算计，把WAL日志归档/PITR这些PG的基础功能阉割掉，放进所谓的“高可用”版本高价出售。
云数据库也是数据库，云数据库并不是啥都不用管的运维外包魔法，不当配置使用，一样会有数据丢失的风险。没有开启WAL归档就无法使用PITR，甚至无法登陆服务器获取现存WAL来恢复误删的数据。当故障发生时，用户甚至被断绝了自救的可能性，只能原地等死。
Kubernetes 作为一个先进的容器编排工具，在无状态应用管理上非常趁手；但其在处理有状态服务 —— 特别是 PostgreSQL 和 MySQL 这样的数据库时，有着本质上的局限性。
将数据库放入 K8S 中会导致“双输” —— K8S 失去了无状态的简单性，不能像纯无状态使用方式那样灵活搬迁调度销毁重建；而数据库也牺牲了一系列重要的属性：可靠性，安全性，性能，以及复杂度成本，却只能换来有限的“弹性”与资源利用率 —— 但虚拟机也可以做到这些！对于公有云厂商之外的用户来说，几乎都是弊远大于利。
对于无状态的应用服务而言，容器是一个相当完美的开发运维解决方案。然而对于带持久状态的服务 —— 数据库来说，事情就没有那么简单了。我认为就目前而言，将生产环境数据库放入Docker / K8S 中仍然是一个馊主意。
对于云厂商来说，使用容器的利益是自己的，弊端是用户的，他们有动机这样去做，但这样的利弊权衡对普通用户而言并不成立。
云厂商画像篇
这个系列多数来自云计算鼓吹者马工，为本土云厂商与互联网大厂绘制了精准幽默，幽默滑稽的肖像。
点一个关注⭐️，精彩不迷路