该死的谷歌，我不想再写博客了。 我有很多事要做。 写博客需要时间、精力和创造力，我可以充分利用这些：我的书， ，我的游戏等等。 但你已经让我很生气了，所以我必须写这篇文章。
那么让我们结束这件事吧。
让我从我刚开始在谷歌工作时发生的一个简短但富有启发性的故事开始。 我知道我最近说了很多关于谷歌的坏话，但当我自己的公司经常做出不称职的商业决策时，我感到很沮丧。 与此同时，我们必须给予它应有的评价：谷歌的内部基础设施确实非常出色，可以肯定地说，今天没有比这更好的了。 谷歌的创始人是比我更优秀的工程师，这个故事只是证实了这一事实。
首先，介绍一下背景：谷歌有一种数据存储技术，称为 。 这是一项了不起的技术成就，是第一个（如果不是第一个）“无限可扩展”键值存储 (K/V) 之一：本质上是 NoSQL 的开始。 如今，Bigtable 在相当拥挤的 K/V 存储空间中仍然表现良好，但在当时（2005 年）它已经非常酷了。
Bigtable 的一个有趣的事情是，它们有称为 Tablet 服务器的内部控制平面对象（作为实现的一部分），具有很大的索引，并且在某些时候它们成为扩展系统时的瓶颈。 Bigtable 工程师正在困惑如何实现可扩展性，突然意识到他们可以用其他 Bigtable 存储来替代平板服务器。 所以Bigtable是Bigtable实现的一部分。 这些存储设施遍布各级。
另一个有趣的细节是，有一段时间 Bigtable 在 Google 内变得流行和普遍，每个团队都有自己的存储库。 因此，在周五的一次会议上，Larry Page 顺便问道：“为什么我们有不止一个 Bigtable？ 为什么不只一个呢？” 理论上，一个存储应该足以满足 Google 的所有存储需求。 当然，他们从来不会仅仅出于实际开发的原因（比如潜在失败的后果）而选择一个，但这个理论很有趣。 整个宇宙的一个存储库（顺便问一下，有人知道亚马逊是否对他们的 Sable 这样做过吗？)
无论如何，这是我的故事。
当时，我在 Google 工作了两年多，有一天我收到了一封来自 Bigtable 工程团队的电子邮件，内容如下：
亲爱的史蒂夫，
来自 Bigtable 团队的问候。 我们想通知您，在[数据中心名称]，您正在使用非常非常旧的 Bigtable 二进制文件。 该版本不再受支持，我们希望帮助您升级到最新版本。
如果您可以安排一些时间共同解决此问题，请告诉我。
一切顺利，
大表团队
在谷歌上你会收到很多邮件，所以乍一看我读到了这样的内容：
亲爱的收件人，
来自某个团队的问候。 我们想传达这样的信息：等等等等。 哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈哈
如果您可以安排一些宝贵的时间来进行等等，请告诉我们。
一切顺利，
某种命令
我几乎立刻就把它删除了，但在我意识的边缘，我感到一种痛苦的、挥之不去的感觉： 不太好 虽然看起来像一封正式的信 明显，收件人被误认为是因为我没有使用 Bigtable。
但这很奇怪。
那天剩下的时间里，我交替思考工作和在微型厨房里尝试什么样的鲨鱼肉，其中至少有三个离我的座位足够近，可以从我的座位上瞄准扔一块饼干，但是写作的想法从未让我感到越来越强烈的轻微焦虑。
他们清楚地说出了我的名字。 并且该电子邮件发送到我的电子邮件地址，而不是其他人的电子邮件地址，并且不是抄送：或密件抄送：。 语气非常个性化且清晰。 也许这是某种错误？
最后，好奇心战胜了我，我去看了他们提到的数据中心的 Borg 控制台。
当然，我还管理着 BigTable 存储。 对不起，什么？ 我看了看里面的内容，哇！ 它来自于 2005 年 XNUMX 月我在 Google 工作的第一周所在的 Codelab 孵化器。 Codelab 强迫你运行 Bigtable 在那里写入一些值，而且我显然在那之后从未关闭过存储。 尽管两年多过去了，它仍然有效。
这个故事有几个值得注意的方面。 首先，Bigtable 的工作对于 Google 的规模来说实在是微不足道，以至于两年后才有人注意到额外的存储空间，而且只是因为二进制版本已经过时了。 为了进行比较，我曾经考虑过使用 对于我的在线游戏。 当时，这项服务每年的费用约为 16 美元。 空的 GCP 上的 Bigtable。 我并不是说他们在欺骗你，但以我个人的观点，对于一个空的该死的数据库来说这是很多钱。
另一个值得注意的方面是存储 两年后仍在工作。 搞什么？ 数据中心来来去去； 它们会经历停电，进行定期维护，并且一直在变化。 硬件更新，交换机更换，一切都在不断改进。 他们到底是如何让我的程序在所有这些变化的情况下运行两年的？ 这在2020年看来是一个不起眼的成就，但在2005-2007年却是相当令人印象深刻。
最美妙的方面是，其他州的一个外部工程团队找到了我，我是 Bigtable 的某个小型、几乎空的实例的所有者，他拥有 零流量 过去两年 - 并提供更新帮助。
我感谢了他们，删除了存储，生活照常进行。 但十三年后，我仍然想起那封信。 因为有时我会收到来自 Google Cloud 的类似电子邮件。 它们看起来像这样：
尊敬的谷歌云用户，
谨此提醒，我们将于 2020 年 XNUMX 月起停止[您使用的基本服务]服务，此后您将无法升级实例。 我们建议升级到最新版本，该版本正处于 Beta 测试阶段，没有文档，没有迁移路径，并且在我们的帮助下已经过时了。
我们致力于确保这一变化对 Google Cloud 平台的所有用户的影响降到最低。
永远最好的朋友，
谷歌云平台
但我几乎从来没有读过这样的信，因为他们实际上说的是：
亲爱的收件人，
去死吧。 操你妈，操你，操你。 放弃你所做的一切，因为它并不重要。 重要的是我们的时间。 我们浪费时间和金钱来维护我们的垃圾，我们厌倦了它，所以我们不会再支持它。 所以放弃你他妈的计划，开始挖掘我们的垃圾文档，在论坛上乞讨碎片，顺便说一句，我们的新狗屎与旧狗屎完全不同，因为我们把这个设计搞砸了，嘿，但这就是你的问题，不是我们的。
我们将继续努力确保您的所有开发项目在一年内变得无法使用。
请滚蛋
谷歌云平台
事实上，我大约每月都会收到一次这样的信件。 这种情况发生得如此频繁和持续，以至于他们不可避免地 推开 我从 GCP 转到了反云阵营。 我不再同意依赖他们的专有开发，因为事实上，对于 DevOps 来说，在裸虚拟机上维护开源系统比试图跟上 Google 关闭“过时”产品的政策更容易。
在我返回 Google Cloud 之前，因为我 甚至接近 批评完了，我们再看看公司在其他一些方面的表现。 谷歌工程师对他们的软件工程学科感到自豪，而这正是导致问题的真正原因。 骄傲对于粗心的人来说是一个陷阱，它导致许多谷歌员工认为他们的决定总是正确的，并且正确（通过一些模糊的定义）比关心客户更重要。
我将随机给出一些来自 Google 之外的其他大型项目的示例，但我希望您能随处看到这种模式。 如下： 向后兼容性使系统能够保持数十年的活力和最新状态.
向后兼容性是所有成功系统的设计目标 开放 使用，即通过开源代码和/或开放标准实现。 我觉得我说的话太明显了，以至于每个人都感到不舒服，但事实并非如此。 这是一个政治问题，所以需要例子。
我选择的第一个系统是最古老的：GNU Emacs，它是 Windows 记事本、操作系统内核和国际空间站的混合体。 解释起来有点困难，但简而言之，Emacs 是一个创建于 1976 年（是的，差不多半个世纪前）的平台，用于编程以提高工作效率，但伪装成文本编辑器。
我每天都使用 Emacs。 是的，我也每天使用 IntelliJ，它本身已经发展成为一个强大的工具平台。 但是，为 IntelliJ 编写扩展是一项比为 Emacs 编写扩展更加雄心勃勃、更加复杂的任务。 更重要的是，为 Emacs 编写的所有内容都被保留 万古.
我仍然使用 1995 年为 Emacs 编写的软件。 我确信有人在 80 年代中期（如果不是更早的话）正在使用为 Emacs 编写的模块。 它们可能需要不时地进行一些调整，但这确实很少见。 我不知道我为 Emacs 编写过的任何内容（而且我已经写了很多）需要重新架构。
Emacs 有一个名为 make-obsolete 的函数，用于处理过时的实体。 用于基本计算机概念（例如“窗口”是什么）的 Emacs 术语通常与行业惯例不同，因为 Emacs 很久以前就引入了它们。 对于那些走在时代前沿的人来说，这是一个典型的危险：你所有的术语都是不正确的。 但 Emacs 确实有一个弃用的概念，用他们的行话来说就是 过时.
但在 Emacs 世界中似乎有不同的工作定义。 如果你愿意的话，这是一种不同的基本哲学。
在 Emacs 领域（以及我们将在下面介绍的许多其他领域），已弃用的 API 状态基本上意味着：“您确实不应该使用这种方法，因为虽然它有效，但它存在各种缺点，我们将在这里列出。 但归根结底，这是你的选择。”
在 Google 的世界里，过时意味着“我们违反了对您的承诺”。 这是真实的。 这就是它的本质意义。 这意味着他们会强迫你 经常 做一些工作，也许很多工作，作为对相信它们的惩罚 ：我们有最好的软件。 最快的！ 您按照说明执行所有操作，启动您的应用程序或服务，然后砰的一声，一两年后它就崩溃了。
就像卖二手车一样，1500公里后肯定会坏。
这是“过时”的两种完全不同的哲学定义。 谷歌对气味的定义 。 我不相信这个 其实 计划报废与苹果公司的含义相同。 但谷歌肯定计划以一种迂回的方式破坏你的程序。 我知道这一点是因为我在那里担任软件工程师超过 12 年。 他们对于应该遵循多少向后兼容性有模糊的内部指导方针，但这最终取决于每个团队或服务。 没有企业级或工程级建议，就过时周期而言最大胆的建议是“在破坏整个系统之前，尝试给客户 6-12 个月的时间进行升级。”
这个问题比他们想象的要严重得多，而且会持续多年，因为客户关怀并不在他们的基因里。 下面详细介绍这一点。
在这一点上，我要大胆声明，Emacs 在很大程度上是成功的，甚至是 基本上 因为他们非常重视向后兼容性。 事实上，这就是我们这篇文章的主题。 成功、长寿的开放系统的成功归功于在其周围生活了数十年的微型社区 扩展/插件。 这就是生态系统。 我已经讨论过平台的本质及其重要性，以及 Google 在其整个企业历史中从未了解过在 Android 或 Chrome 之外创建成功的开放平台需要什么。
实际上，我应该简单提一下 Android，因为您可能正在考虑它。
首先，将 安卓不是谷歌。 他们彼此几乎没有任何共同点。 Android 是一家于 2005 年 XNUMX 月被 Google 收购的公司，该公司被允许或多或少地自主运营，实际上在接下来的几年里基本上没有受到影响。 Android 是一个臭名昭著的技术堆栈，也是一个同样臭名昭著的多刺组织。 正如一位谷歌员工所说，“你不能只登录 Android。”
在上一篇文章中，我讨论了 Android 的一些早期设计决策有多么糟糕。 哎呀，当我写那篇文章时，他们正在推出名为“即时应用程序”的垃圾，现在（惊讶！） ，如果你愚蠢到听从谷歌并将你的内容转移到这些即时应用程序，我表示同情。
但这里有一个区别，一个显着的区别，那就是 Android 人真正了解平台的重要性，他们尽力让旧的 Android 应用程序继续运行。 事实上，他们为保持向后兼容性所做的努力是如此极端，以至于就连我，几年前在 Android 部门短暂工作期间，也发现自己试图说服他们放弃对一些最古老的设备和 API 的支持（我错了） ，就像过去和现在的许多其他事情一样。对不起 Android 家伙！既然我去过印度尼西亚，我明白为什么我们需要它们）。
Android 人员将向后兼容性推向了几乎难以想象的极端，在他们的系统和工具链中积累了大量的遗留技术债务。 天啊，你应该看到他们在构建系统中必须做的一些疯狂的事情，所有这些都是以兼容性的名义。
为此，我授予 Android 令人垂涎的“你不是 Google”奖。 他们真的不想成为不知道如何创建耐用平台的谷歌，但Android 他知道， 怎么做。 因此，谷歌在某一方面非常聪明：允许人们在 Android 上按照自己的方式做事。
然而，Android 的即时应用程序是一个非常愚蠢的想法。 你知道为什么吗？ 因为他们要求 重写和重新设计您的应用程序！ 就好像人们会简单地重写两百万个应用程序一样。 我猜即时应用程序是一些谷歌员工的想法。
但有一个区别。 向后兼容性的代价很高。 Android本身承担了这些费用，而谷歌则坚持由其承担 你，付费客户。
您可以在其 API 中看到 Android 对向后兼容性的承诺。 当您有四个或五个不同的子系统实际上执行相同的操作时，这是一个明确的信号，表明核心致力于向后兼容。 在平台世界中，这就是对客户和市场的承诺的代名词。
谷歌的主要问题是他们对自己的工程卫生感到自豪。 他们不喜欢有很多不同的方法来做同一件事，旧的、不太理想的方法与新的、更奇特的方法并存。 它增加了系统新手的学习曲线，增加了维护遗留 API 的负担，降低了新功能的速度，最主要的罪过是它不漂亮。 谷歌 - 就像蒂姆伯顿的爱丽丝梦游仙境中的阿斯科特女士一样：
阿斯科特女士：
- 艾丽丝，你知道我最害怕什么吗？
- 贵族的衰落？
- 我担心我会 丑陋的孙子.
为了理解美观与实用之间的权衡，让我们看一下第三个成功的平台（继 Emacs 和 Android 之后），看看它是如何工作的：Java 本身。
Java 有很多过时的 API。 弃用在 Java 程序员中非常流行，甚至比大多数编程语言中更流行。 Java 本身、核心语言和库都在不断地弃用 API。
仅举数千个例子之一， 被认为是过时的。 自 1.2 年 1998 月发布 Java 22 以来，它已被弃用。 自此被弃用以来已经过去 XNUMX 年了。
但我在生产中的实际代码仍然在杀死线程 天天。 你真的认为这样好吗？ 绝对地！ 当然，我的意思是，如果我今天重写代码，我会以不同的方式实现它。 但是我的游戏代码在过去二十年里让数十万人感到高兴，它是用一个函数编写的，可以关闭挂起时间过长的线程，而且我 从来不需要改变它。 我比任何人都更了解我的系统，我确实有 25 年在生产中使用它的经验，我可以肯定地说：就我而言，关闭这些特定的工作线程是完全可行的 无害。 不值得花费时间和精力来重写这段代码，并且感谢 Larry Ellison（可能）Oracle 没有强迫我重写它。
Oracle 可能也了解平台。 谁知道。
在整个核心 Java API 中都可以找到证据，这些 API 充满了过时的浪潮，就像峡谷中冰川的线条一样。 您可以在 Java Swing 库中轻松找到五六个不同的键盘导航管理器（KeyboardFocusManager）。 实际上很难找到一个未被弃用的 Java API。 但他们仍然有效！ 我认为，只有当接口带来明显的安全问题时，Java 团队才会真正删除 API。
事情是这样的，伙计们：我们软件开发人员都非常忙碌，在软件的每个领域我们都面临着竞争的替代品。 在任何给定时间，使用 X 语言的程序员都将语言 Y 视为可能的替代品。 哦，你不相信我吗？ 你想把它称为 Swift 吗？ 就像，每个人都在迁移到 Swift，没有人放弃它，对吗？ 哇，你知道的真少。 公司正在计算双移动开发团队（iOS 和 Android）的成本 - 他们开始意识到那些名字有趣的跨平台开发系统（如 Flutter 和 React Native）实际上可以工作，并且可以用来减少他们的规模移动团队的效率提高了一倍，或者相反，使他们的生产力提高了一倍。 这涉及真金白银。 是的，有妥协，但另一方面，是金钱。
让我们假设苹果愚蠢地接受了 Guido van Rossum 的暗示，并宣称 Swift 6.0 与 Swift 5.0 向后不兼容，就像 Python 3 与 Python 2 不兼容一样。
我大概十年前就讲过这个故事，但大约十五年前，我和 Guido 一起去了 O'Reilly 的 Foo Camp，和 Paul Graham 以及一群大人物坐在帐篷里。 我们坐在酷热的天气里等待拉里·佩奇乘坐他的私人直升机飞出去，而吉多则喋喋不休地谈论“Python 3000”，他以每个人迁移到那里需要的年数命名。 我们一直问他为什么要破坏兼容性，他回答说：“Unicode。” 我们问，如果我们必须重写代码，我们还会看到什么其他好处？ 他回答说：“Yooooooooooooooouuuuuuuniiiiiiicoooooooode。”
如果您安装 Google Cloud Platform SDK（“gcloud”），您将收到以下通知：
亲爱的收件人，
我们想提醒您，对 Python 2 的支持已被弃用，所以去你的吧
… 等等。 生活圈子。
但关键是每个开发人员都有选择。 如果你强迫他们足够频繁地重写代码，他们可能会考虑 其他 选项。 他们不是你的人质，无论你多么希望他们成为你的人质。 他们是你的客人。 Python 仍然是一种非常流行的编程语言，但是该死的，Python 3(000) 在其自身、其社区及其社区的用户中造成了如此混乱，其后果十五年来都没有得到解决。
由于这种向后不兼容性，有多少 Python 程序被用 Go（或 Ruby 或其他替代方案）重写？ 有多少新软件是用 Python 以外的语言编写的，尽管它 可能是 用 Python 写的，如果 Guido 没有烧毁整个村庄？ 很难说，但 Python 显然受到了影响。 这是一个巨大的混乱，每个人都输了。
因此，假设苹果公司受到 Guido 的启发并破坏了兼容性。 您认为接下来会发生什么？ 好吧，如果可能的话，也许 80-90% 的开发人员会重写他们的软件。 换句话说，10-20% 的用户群会自动转向某种竞争语言，例如 Flutter。
多次这样做，您将失去一半的用户群。 就像在体育运动中一样，在编程世界中，当前的形式也很重要。 所有。 任何在五年内失去一半用户的人都将被视为减肥大王。 你一定是平台世界里的潮流者。 但这是不支持旧版本随着时间的推移会毁掉你的地方。 因为每次你解雇一些开发人员时，你（a）永远失去他们，因为他们对你违反合同感到愤怒，并且（b）将他们交给你的竞争对手。
讽刺的是，当我创建 Grok 时，我还帮助 Google 成为了一个忽略向后兼容性的首席女主角，Grok 是一个源代码分析和理解系统，可以轻松自动化和检测代码本身 - 类似于 IDE，但这里是云服务存储大型数据仓库中所有数十亿行 Google 源代码的具体表示。
Grok 为 Google 员工提供了一个强大的框架，用于在整个代码库（实际上是整个 Google）中执行自动重构。 系统不仅计算你的上游依赖关系（你所依赖的），还计算你的上游依赖关系（你所依赖的） 下游的 （这取决于您）所以当您更改 API 时，您知道您正在破坏的每个人！ 这样，当您进行更改时，您可以验证 API 的每个使用者是否已更新到新版本，并且实际上，通常使用他们编写的 Rosie 工具，您可以完全自动化该过程。
这使得谷歌的代码库内部几乎是超自然的干净，因为他们有这些机器人仆人在房子里跑来跑去，如果他们将 SomeDespicouslyLongFunctionName 重命名为 SomeDespicouslyLongMethodName，就会自动清理所有东西，因为有人认为这是一个丑陋的孙子，他需要睡觉。
坦率地说，它对谷歌内部运作得非常好。 我的意思是，是的，Google 的 Go 社区确实与 Google 的 Java 社区笑得很开心，因为他们有持续重构的习惯。 如果你重新启动某件事 N 次，这意味着你不仅把它搞砸了 N-1 次，而且过了一段时间，很明显你可能在第 N 次尝试中也搞砸了它。 但是，总的来说，他们仍然最重要的是保持代码“干净”。
当他们试图将这种态度强加给他们的云客户端和其他 API 的用户时，问题就开始了。
我已经向您介绍了一些 Emacs、Android 和 Java； 让我们看看最新的成功且长期存在的平台：网络本身。 你能想象自 1995 年我们使用闪烁标签以来 HTTP 经历了多少次迭代？ 和网页上的“正在建设”图标。
但它仍然有效！ 而且这些页面仍然有效！ 是的，伙计们，浏览器是向后兼容性方面的世界冠军。 Chrome 是罕见的 Google 平台的另一个例子，它的头脑正确地拧紧了，正如您可能已经猜到的那样，Chrome 实际上是作为一家与 Google 其余部分分开的沙盒公司运营的。
我还要感谢操作系统开发人员中的朋友：Windows、Linux、NOT APPLE FUCK YOU APPLE、FreeBSD 等，他们在他们成功的平台上做了如此出色的向后兼容性工作（Apple 最多只能得到一个 C）缺点是它们总是无缘无故地破坏一切，但不知何故，社区在每个版本中都绕过了它，并且 OS X 容器仍然没有完全过时......还）。
但是等等，你说。 我们不是在比较苹果和橘子吗——单机上的独立软件系统（如 Emacs/JDK/Android/Chrome）与多服务器系统和 API（如云服务）？
好吧，我昨天在推特上提到了这一点，但是按照 Larry Wall（编程语言 Perl 的创建者 - 大约是 per.）的风格，根据“糟糕/规则”的原则，我查了这个词 弃用 在 Google 和 Amazon 开发者网站上。 尽管 AWS 已经 数百 Google 的开发者文档中提到弃用的服务数量是 GCP 的几倍，提及弃用的频率大约是 GCP 的七倍。
如果谷歌的任何人正在读这篇文章，他们可能已经准备好拿出唐纳德·特朗普式的图表来表明他们实际上做的一切都是正确的，并且我不应该进行不公平的比较，例如“不推荐使用的词的提及次数与服务数量" "
但这么多年过去了，谷歌云仍然是第三大服务（我从来没有写过一篇关于试图成为第二名的失败尝试的文章），但如果内部人士可信的话，有人担心他们可能很快就会跌落到第三名。 3号。
我没有任何令人信服的论据来“证明”我的论文。 我所拥有的只是我作为开发人员 30 年来积累的丰富多彩的示例。 我已经提到过这个问题的深刻哲学本质； 在某些方面，它在开发者社区中被政治化了。 有些人认为 创作者 平台应该关心兼容性，而其他人则认为这是一个问题 用户 （开发商自己）。 二分之一。 事实上，当我们决定谁应该承担共同问题的成本时，这难道不是一个政治问题吗？
所以这就是政治。 我的演讲可能会引起愤怒的反应。
如 用户 谷歌云平台，并且作为两年的 AWS 用户（同时为 Grab 工作），我可以说，在优先事项方面，亚马逊和谷歌的理念存在巨大差异。 我并不积极在 AWS 上进行开发，因此我不太清楚他们删除旧 API 的频率。 但有人怀疑这种情况并不像谷歌那样频繁发生。 我坚信，GCP 中持续存在的争议和挫败感是阻碍该平台发展的最大因素之一。
我知道我没有列出不再受支持的 GCP 系统的具体示例。 我可以说我用过的几乎所有东西，从网络（从最旧的到 VPC）到存储（Cloud SQL v1-v2）、Firebase（现在是具有完全不同 API 的 Firestore）、App Engine（我们甚至还没有开始） 、云端点 Cloud Endpoint 以及...我不知道 - 绝对是所有这一切 最多 2-3 年后强迫你重写代码，而且他们从来不会为你自动迁移，而且经常 。 就好像本来就该如此一样。
每次我查看 AWS 时，我都会问自己为什么我仍然使用 GCP。 他们显然不需要客户。 他们需要 买家。 你明白其中的区别吗？ 让我解释。
谷歌云有 ，人们提出他们的软件解决方案，为了避免空荡荡的餐厅效应，他们需要用一些建议来填充它，因此他们与一家名为 Bitnami 的公司签约，创建了一堆“一键”部署的解决方案，或者应该我自己写“解决方案”，因为这些解决不了任何问题。 它们只是作为复选框、营销填充物而存在，谷歌从不关心这些工具是否真正有效。 我认识一些一直处于主导地位的产品经理，我可以向你保证这些人不在乎。
以所谓的“一键式”部署解决方案为例。 。 我对 Google Cloud SQL 恶作剧感到厌倦，所以我开始考虑构建自己的 Percona 集群作为替代方案。 这次谷歌似乎做得很好，他们只需点击一个按钮就可以节省我一些时间和精力！
太好了，我们走吧。 让我们点击链接并单击此按钮。 选择“是”同意所有默认设置并将集群部署到您的 Google 云项目中。 哈哈，这不行。 这些废话都不起作用。 该工具从未经过测试，并且从第一分钟就开始腐烂，如果超过一半的“解决方案”是一键部署，我不会感到惊讶（现在我们明白为什么要引用） 大体 不起作用。 这是绝对无望的黑暗，最好不要进入。
但谷歌是对的 冲动 你要使用它们。 他们希望你 我买了。 对他们来说，这是一笔交易。 他们什么都不想要 支持。 它不是谷歌 DNA 的一部分。 是的，工程师们互相支持，我与 Bigtable 的故事就证明了这一点。 但在为普通人提供的产品和服务中 всегда 是无情的 ，即使拥有数百万用户，也达不到盈利标准。
这对 GCP 来说是一个真正的挑战，因为这是所有云产品背后的 DNA。 他们并不试图支持任何事情；他们只是想支持任何事情。 众所周知，他们拒绝托管（作为托管服务）任何第三方软件 直到那时，直到 AWS 做同样的事情并围绕它建立一个成功的业务，并且当客户确实有同样的要求时。 然而，要让谷歌支持某些东西需要付出一些努力。
这种缺乏支持的文化，加上“让我们打破它，让它变得更美丽”的心态，疏远了开发人员。
如果你想建立一个长期存在的平台，这并不是一件好事。
谷歌，醒醒吧，该死的。 现在已经2020年了。 你还是输了。 是时候认真审视一下镜子并回答您是否真的想留在云业务中了。
如果你想留下来的话 停止破坏一切。 伙计们，你们很有钱。 我们开发人员不这样做。 所以，谁来承担兼容的重担，就需要你自己承担了。 不适合我们。
因为至少还有三朵真正的好云。 他们招手。
现在我将继续修复所有损坏的系统。 呃。
直到下一次！
PS 阅读本文的一些讨论后进行更新（顺便说一句，讨论很棒）。 Firebase 支持尚未停止，据我所知也没有任何计划。 然而，他们有一个令人讨厌的流错误，导致 Java 客户端在 App Engine 中停滞。 他们的一位工程师帮我解决了这个问题， 当我在谷歌工作时，但他们从未真正修复过该错误，所以我有一个糟糕的解决方法，必须每天重新启动 GAE 应用程序。 就这样，已经四年了！ 他们现在有了 Firestore。 迁移到它需要大量工作，因为它是一个完全不同的系统，而且 Firebase 错误永远不会得到修复。 可以得出什么结论呢？ 您可以获得帮助 如果你在公司工作。 我可能是唯一在 GAE 上使用 Firebase 的人，因为我在 100% 原生应用程序中记录了不到 100 个密钥，并且由于已知错误，它每隔几天就会停止工作。 除了自行承担使用风险之外，我还能说什么。 我要切换到 Redis。
我还看到一些更有经验的 AWS 用户表示 AWS 通常永远不会停止支持任何服务，SimpleDB 就是一个很好的例子。 我的假设是，AWS 没有像谷歌那样出现同样的支持终止问题，这似乎是有道理的。
此外，我注意到 20 天前，Google App Engine 团队破坏了一个关键 Go 库的托管，关闭了一位核心 Go 开发人员的 GAE 应用程序。 实在是太蠢了。
最后，我听说 Google 员工已经在讨论这个问题并且普遍同意我的观点（爱你们！）。 但他们似乎认为这个问题无法解决，因为谷歌的文化从来没有正确的激励结构。 我认为花一些时间来讨论我在 Grab 工作期间与 AWS 工程师一起工作的绝对令人惊奇的经历是件好事。 未来的某一天，我希望！
是的，2005 年，43 号楼的巨型自助餐上确实提供了不同类型的鲨鱼肉，我最喜欢的是锤头鲨肉。 然而，到 2006 年，拉里和谢尔盖戒掉了所有不健康的零食。 所以在 2007 年的 Bigtable 故事中，确实没有鲨鱼，我欺骗了你。
当我四年前查看云 Bigtable 时（不管怎样），这就是成本所在。 现在似乎有所下降，但这对于一个空的数据仓库来说仍然是一个可怕的数字，特别是因为我的第一个故事表明一个空的大表在其规模上是多么无关紧要。
很抱歉冒犯了苹果社区，并且没有对微软等说任何好话。你没事，我真的很感谢这篇文章引发的所有讨论！ 但有时你需要引起一点波澜才能引发讨论，你知道吗？
谢谢阅读。
更新 2，19.08.2020 年 XNUMX 月 XNUMX 日。 条纹 !
更新 3，31.08.2020 年 2 月 2 日。 Cloud Marketplace 的一位 Google 工程师联系了我，他是我的老朋友。 他想弄清楚为什么 CXNUMXD 不起作用，我们最终发现这是因为我几年前就构建了网络，而 CXNUMXD 无法在旧网络上运行，因为它们的模板中缺少子网参数。 我认为潜在的 GCP 用户最好确保他们认识足够多的 Google 工程师......
来源： habr.com