因此，让我们解决这个问题。
我将从一个刚开始在Google工作时的小而有启发性的故事开始。我知道我最近对Google说了很多坏话，但是当我的母公司定期做出无能为力的商业决策时，这让我很不高兴。也就是说，我们必须致敬：Google的内部基础架构确实非同寻常，我们可以肯定地说，今天没有比这更好的了。 Google的创始人比我将成为的工程师要好得多，这个故事仅印证了这一事实。
首先，有一点背景知识：Google有一种称为Bigtable的存储技术。这是一项了不起的技术成就，它是第一个（如果不是第一个）“无限扩展”键值存储（K / V）：本质上是NoSQL的开始。这些天来，Bigtable在相当拥挤的K / V存储空间中仍然感觉良好，但在当时（2005年），它的确令人赞叹。
关于Bigtable的一件有趣的事是，它们具有称为平板电脑服务器的内部控制平面对象（作为实现的一部分），具有大型索引，并且在某些时候，它们成为扩展系统时的瓶颈。 Bigtable工程师为实现可伸缩性而绞尽脑汁，突然意识到他们可以用其他Bigtable存储替代平板电脑服务器。因此，Bigtable是Bigtable实现的一部分。这些存储设施在各个层面上都存在。
另一个有趣的细节是，一段时间以来，Bigtable在Google内部变得非常流行和无处不在，并且每个团队都有自己的存储库。因此，在周五的一次会议上，拉里·佩奇（Larry Page）随便问道：“我们为什么有多个Bigtable？为什么不只是一个？从理论上讲，一个存储就足以满足Google的所有存储需求。当然，出于实际的发展原因（例如潜在故障的后果），他们从不跳到一个，但是这种理论很有趣。整个宇宙的一个存储库（顺便说一句，有人知道亚马逊是否用Sable做到了吗？）
无论如何，这是我的故事。
当时，我在Google工作了两年多，有一天，我收到了Bigtable工程团队的电子邮件，内容如下：
尊敬的史蒂夫：
Bigtable团队致辞。谨在此通知您，您正在[数据中心名称]数据中心中使用非常古老的Bigtable二进制文件。不再支持该版本，我们希望帮助您升级到最新版本。
如果您可以安排一些时间来共同解决此问题，请告诉我。
最好的
Bigtable团队
您在Google上收到了很多邮件，因此乍一看，我读到了以下内容：
,
- . , ----. -----, -- .
, , --.
,
-
我几乎马上就删除了它，但是在我的意识边缘，我感到一种痛苦，疼痛的感觉，这看起来并不像正式的信件，尽管很明显收件人是错误的，因为我没有使用Bigtable。
但这很奇怪。
余下的一天，我交替考虑工作以及在微型厨房中尝试哪种鲨鱼肉，其中至少三个离我足够近，可以拿起一个很好用的海绵蛋糕从我的地方拿走，但是写作的想法并没有让我感到成长。轻微的焦虑。
他们清楚地叫了我名字。电子邮件将发送到我的电子邮件地址，而不是其他人的电子邮件地址，并且不是cc：或bcc：。语气非常个性鲜明。也许这是某种错误？
最后，好奇心使我变得更好，我去看看他们提到的数据中心中的Borg控制台。
当然，我可以控制BigTable的存储。对不起，什么？我看了看它的内容，然后-哇！是在Codelab孵化器中，我于2005年6月在Google工作了第一周。 Codelab强迫您启动Bigtable，以便您在那里写一些值，在那之后我可能再也没有关闭过存储库。尽管已经过去了两年多，但它仍然有效。
这个故事有几个值得注意的方面。首先，Bigtable的工作在Google的规模上微不足道，以至于仅仅两年后，有人注意到了额外的存储空间，即使如此，也仅仅是因为二进制文件的版本已过时。为了比较，我曾经考虑使用适用于我的在线游戏的Google Cloud上的Bigtable。当时，对于GCP上的一个空Bigtable ，这项服务每年的费用约为$ 16,000 。我并不是说他们在欺骗您，但是以我个人的观点，这对于一个空的他妈的数据库来说是很多钱。
另一个值得注意的方面是，存储在两年后仍然可以工作... WTF？数据中心来来去去；他们遇到中断，进行例行维护，随时变化。硬件已更新，交换机已交换，一切都在不断改进。通过所有这些更改，他们如何设法使我的程序运行两年？在2020年，这似乎是一个微不足道的成就，但在2005-2007年间，这是相当可观的。
最妙的方面是，其他州的外部工程团队联系了我，Bigtable的一个很小的，几乎是空的实例的所有者，该实例在过去两年中的流量为零-并提供了更新帮助。 ...
我感谢他们，拆除了保险库，生活照常进行。但是十三年后，我仍然考虑这封信。因为有时候我会从Google Cloud收到这样的电子邮件。他们看起来像这样：
尊敬的Google Cloud用户，谨
提醒您，自2020年8月起我们将停止服务[您使用的一项重要服务]，在此之后，您将无法更新实例。我们建议您升级到最新版本，该版本已通过Beta测试，没有文档，没有迁移路径，并且在我们的同类帮助下已经过时了。
我们致力于最大程度地减少此更改对Google Cloud平台所有用户的影响。
永远的好朋友，
Google Cloud Platform
但是我很难读这样的信，因为实际上他们说以下话：
亲爱的收件人，
操你。操你，操你，操你。扔掉您所做的一切，因为这无关紧要。重要的是我们的时间。我们花时间和金钱来支持我们的行为，我们对此感到厌倦，因此我们不再支持它。因此，放弃您的计划，开始深入研究我们的拙劣文档，在论坛上乞讨废料，顺便说一下，我们的新事物与旧事物完全不同，因为我们将这种设计弄得很糟，呵呵，但这是您的问题，不是我们的。
我们将继续努力，以使您的所有设计在一年之内无法使用。
请走吧，
Google Cloud Platform
事实上，我每个月大约收到一次这样的信。这种情况经常如此频繁地发生，以至于他们不可避免地将我推离GCP并进入了对立的云计算阵营。我不再同意依靠他们的专有开发，因为事实上，对于开发人员而言，在裸机上维护开放源代码系统要比试图与Google保持其“过时”产品关闭政策更容易。
回到Google Cloud之前，因为我已经很近了还没有批评他们，让我们看看公司在其他领域的表现。 Google工程师以其软件工程专业为荣，这实际上是造成问题的原因。骄傲是粗心大意的陷阱；它使许多Google员工认为自己的决定永远是正确的，正确的态度（用模糊，模糊的定义）比客户服务更为重要。
这是Google之外其他大型项目的一些任意示例，但我希望您到处都能看到这种模式。就是这样：向后兼容使系统可以保持数十年的生命周期和最新状态。
向后兼容是所有成功设计的系统的设计目标，开放使用，即以开放源代码和/或开放标准实施。我觉得我说的太明显了，每个人都感到不舒服，但没有。这是一个政治问题，因此需要实例。
我选择的第一个系统是最早的系统：GNU Emacs，它是Windows记事本，OS内核和国际空间站之间的混合体。有点难以解释，但是简而言之，Emacs是一个于1976年创建的平台（是的，差不多半个世纪前），该平台用于编程以提高工作效率，但是却伪装成文本编辑器。
我每天都使用Emacs。是的，我每天也使用IntelliJ，它本身已成为强大的工具平台。但是，为IntelliJ编写扩展要比为Emacs编写扩展大得多，而且难度更大。更重要的是，为Emacs编写的所有内容都将永远存在。
我仍然使用1995年为Emacs编写的软件。而且我确定有人会在80年代中期（如果不是以前）使用为Emacs编写的模块。他们可能会不时需要进行细微调整，但这确实很少见。我不知道我为Emacs编写过的任何东西（而且我已经写了很多东西），这些东西都必须重新架构架构。
Emacs具有一个称为遗留实体的过时功能。 Emacs的基本计算机概念（例如“窗口”是什么）的术语通常与行业惯例有所不同，因为Emacs早已引入了它们。对于那些过早的人来说，这是典型的危险：您的所有条款都不正确。但是Emacs确实有过时的概念，用过时的术语称为过时。
但是在Emacs世界中，似乎存在不同的工作定义。如果您愿意的话，还有另一种基本哲学。
在Emacs的世界（以及我们将在下面介绍的许多其他领域）中，旧版API的状态基本上意味着：“您实际上不应该使用这种方法，因为尽管这种方法有效，但它会遭受各种弊端，我们将在此处列出。但最后，这是您的选择。”
在Google世界中，旧产品状态表示“我们违反了我们对您的义务”。真的是这本质上就是这个意思。这意味着他们会强迫您定期做一些工作，也许还会做很多工作，以作为对他们五颜六色的广告的信任的惩罚：我们拥有最好的软件。最快的！您需要按照说明进行所有操作，启动您的应用程序或服务，然后在一两年后中断，然后进行bam。
这就像卖一辆二手车，肯定会在1500公里后发生故障。
这是“过时”的两个完全不同的哲学定义。 Google的定义闻起来像计划中的过时。我不相信这真的是与苹果计划相同的计划过时。但是Google绝对计划以一种about回的方式破坏您的程序。我知道这一点是因为我在那里担任软件工程师超过12年。他们对应该向后兼容的多少有模糊的内部指导原则，但最终取决于每个团队或服务。没有公司或工程级别的建议，关于过时周期的最大胆建议是“尝试给客户6到12个月的时间来升级整个系统。”
这个问题比他们想的要严重得多，而且这个问题将持续多年，因为客户服务并不是他们的DNA。在下面的更多内容。
就目前而言，我将大胆地声明Emacs在很大程度上（甚至大部分情况下）是成功的，因为它们非常重视向后兼容性。实际上，这是本文的论点。成功的长期开放源代码系统的成功归功于数十年来围绕扩展/插件存在的微型社区。这就是生态系统。我已经讨论过平台的本质以及它们的重要性，以及Google在整个公司历史中从未了解除了Android或Chrome之外，如何创建一个成功的开放平台。
实际上，我不得不简短地提到Android，因为您可能已经考虑过了。
首先，Android不是Google...他们几乎没有任何关系。 Android是一家于2005年7月被Google收购的公司，该公司或多或少地被允许自主运行，实际上多年来一直保持完整。 Android是一个臭名昭著的技术堆栈，也是一个臭名昭著的棘手组织。正如一位Google员工所说：“您不能只使用Android。”
在上一篇文章中，我讨论了一些早期Android设计的糟糕程度。哎呀，当我写那篇文章时，他们正在部署一个叫做“ Instant Apps”的东西，现在（惊奇！）已经过时了。并同情您是否愚蠢到可以听Google并将您的内容带入这些即时应用程序。
但是有一个不同，一个很大的不同，那就是Android人士真正了解平台的重要性，他们尽力使旧的Android应用程序正常运行。实际上，他们为保持向后兼容性所做的努力非常极端，以至于我几年前在Android部门短暂工作时，甚至发现自己试图说服他们放弃对某些最旧设备和API的支持（我错了，过去和现在还有很多其他事情。对不起，Android家伙！既然我去过印度尼西亚，我就明白了为什么我们需要它们）。
Android人员保持向后兼容的能力，几乎达到了无法想象的极限，在他们的系统和工具链中堆积了大量的过时技术债务。哦，天哪，您应该已经看到了它们在构建系统中必须做的一些疯狂的事情，而这些都是以兼容性为名的。
为此，我授予Android令人垂涎的You Are Not Google大奖。他们真的不想成为Google，因为Google不知道如何构建持久的平台，但是Android知道如何做到。因此Google在一个方面非常明智：它允许Android上的人们以自己的方式做事。
但是，即时Android应用程序是一个非常愚蠢的想法。你知道为什么吗？因为他们要求重写并重新设计您的应用程序！仿佛人们只会拿并重写200万个应用程序。我想即时应用是一些Google员工的想法。
但是这里有所不同。向后兼容性很昂贵。 Android本身承担这些费用的负担，而Google坚持由您（付费客户）承担这些费用。
您可以在其API中看到Android对向后兼容的承诺。当您有四个或五个不同的子系统实际上要做相同的事情时，这无疑是向后兼容性的承诺所在。在平台世界中，哪一个是对客户和市场承诺的代名词。
Google的主要问题是他们对自己的工程学设计感到自豪。当有许多不同的方式来做同一件事时，他们不喜欢它，而较旧的，不太理想的方式与更新，更离奇的方式并排。它增加了系统新手的学习曲线，增加了维护旧版API的负担，减慢了新功能的速度，并且主要的缺点是丑陋的。 Google-就像蒂姆·伯顿（Tim Burton）的《爱丽丝梦游仙境
》中的阿斯科特夫人：阿斯科特夫人：
-爱丽丝，你知道我最害怕的吗？
-贵族的衰落？
-我怕我会有丑陋的孙子。
为了了解美观与实用之间的平衡，让我们看一下第三个成功的平台（仅次于Emacs和Android）并了解其工作原理：Java本身。
Java有大量的遗留API。弃用在Java程序员中非常流行，甚至比大多数编程语言更流行。在Java本身（主要语言和库）中，API弃用是不断发生的。
如果仅使用数千个示例之一，则不建议使用关闭流。自1998年12月发布Java 1.2以来，已弃用该工具。自弃用至今已有22年了。
但是我真正的生产代码仍然每天杀死线程...好吗？绝对！我的意思是，当然，如果今天要重写代码，我将以不同的方式实现它。但是，我的游戏代码在过去的二十年中使成千上万的人感到高兴，但它编写的函数具有关闭挂起时间过长的线程的功能，而我无需更改它。我最了解我的系统，我在生产中有25年的工作经验，我可以肯定地说：就我而言，关闭这些特定的工作流是完全无害的。您不应该浪费时间和精力来重写此代码，并且（可能）赞扬Larry Ellison，Oracle没有强迫我重写它。
Oracle可能也精通平台。谁知道。
可以找到所有陈旧过时的核心Java API的证明，例如峡谷中冰川的线条。在Java Swing库中，您可以轻松找到五个或六个不同的键盘导航管理器（KeyboardFocusManager）。实际上，很难找到不被弃用的Java API。但是它们仍然有效！我认为，如果接口引起严重的安全问题，Java团队只会真正删除该API。
家伙们：我们的软件开发人员都很忙，在软件的每个领域我们都面临着竞争的替代方案。在任何给定时间，X程序员都将Y视为可能的替代者。哦，你不相信我吗？您想被称为Swift吗？就像，每个人都迁移到Swift，没有人放弃它，对吗？哇，你知道的很少。公司正在计算双重移动开发团队（iOS和Android）的成本-他们开始意识到，这些有趣的跨平台开发系统（如Flutter和React Native）确实有效，并且可以减少其移动团队的规模。两倍，或者相反，使它们的生产力提高两倍。真钱is可危。是的，有妥协，但另一方面，电子货币。
假设，Apple愚蠢地效仿了Guido van Rossum的例子，并宣布Swift 6.0向后与Swift 5.0不兼容，就像Python 3与Python 2不兼容一样。
我大概在十年前就讲过这个故事，但是在15年前我曾讲过和吉多一起去了奥莱利的Foo营地，与保罗·格雷厄姆（Paul Graham）和一大堆颠簸坐在帐篷里我们坐在闷热的天气里，等待拉里·佩奇（Larry Page）乘坐他的私人直升机起飞，而圭多（Guido）单调地喃喃地谈论着Python 3000，他以多年的名字命名。我们一直问他为什么破坏兼容性，他回答：“ Unicode”。我们问，如果必须重写代码，还会看到什么其他好处？他回答说：“ Yooooooooooooooouuuuuuuniiiiiiicoooooooode”。
如果您安装了Google Cloud Platform SDK（“ gcloud”），则会收到以下通知：
亲爱的收件人：
我们想提醒您，Python 2支持已被弃用，是吗？
…等等生活圈子。
但关键是，每个开发人员都有选择的余地。而且，如果让他们经常重写代码，那么他们可能会考虑其他选择。他们不是您的人质，无论您想要他们多少。他们是你的客人。 Python仍然是一种非常流行的编程语言，但是令人难以置信的是，Python 3（000）本身，在其社区中以及在其社区中的用户之间都造成了如此混乱，以至于后果已经十五年了。
由于这种向后不兼容，已经用Go（或Ruby或其他替代方法）重写了多少个Python程序？尽管可能已经用Python以外的东西编写了多少新软件如果用Guido编写的Python编写的书，还没有烧毁整个村庄吗？很难说，但是Python显然遭受了痛苦。这是一个巨大的混乱，每个人都是失败者。
因此，假设Apple遵循Guido的示例并破坏了兼容性。您认为接下来会发生什么？好吧，也许80-90％的开发人员将尽可能重写他们的软件。换句话说，10-20％的用户群会自动使用某些竞争性语言，例如Flutter。
这样做几次，您将失去一半的用户群。与体育运动一样，在编程世界中，当前的形状也意味着一切。...在五年内失去一半用户的任何人都将被视为“大胖子”。您应该在平台世界中处于流行趋势。但这是放弃对旧版本的支持会随着时间的流逝杀死您的地方。因为每当您摆脱一部分开发人员时，您（a）永远失去他们，因为他们因违反合同而生您的气，并且（b）将其交给竞争对手。
具有讽刺意味的是，当我创建Grok（一种有助于基于代码的自动化和工具的源代码分析和理解系统）时，我也帮助Google变成了向后兼容的prima donna，类似于IDE，但是在这里云服务存储实现了大型数据仓库中数十亿行Google源代码的表示形式。
Grok为Google员工提供了一个强大的框架，可以在整个代码库（实际上整个Google）中进行自动重构。系统不仅计算您的上游依赖关系（取决于您），还计算下游的依赖关系（取决于您），因此，当您更改API时，您会知道所有被破坏的人！这样，当您进行更改时，您可以检查API的每个使用者都已更新到新版本，实际上，通常使用他们编写的Rosie工具，您可以完全自动化该过程。
这使Google的代码库在内部几乎可以说是“自然”的，因为这些机器人仆人到处乱窜，如果他们将SomeDespicablyLongFunctionName重命名为SomeDespicablyLongMethodName，他们会自动清理所有内容，因为有人认为这是一个丑陋的孙子，需要入睡。
老实说，它在Google内部非常有效。我的意思是，是的，Google的Go社区对Google的Java社区非常满意，因为他们习惯不断进行重构。重新启动N次意味着您不仅将它弄乱了N-1次，而且一段时间后很明显，您很可能在第N次尝试时就把它弄乱了。但是，总的来说，它们会大惊小怪，并保持代码“干净”。
当他们试图将这种态度强加给他们的云客户端和其他API用户时，问题就开始了。
我向您介绍了Emacs，Android和Java。让我们看一下最新的成功长期存在的平台：Web本身。您可以想象，自1995年以来，HTTP经历了多少次迭代，那时我们使用了闪烁的<blink>标记和网页上正在构建的图标。
但它仍然有效！这些页面仍在工作！是的，浏览器是世界向后兼容性的拥护者。 Chrome是另一个罕见的Google平台的例子，它的头脑已经被正确地抓住了，而且您猜到了，Chrome实际上是与Google其余部分分开的独立公司。
我还要感谢操作系统开发人员中的朋友：Windows，Linux，而不是APPLE，而不是APPLE，FreeBSD等，因为它们在成功的平台上做了很多向后兼容工作（Apple最多获得三倍的兼容性）。减号，因为它们无缘无故地破坏所有内容，但是社区在每个发行版中都以某种方式处理了这个问题，到目前为止，OS X容器还没有完全过时……）。
但是等等，你说。我们不是将苹果与橘子进行比较吗？苹果是单台机器上的独立软件系统，例如Emacs / JDK / Android / Chrome，还是多服务器系统和API（例如云服务）？
好吧，我昨天在推特上发了言，但是在Larry Wall的“吸引/统治”风格中，我查找了Google和Amazon开发人员网站上已弃用的单词。尽管AWS提供的服务数量是GCP的数百倍，但Google的开发人员文档提到弃用的频率大约是GCP的七倍。
如果Google的某人读了此书，那么他们很可能已经准备好绘制出唐纳德·特朗普（Donald Trump）风格的图表，表明他们实际上做得很好，并且我不应该进行不公平的比较，例如“根据服务的数量，不提这个词的提及次数”。
但是经过了这么多年，Google Cloud仍然排名第三（我从未写过有关成为第二失败的尝试的文章），但是如果您相信内部人士，则有些担心他们可能会很快
跌至第四。 “证明”您论文的论据。我所拥有的都是丰富多彩的示例，我作为开发人员已经积累了30多年。我已经提到了这个问题的深刻哲学性质。在某种程度上，它在开发人员社区中被政治化了。有些人认为平台创建者应该关心兼容性，而另一些人则认为这是用户的关注。（开发人员自己）。一分之二。的确，当我们决定由谁承担共同问题的代价时，这不是政治问题吗？
这就是政治。我的演讲肯定会引起愤怒的回应。
作为用户的谷歌云平台，以及一个AWS用户两年（在抢），我可以说，有亚马逊和谷歌的哲学之间的巨大差异，当涉及到优先级。我没有积极地在AWS上进行开发，所以我不太清楚它们多久删除一次旧的API。但是有人怀疑这种情况不会像Google那样经常发生。我坚信，GCP中不断引起争议和沮丧的原因是对该平台开发的最大限制之一。
我知道我还没有命名不再支持的GCP系统的特定示例。我可以说几乎所有我使用过的东西，从网络（从最早的VPC到VPC）到存储（Cloud SQL v1-v2），Firebase（现在的Firestore具有完全不同的API），App Engine（甚至还没有开始），云端点以及之前的版本...我不知道-绝对所有这些都使您最多在2-3年内重写代码，并且它们从未为您自动完成迁移，而且通常根本没有记录下来的迁移路径。好像应该的。
每次查看AWS时，我都会问自己为什么仍然坐在GCP上。他们显然不需要客户。他们想要买家。您了解其中的区别吗？让我解释。
Google Cloud拥有一个市场，人们可以在该市场中提供其软件解决方案，并且为了避免空荡荡的餐厅的影响，他们不得不向其提供一些建议，因此他们与Bitnami签订了合同，以创建一系列“单击即可”部署的解决方案，我必须自己编写“解决方案”，因为它们不能解决该死的事情。它们只是作为标志，作为营销手段而存在，而Google从来不在乎任何工具是否真正起作用。我知道有开车的产品经理，我可以向您保证这些人不在乎。
以“一键式”部署解决方案Percona为例...我对Google Cloud SQL滑稽动作感到无聊，所以我开始考虑创建自己的Percona集群作为替代方案。这次Google似乎做得不错，只需单击一下按钮，他们就会为我节省一些时间和精力！
好吧，太好了，走吧。让我们点击链接，然后按此按钮。选择“是”以同意所有默认设置，并将集群部署到您的Google云项目。哈哈，不行。这些狗屎都不起作用。该工具从未经过测试，并且从一分钟开始就开始腐烂，如果一键式部署的“解决方案”中有一半以上（现在我们明白为什么引用）根本不起作用，也不会感到惊讶。这绝对是绝望的黑暗，最好不要进入。
但是Google明确鼓励您使用它们。他们要你买。对于他们来说，这是一笔交易。他们不想支持任何事情。它不是Google DNA的一部分。是的，工程师的相互支持，正如我在Bigtable的故事所证明的那样。但是，在针对普通百姓的产品和服务中，即使关闭了拥有数百万用户的服务，但他们始终会残酷地关闭任何无法盈利的服务。
对于GCP而言，这是一个真正的挑战，因为这种DNA位于所有云产品背后。他们不寻求任何支持。众所周知，他们拒绝托管（作为托管服务）任何第三方软件只要AWS无法做到这一点，并且在客户要求相同的条件下，AWS不会成功地开展业务。但是，要使Google支持某件事需要花费一些精力。
这种缺乏支持的文化，再加上“让我们打破它，使其变得美丽”的原则，使开发人员与他们疏远了。
如果您要构建一个长期存在的平台，那就不好了。
Google醒了，该死。是2020年。你还在输。现在是时候仔细了解一下并回答，如果您真的想保留在云业务中。
如果你想留下来，那就别再破坏一切了...你们有钱。我们开发人员不是。因此，对于谁来承担兼容性的负担，您需要自己承担。不适合我们。
因为至少还有三朵真正的好云。他们向他们招手。
现在，我将继续修复所有损坏的系统。嗯
直到下一次！
阅读本文中的某些讨论后进行PS Update（顺便说一下，讨论非常好）。 Firebase尚未停止，并且我没有任何计划。但是，它们存在令人讨厌的流式传输错误，导致Java客户端在App Engine中停止。当我在Google工作时，他们的一位工程师为我解决了这个问题, , , GAE. ! Firestore. , , , Firebase . ? , . , , Firebase GAE, 100 100% , - . , . Redis.
, AWS , AWS , SimpleDB — . , AWS , Google, , .
, , 20 Google App Engine Go, GAE Go. , .
, , ( , !). , , Google . , , AWS, Grab. - , !
, 2005 43, . 2006 . Bigtable 2007 .
Bigtable (-), . , , , , , .
, Apple Microsoft . . , , ! , , ?
.
2, 19.08.2020. Stripe API!
更新3，08/31/2020。一位Cloud Marketplace的Google工程师与我联系，结果证明我是我的老朋友。他想找出为什么C2D无法工作的原因，最后我们发现：原因是几年前我创建了我的网络，由于遗留网络中模板中的子网参数缺失，所以C2D无法在旧网络上工作。我认为潜在的GCP用户最好确保他们在Google拥有足够熟悉的工程师...