GCP在许多方面优于AWS

我最初在Reddit上发布了这篇文章，这样我就可以从其他工程师那里获得一个很好的意见样本，看看他们与我的观点相比如何，然后再在这里发布和扩展。这是我基于使用两个平台(每个平台两年)的经验得出的看法。我对GCP的偏见主要是基于我在GCP上获得的卓越经验，我与Google没有任何关联。作为云平台的企业选择，AWS仍然是我的第二选择，如果他们做得更好就好了。我欢迎你的意见和纠正，特别是如果他们是知情的和建设性的，我很高兴从你那里学习。

如果AWS(亚马逊网络服务)和GCP(谷歌云平台)都是汽车公司，你想买一辆车，AWS会给你方向盘，一本笨重冗长的手册和钥匙，然后告诉你去他们也拥有的20家不同的商店去买剩下的组件，尽可能自己把它们组装在一起。当然，也许您可以雇佣一项服务并获得工具来自动化这一部分，但将这些组件组装在一起并维护自动化仍然落在您的肩上。

另一方面，GCP的体验更像是收集汽车钥匙，然后从停车场开车离开，如果你愿意，可以选择拆卸和定制汽车，但默认情况下，这是一辆功能齐全、部件连贯的汽车，这样你就可以快速实现你的目标，即开车四处行驶，而不是组装汽车。

我使用AWS的第一次体验是短暂的，我不喜欢它；我觉得AWS的界面以及工具和设置的组织方式有违直觉和怪异，当时我还没有太多可比较的东西。

例如，为服务器分配静态IP非常奇怪，我一直在寻找分配静态IP的方法，而不知道它应该被称为弹性IP并隐藏在一组单独的菜单中。这些弹性IP是与动态分配的IP池不同的IP池的一部分，因此我不得不停止生产服务器以更改IP，并更改指向该新IP的DNS，这是因为我的前任没有为服务器分配静态IP，我打赌他可能在10分钟后就放弃了，试图找出它被称为弹性IP。

我在AWS工作的第二次经历是在GCP工作一年半之后，相比之下，我现在真的无法忍受AWS，我花了几个月的时间才习惯使用它，我记得在我最初的几周里，我实际上考虑过辞职，只接受GCP的角色。

这并不是说AWS比GCP更难使用，而是它不必要地硬；它们之间的基础设施原语杂乱无章，凝聚力很差。挑战是好的，令人困惑的混乱不是，AWS的问题是，您的大部分工作时间将花在整理文档和在功能和产品中筛选以找到您想要的东西，而不是专注于有趣的又酷又有趣的挑战。

让我们来回顾一下让AWS变得如此难以使用的几个方面，以及它与GCP相比有何不同。

从GCP到AWS，首先让您印象深刻的区别之一是客户与项目。在GCP中，您有一个可用于管理其余项目的主帐户/项目，您可以使用公司的Google帐户登录，然后您可以随心所欲地设置任何项目的权限。所以你可以有一个开发项目，一个生产项目，等等。所有这些都是开箱即用的，绝对没有额外的事情需要你去做。

在AWS中，您有帐户，并且每个帐户都有一组单独的用户。有多种方法可以连接这些帐户，以便您的用户拥有对其他帐户的权限。实现此目的的一种方法是创建主用户帐户，然后添加可由该主帐户在所有其他帐户中承担的角色。

这不仅设置起来很痛苦，而且使用起来也很痛苦。例如，在使用terraform脚本时，如果需要跨多个帐户工作，则需要跨多个模块协调多个角色。

假设我们使用2FA和几个不同的项目/帐户，让我们将使用GCP CLI所需的操作与AWS进行比较。

在GCP中，安装Google SDK之后，您需要做的就是运行gcloud init，它会将您在浏览器中重定向到Google登录页面。在这里，你可以用你的2FA登录(如果你有一部Android手机，只需解锁手机，然后按OK就可以了)，然后你就完成了。您的登录会话已附加到您的Google会话，因此当您终止此会话时，您将被注销-非常简单。

在AWS中，您需要创建一个可用于通过CLI登录的令牌，这很简单，对吧？但是现在我们想要使用2FA，这就是有趣的开始。

在您使用令牌登录之后，您需要创建一个脚本来为您提供12小时的会话，并且您每天都需要这样做，因为没有办法扩展它。

好的，但这不是什么大不了的事，你说，毕竟这只是一个代码，你需要每天输入一次，然后你就可以开始你的一天了。

但是等等，还有更多！如果您需要承担另一个帐户中的角色，则需要创建另一个脚本来创建另一个配置文件供您使用。

这是一个步骤加上两个脚本，再加上中间的许多步骤。当然，您可以将大部分操作自动化，或者使用您在网上找到的其他人的工具(您很可能需要调整这些工具)，但是为什么呢？为什么我们要做这么多工作才能使用AWS？为什么AWS不能像谷歌那样抽象化你的痛苦呢？

如果使用CLI对您来说太痛苦了，您可以随时登录门户并使用其用户界面，尽管我不建议您对所有内容都这样做，但实际上我建议您尽量不要使用CLI，仅供参考并检查服务的状态，请始终尽可能多地使用基础架构作为代码。

AWS的界面看起来像是一个居住在小行星上的孤独的外星人设计的，他曾经看过一部关于人类点击鼠标的纪录片。它令人困惑、违反直觉、杂乱无章，而且极其拥挤。

我甚至数不清我在AWS控制台中迷路或被难住的次数，有时是因为最愚蠢的细节，比如错过了在一个奇怪的角落里藏着一个下一步按钮。或者试图使用只能搜索前缀的搜索栏(WTF？)。

但我对AWS控制台最大的不满是，在实际配置任何东西之前，您总是被需要填写的大量设置和选项压得喘不过气来。

我脑海中浮现的一个例子是，有人在工作时说，我们应该使用codebuild/codeploy来取代Jenkins进行ECS部署。第一个工程师试了，他卡住了，第二个工程师试了，他卡住了，我试了几个小时，我卡住了…。最后，我放弃了，因为我不想再花更多的时间在一个我认为应该让生活变得更容易的CI/CD上似乎不太受欢迎的工具上。

不过，亚马逊似乎在几乎所有产品的界面方面都特别糟糕。例如，在我的智能电视中，Netflix应用程序运行得无懈可击，使用起来很直观，而亚马逊Prime应用程序令人厌恶，你经常不小心按错了按钮，或者迷路了，或者字幕经常不同步。

在一位曾在亚马逊工作的谷歌工程师不久前写道，他解释了亚马逊和贝佐斯不理解界面(或者是人与人之间的互动)的问题时，他怒气冲冲地解释了这个问题。就像这样：

杰夫·贝佐斯(Jeff Bezos)是一位臭名昭著的微观管理者。他对亚马逊零售网站的每一个像素都进行微观管理。他聘请了苹果首席科学家拉里·特斯勒(Larry Tesler)，他可能是全世界最著名和最受尊敬的人机交互专家，然后三年来无视拉里说的每一句该死的话，直到拉里最终--明智地--离开了公司。拉里会做这些大的可用性研究，并毫无疑问地证明没有人能理解那个该死的网站，但贝佐斯就是不能放弃那些像素，那些登录页面上数百万个语义丰富的像素。他们就像他自己的数百万个宝贝孩子。所以他们都还在那里，而拉里不在了。

另一方面，GCP的用户界面使用起来非常直观，每当您想要配置任何东西时，您都会得到合理的默认值，这样您只需单击几下就可以部署任何东西，我从未在使用GCP时迷路过，也没有需要查阅一百万页的文档来找出我需要做什么。

然而，这并不意味着GCP正在剥夺您对复杂细节进行配置的能力，它只是意味着他们为您提供了一个工作配置的示例，然后您可以根据您的目的进行调整。

您还可以通过GCP中的UI执行其他操作，这些操作要么在AWS中运行得非常糟糕，要么根本不存在。例如，您可以轻松地将终端和ssh打开到您已启动的任何实例中(前提是您为其设置了权限)，并且它工作得非常好。

GCP中另一个我非常喜欢的特性是查看CLI命令的能力，该命令可以在控制台中执行任何设置。这使得学习CLI变得容易得多，这比在网上搜索如何做任何事情的示例或试图理解aws华丽的文档…要好得多。

您可以原谅AWS中的文档是一场噩梦，因为它仅仅反映了试图描述的令人困惑的混乱局面。每当你试图解决一个简单的问题时，你经常会在参考页上溺水，这种经历就像要了一杯水，然后被消防栓冲了下去。

优秀的文档是与上下文相关的，而不是参考性的。如果您想要学习如何烹饪一道菜，您不会希望有人向您指出一系列配料，您需要一个描述如何使用它们的食谱，而这正是AWS文档经常失败的地方；它详尽地描述了它们拥有的一切(这还不错)，但是它们在将文档放入上下文方面并不总是做得很好。

为了对被要求在AWS中记录任何东西的人完全公平，记录令人困惑和混乱的东西比记录简单易用的东西要难得多。大量和过于冗长的文档通常是复杂和过于错综复杂的软件或流程的标志，因此从这个意义上说，Google Cloud从一开始就具有优势。

GCP中的文档通常是清晰而简明的，虽然它可能并不总是完美的，但我通常认为它是有用的，并且切中要害。如果您想要其他优秀的文档示例，请查看DigitalOcean-它们非常棒。

如果您的意图是使用Kubernetes，那么甚至不必费心使用AWS，他们的实现是如此糟糕，我甚至不能理解他们怎么会有胆量称其为托管的，特别是与GCP相比。

在GCP中，如果你想旋转一个集群，没问题，只需点击几下就可以了。默认设置很简单，而且整个产品感觉非常有凝聚力，所有从你的体验中抽象出来的丑陋、乏味的部分。

使用GKE，您不需要加入节点，也不需要规划或自动化这些节点的升级，它是自动完成的，或者只需单击几次即可完成，这并不意味着您要牺牲复杂性。你可以定制很多东西，但当你看到合理、简单的默认设置时，理解一个产品要容易得多，因为它被一系列选项淹没了，并试图弄清楚所有东西是如何组合在一起的，就像EKS的情况一样。

旋转EKS集群实质上给了您一块砖。您必须在侧面旋转您自己的节点，并确保它们与主节点连接，这对您来说除了“托管”的承诺之外，还有很多工作要做。

是的，我知道有官方的terraform模块可以为您处理大部分工作，并使工作变得容易得多，还有Weaveworks开发的名为eksctl的工具非常棒，但它们旨在简化本应由AWS设计抽象的复杂解决方案，而不是依赖于其他人来理解复杂脚本和工具的混乱。

即使您使用这些工具在AWS之上创建自动化，但事实仍然是，在AWS下面有很多移动部件，您将始终负责协调并确保这些部件工作正常且处于最新状态。例如，eksctl在后台使用CloudFortification模板。

在撰写本文时，有169个AWS产品，而GCP只有90个。AWS已经存在的时间更长了，因此他们有更多的服务，他们怀着良好的亚马逊精神，不断积极地扩展这项服务，以极快的速度为您提供更多您可能需要的东西(以及许多您不需要的东西)。

这听起来像是一件好事，直到你开始看到他们有多少半熟的或几乎重复的产品。一个很好的例子是参数存储和Secret Manager，它们是不同的，但从实用的角度来看，它们看起来与Secret Manager非常相似，只是增加了秘密的轮换。

另一个疯狂产品超载的例子是队列，在本文中由Dep很好地解释了这一点：

GCP将他们的不同服务集成在一起做得很好。GCP提供了一组较小的核心原语，这些原语是全局的，可以很好地用于许多用例。Pub/Sub可能是我拥有的最好的例子。在AWS中，当您阅读本文时，您已经拥有SQS、SNS、Amazon MQ、Kinesis数据流、Kinesis Data Firehose、DynamoDB Streams，可能还有另一项排队服务。2019年更新：亚马逊现在又发布了一项流媒体服务：亚马逊托管流媒体Kafka。GCP有PUB/SUB。Pub/Sub似乎足够灵活，可以取代大多数(全部？)。在AWS的各种队列中。

另一方面，GCP的产品更少，但他们拥有的产品(至少在我的经验中)感觉更完整，更好地与生态系统的其余部分集成，选择一种产品而不是另一种产品不会成为需要广泛研究的痛苦选择(好的，您仍然需要研究，但不会太多)。

在我开始使用Macbook之前，我过去常常嘲笑苹果的局限性，以及它们与Windows和Linux发行版相比的功能是多么的少，直到那时，我才意识到，对几个产品采取固执己见的方法，更紧密地集成各种组件，往往会产生更优越、更稳定的体验，这与我现在使用GCP与AWS的体验相似。GCP带给您的东西更少，交付速度也更慢，但它给您的集成要好得多，使用简单，而且通常比AWS的同类产品工作得更好。

AWS对其服务的收费比GCP高得多，但大多数人忽略了使用AWS的真正高昂成本，即专业知识、时间和人力。

有了GCP，一个在平台工具方面相对缺乏经验的工程师可以在相对较短的时间内拿起它并完成他的工作，因为大多数将所有部件拼装在一起的繁琐任务都已经由谷歌完成了。

在GCP中，您可能需要一天或更少的时间来完成任务，而在AWS中，您可能需要一周时间才能完成相同的任务。这里我可以举一个vPC端点的例子。我当时使用的是Terraform群集安装，我想限制Internet的出站流量。问题是，如果您这样做，那么您还会切断到AWS的流量，为了解决此问题，您需要设置端点。端点基本上允许您通过AWS Intranet而不是Internet连接到AWS(不要问我为什么云提供商在默认情况下不这样做，这对我来说毫无意义)。

非常简单，我只需添加这些端点，然后我的工作就完成了。问题是，我使用的是具有许多移动部件并使用多个AWS服务的Terraform集群配置器，您无法设置适用于所有AWS服务的端点，每个服务只能设置一个端点，我必须做大量挖掘，试图找出配置器正在使用的所有服务，并为每个服务添加端点。每次添加端点时，我都发现必须添加另一个端点，最后我添加了大约5个端点，然后我发现有几个端点。因此，最终我只能允许通过NAT的传出流量。

出于好奇，我调查了如何在Google Cloud中做到这一点，因为我以前从未这样做过，只是想看看与AWS相比会有多难，我并不惊讶地发现，只需点击一个复选框或激活一个设置就可以完成同样的事情，而且它适用于所有服务。此外，在GCP中执行此操作是免费的，而在AWS中您需要为每个端点付费。

上面只是一个例子，但我发现，一般来说，我想在AWS中完成的任何任务都需要比GCP多得多的精力和精力，这意味着如果您使用AWS，您可能需要雇佣更多的工程师，并且需要更多的时间和人力资源投入。

如果您决定使用AWS，给您的组织带来的另一个重大成本是持续中断的流程。心流是一种状态，在这种状态下，你理想地希望你的工程师在你的公司有很大一部分时间，不仅他们会更快乐，而且他们的工作效率也会更高。

使用AWS的问题是，由于使用起来非常混乱和复杂，您将不得不花费大量时间阅读文档和测试，以弄清楚事情是如何工作的，而令人恼火的是，这不会是有趣的实验，它将是乏味而琐碎的问题，而这些问题不应该存在，就像我上面描述的端点问题一样。

即使在您熟悉了AWS的使用之后，您仍然会花费过多的时间做一些在GCP中从不需要做的枯燥乏味的事情。比如每12小时输入一次2FA代码，或者承担角色，或者只是简单地检查一下各个部分和服务并将它们组合在一起。你和你想要完成的任务之间的障碍越繁琐，你就越难实现心流。

我不打算在这两个平台上做广泛的测试，也不会为这篇文章发布基准测试，因为这比我想花在这上面的工作要多得多，但我只想说，根据我的经验，我觉得GCP的性能几乎总是更好，例如，在GCP中从实例复制到存储桶的速度快得离谱，我记得对此感到震惊，因为在以前的工作中，我不得不每小时备份到AWS中的大量大块数据存储桶，我总是觉得复制非常慢，但这不是最快的，因为在以前的工作中，我必须每小时备份到AWS中的大块数据存储桶，而且我总是觉得复制非常慢，但这不是

本文中的一些延迟测试清楚地表明，当涉及到网络性能时，GCP几乎在所有领域都做得更好。

AWS和GCP都非常安全，只要您的设计不粗心，就不会有问题。然而，GCP对我来说有一个优势，那就是默认情况下所有内容都是加密的。例如，它们的存储桶和日志在传输过程中和静止时都是加密的。出于某种奇怪的原因，默认情况下AWS不会加密存储桶或日志，您必须启用此功能。见鬼，谁不想让自己的数据在AWS服务器上加密呢？

如果您有兴趣了解更多有关GCP安全的信息，这是一次不错的演讲：

我认为，在可伸缩性和全球基础设施方面，世界上没有一家公司比谷歌做得更好(尽管CloudFlare在某些领域肯定会让它大吃一惊)。

为了了解谷歌的基础设施有多么不可思议，2013年谷歌宕机了5分钟，整个世界的互联网流量下降了40%，因为人们认为谷歌不开通时，他们的互联网就坏了。

人们更信任谷歌，而不是。

..