何时使用 Google App Engine Flex vs Google Cloud Run

我希望使用 Google 的无服务器选项之一来部署容器化代码。据我所知,谷歌在这方面有两种选择:

  1. Google App Engine 柔性环境
  2. 谷歌云运行 (测试版)

我看了2019年谷歌下一步的谈话 我应该在哪里运行代码? 从5 + 计算选项中选择。我读了 Jerry101对“ Google App Engine 和 Google Cloud Run 有什么区别?”

对我来说,基本上听起来云运行是对使用 Google App Engine 柔性环境的局限性的答案。

我认为选择 App Engine 柔性环境而不是 Cloud Run 的原因是:

  • Legacy -如果你的代码目前依赖于 App Engine Flex,你可能不想移动它
  • Trackrecord -App Engine Flex 已经存在一段时间了,从这个意义上说,它有一个跟踪记录,而 Cloud Run 只是 Beta 版本

但这些都是操作类型的考虑因素。我也不担心。选择 App Engine Flex 而不是 Cloud Run 有什么技术上的优势吗?

谢谢

注意: 针对 App Engine 的 Beta Serverless VPC Access 仅适用于2019年4月发布的 标准环境版本,而不适用于 Flex 版本,所以在 App Engine Flex vs Cloud Run 的问题中不需要考虑这个问题

24986 次浏览

GAE 柔性环境和 Cloud Run 之间的定价模型有些不同。

  • 在 GAE 灵活性中,您总是在任何时候运行至少1个实例。因此,即使你的应用程序没有收到任何请求,你也要为此付费。计费粒度为1分钟。
  • 在 Cloud Run 中,处理请求时使用 只有支付,计费粒度为0.1秒。有关 CloudRun 计费模型的解释,请参见 给你

底层基础设施: 由于 GAE 灵活性是在虚拟机上运行的,所以部署应用程序的新版本并进行扩展要比 Cloud Run 慢一些。云运行部署更快。

可移植性: Cloud Run 使用开放源码的 Knate API 及其 集装箱运输合同。这使您在更大程度上具有灵活性和自由度。如果希望在所管理的基础设施(比如 GKE)上运行相同的工作负载,可以使用“ Cloud Run on GKE”。

简而言之: Appengine 是一个真实的、相对稳定的东西。 Cloud Run 基本上只是一个草案/想法,非常不稳定。

说来话长: 处于 alpha/beta 测试阶段的 Google Cloud Run 可能会经历很多变化。如果你年纪足够大,你可能还记得 Appengine 的定价已经发生了多么戏剧性的变化。它承诺基于 CPU/RAM 的定价,然后它认为这是不“可能的”,或者至少不是非常有利可图,并转移到基于虚拟机的定价,然后他们发布了一个体面的应用引擎版本(Appengine Flex 或者不管它当时有什么名字) ,但是通过增加一个最小实例模型再次提高了价格。更不用说数不清的 API/突破性变化或限制变化了。

Cloud Run 是基于 gVisor 的,它有 有些限制,所以取决于你使用的语言/库和你所做的,它可能会在某个时候崩溃(或者只是谷歌的实现可能会崩溃) ,你什么也做不了(比如修补系统) ,它会破坏你的生产力和潜在的业务。你可以看看它当前的 问题

免费建议: 即使您选择 Appengine 或 Cloud Run 避免专有 API/服务,如 谷歌数据存储。他们可能会毁了你的生意。定价、 API 和 限制将发生变化。没有真正的开源或付费的替代品,所以你的代码是不可移植的。你的代码在 Google 云之外毫无价值。

免责声明: 我已经被应用程序引擎的改变和数据存储的锁定搞得焦头烂额,所以我的观点可能有偏见。

事实上,我建议你认真考虑一下应用引擎云计算。

随着时间的推移,我已经看到一些关于“新的”App Engine 的评论,而且看起来云运行就是那个答案。它处于测试阶段,这可能是个问题。我看到一些公司在生产中使用 beta 服务,而其他公司在等待。然而,如果我今天要开始一个新的应用程序-它肯定会是基于 App Engine Flex 的 Cloud Run。

作为一项商业功能,谷歌对库伯内特的研究非常深入。因为云运行是坐在 GKE-这意味着它是间接接受开发通过其他团队(一般的 GKE 基础设施)。

相反,App Engine 使用的是一些较老的技术。虽然它不坏-它是“昨天”的技术。在我看来,谷歌似乎是一家对新事物和行业高度采用的内容感到非常兴奋的公司。

所有这些都表明——当您将服务包装在一个容器中时,您应该能够在任何地方运行它们?任何有集装箱平台的地方。您可以使用类似于 Cloud Endpoints 的东西来预置您的服务,并且您可以在 App Engine 和 Cloud Run 上来回部署。然后,在这一点上,限制可能是所提供的服务。例如,Cloud Run 目前不支持一些项目,比如云负载平衡或者云存储器。今天可能是个阻断剂。

我有一个作为微服务的带有 REST API 接口的 ML 模型。当我尝试使用 CloudRun 运行时,它进行了部署,但是不能正常工作。我不得不切换回应用程序引擎柔性环境。

Cloud Run (完全管理)目前(2020年7月)的 RAM 限制为2GB。为了更好的硬件,我应该去 Anthose 与 GKE 红外线。但是这至少需要4个实例才能正常工作。 我的是一个小应用程序,我解决了应用程序引擎灵活的环境。虽然自动缩放设置需要最少2个实例,但在早期,可以用手动缩放和1个实例作为限制来管理它。

编辑: 在2020年8月22日,对于完全管理的 GCP Cloud Run,RAM 限制是4GB,核心数量是2。

App Engine 的灵活性 ,注重“代码优先”,以开发者为中心,App Engine 应用由多个服务组成,在部署应用程序的时候你真的不需要做任何命名。

GAE 灵活环境的特点:

  • 不可能缩小到零
  • 任何受支持的 编程语言: Python、 Java、 Node.js、 Go、 Ruby、 PHP 或.NET
  • 在包含自定义运行库或源的 Docker 容器中运行 用其他编程语言编写的代码。
  • 使用或依赖包含本机代码的框架。
  • 访问 Google Cloud 项目的资源或服务 驻留在计算机引擎网络中。
  • 最大请求超时时间: 60分钟

Cloud Run 是一个托管计算平台,它允许你运行可以通过请求或事件调用的容器,一切都是一个服务,不管它是一个实际的服务还是一个带有 web 界面的应用,所以考虑将它用作一个服务的部署,而不是一个应用。

云跑的特点:

  • 它是无服务器的: 它抽象出所有的基础设施管理
  • 这取决于您的应用程序应该是无状态的。
  • GCP 将旋转您的应用程序的多个实例来动态扩展它
  • 缩小到零

您可以使用下面的 url 来获得 云跑应用程序引擎之间的差异。 主机选择

很多时候,在 云跑上使用 应用程序引擎的原因是,云跑没有后台进程。它的响应时间也只有15分钟。

主要区别在于后台任务。

在云运行中,所有事情都由一个请求启动,一旦该请求完成,实例将不再启动。

App Engine also gave you some built in freebies like memory caching, but I don't think that's true of App Engine flex.

对于一个简单的 HTTP API,差异是可以忽略不计的,并且您可以获得 App Engine 为其他 GCP 产品(Cloud Scheduler,Cloud Task)提供的一些内容。

你可以看看这个视频,在云上进行比较和演示: Https://www.youtube.com/watch?v=rvwopvge74c