去 GAE——我们对谷歌应用引擎的回顾

原文：https://medium.com/hackernoon/going-gae-our-experience-with-google-app-engine-deaf2b7171c1

当我和汤姆离开阿萨那建造吊舱时，我们最大的决定之一就是我们想要在哪个云上建造。这是一个具有巨大路径依赖性的决定；改变基础设施的成本非常高，而且每个堆栈都有怪癖和限制，只有在被锁定后你才会发现。从很多方面来说，这是一场婚姻。我们决定与 T2 GAE T3 联姻——将整个系统放在 T4 谷歌 T5 云上。

我们这样做有几个原因:

我们不是基础设施工程师(也不想成为)。比起 IaaS(基础设施即服务)，我们更想要 PaaS(平台即服务)；本质上，我们希望与一个简单的 API 交互，而不需要考虑负载平衡器或实例。
GAE 巨蟒小组的成员非常性感。它们让你想要建造一些东西！
谷歌给了我们 300 美元的信用。

从很多方面来说，我们觉得自己是在选择失败者。当然，Snapchat 使用谷歌，但我们不知道其他很多。在阿萨纳，我们几乎都是 AWS。AWS 很强大，但也可以亲自动手:频繁地用安全补丁更新 EC2 实例，看到远程作业备份，见证 Asana 数据库的分片给我留下了深刻的印象。连弹性豆茎都可以手动。我们需要更简单的 Pod，但不想牺牲功能和可伸缩性。

几个月后，随着 Pod 测试版的发布，我们对在 GAE 的决定很满意。有一些挑战，但我们经历的大多数“怪癖”都是积极的。

这就是我们喜欢 GAE 的地方:

我们的 web 服务器配置适合不到 100 行的 YAML 。实例类、应用版本、路由甚至环境变量都在这个简单的文件中管理。它是透明的，并被检入 Git。
数据存储有一个学习曲线，但现在我们喜欢它。由于来自关系数据库背景，一开始很难找到云数据存储。它有一些限制——最明显的是，不能进行连接，并且许多读取操作缺乏很强的一致性。你接受了这个紧身衣，作为可伸缩性和速度的交换。
错误报告是无缝的。错误报告连接到所有实例的整合应用程序日志，因此您可以立即看到任何异常的完整跟踪，以及问题发生的位置和频率。该系统针对报告错误而不是对错误进行分类进行了优化，但有一个选项可以将问题连接到 GitHub 或其他外部服务。
远程作业(称为任务)是无缝的。吞吐量、重试次数和任务路由在另一个简单的 YAML 文件中管理。在 web 控制台中查看队列很容易。
GAE 简化安全措施。我们甚至不知道我们的网络服务器运行的是什么操作系统——我们只知道谷歌已经覆盖了它，他们有数百名安全工程师在监视恶意软件。这缩小了我们需要担心的安全风险的范围。GAE 甚至提供了一个安全扫描仪，用于探测我们网站上的 XSS 病毒和过时的软件包。
对所有 Google APIs 的访问是统一的。由于 Pod 是一个连接到几个谷歌服务的日历，我们大量使用谷歌 API。在一个地方管理配额和访问权限非常方便。

GAE 的成本随着你的应用程序正在进行的计算量而增加——当你不使用实例时，完全关闭它们。到目前为止，web 服务器一直是我们成本的主要组成部分，尽管我们对数据存储、BigQuery 和云存储做了大量的写入工作。

如果没有一些问题，这就不是一场婚姻，我们肯定也有过对谷歌感到焦虑的时候。谷歌使用内部问题追踪器来管理 bug 和功能请求，某些团队在分类方面做得非常好，而其他团队似乎很少关注。

另一个具有挑战性的地方是 BigQuery。与 Redshift 类似，很难避免重复数据，因为 BigQuery 是仅追加的，并且不支持主键。然而，这可以通过应用程序设计来解决。BigQuery 的另一个问题是可靠性和缺乏谷歌的沟通。我们发现状态页面可能完全错误——有时长达数小时。当 BigQuery 宕机时，我们通常会联系谷歌的朋友，看看他们是否知道这件事。

最后，如果我们不进行黑客攻击，我们想不出 Google 栈支持子串搜索的任何方法。如果你想搜索部分字符串(例如，一个“Justi”在用户输入 ahead 中找到“Justin”)，你只是运气不好——搜索 API 不这么做(NDB 也不这么做)。

然而，总的来说，我们非常高兴能与谷歌合作。与 AWS 相比，谷歌感觉更简单，更有价值，更重要的是，更容易接近。这就好像谷歌有构建云应用的经验一样！围绕存储和移动数据的所有技术难题都已解决；通过共享这些解决方案，他们使像我们这样的开发人员不再考虑基础设施，而是专注于构建优秀的产品。

那就有趣多了。