我想知道App Engine和Compute Engine之间的区别是什么 . 任何人都可以向我解释这个区别吗？
除了上面的App Engine vs Compute Engine注释之外，此处的列表还包括与Google Kubernete Engine的比较以及基于从小到大的各种应用程序的经验的一些注释 . 有关更多要点，请参阅Google Cloud Platform文档，在页面Choosing an App Engine Environment上对App Engine标准版和Flex版中的功能进行高级描述 . 有关App Engine和Kubernetes部署的另一个比较，请参阅Daz Wilkin的文章App Engine Flex or Kubernetes Engine .
App Engine Standard
优点
对于低流量应用而言，直接成本以及维护应用的成本非常经济 .
自动缩放速度很快 . App Engine中的自动缩放基于轻量级instance classes F1-F4 .
版本管理和traffic splitting快速方便 . 这些功能本身内置于App Engine（标准版和Flex版）中 .
最小的管理，开发人员只需关注他们的应用程序 . 与GCE一样，开发人员无需担心像GCE一样可靠地管理VM，也不需要像GKE一样了解集群 .
访问数据存储区很快 . 首次发布App Engine时，运行时与Datastore位于同一位置 . 后来的数据存储区被拆分为独立产品Cloud Datastore，但App Engine标准服务与数据存储区的共址仍然存在 .
支持访问Memcache .
App Engine沙箱非常安全 . 与GCE或其他虚拟机上的开发相比，您需要自己努力防止虚拟机在操作系统级别被接管，默认情况下，App Engine Standard沙箱相对安全 .
缺点
通常比其他环境更受限制实例更小 . 虽然这对于快速自动扩展很有用，但许多应用程序可以从更大的实例中受益，例如GCE实例大小高达96个内核 .
网络未与GCE集成
无法将App Engine置于Google Cloud Load Balancer之后 . 受支持的运行时限制：Python 2.7，Java 7和8，Go 1.6-1.9和PHP 5.5 . 在Java中，有一些对Servlet的支持，但不支持完整的J2EE标准 .
App Engine Flex
可以使用自定义运行时
与GCE网络的本机集成
版本和流量管理方便，与标准相同
较大的实例大小可能更适合于大型复杂应用程序，尤其是可以使用大量内存的Java应用程序
网络集成并不完美 - 不与内部负载 balancer 器或共享虚拟私有 Cloud 集成
访问托管的Memcache通常不可用
Google Kubernetes Engine
与容器的本机集成允许自定义运行时和对集群配置的更好控制 .
体现了许多使用虚拟机的最佳实践，例如immutable runtime environments以及回滚到以前版本的简便能力
提供一致且可重复的部署框架
基于开放标准，特别是Kubernetes，用于 Cloud 和本地之间的可移植性 .
版本管理可以使用Docker容器和Google Container Registry完成
交通分配和管理是自己动手，可能利用Istio和Envoy
一些管理开销
一段时间来提升Kubernetes概念，例如pod，部署，服务，入口和名称空间
需要公开一些公共IP，除非使用现在处于测试阶段的Private Clusters消除了这种需求，但您仍然需要提供对将运行kubectl命令的位置的访问权限 .
监控集成并不完美
虽然Kubernetes Engine本身支持L3内部负载 balancer ，但L7内部负载 balancer 是自己动手，可能利用Envoy
Compute Engine
易于提升 - 无需在Kubernetes或App Engine上使用，只需重复使用您之前的经验 . 这可能是直接使用Compute Engine的主要原因 .
完全控制 - 您可以直接利用许多计算引擎功能并安装最新的所有您喜欢的东西，以保持最前沿 .
无需公共IP . 如果在公共IP上暴露任何内容，某些传统软件可能难以锁定 .
您可以利用容器优化的操作系统来运行Docker容器
尽管您可以重复使用来自各个地方的解决方案，包括Cloud Launcher，但主要是自己动手，为充分提高可靠性和安全性可能具有挑战性 .
更多管理开销 . Compute Engine有许多管理工具，但他们不一定了解您如何部署应用程序，例如App Engine和Kubernetes Engine监控工具 .
Autoscaling基于GCE实例，可能比App Engine慢
趋势是在雪花GCE实例上安装软件，这可能需要一些维护工作
App Engine使开发人员能够控制Google Compute Engine内核，并为Google Compute Engine数据处理应用程序提供面向Web的前端 .
另一方面，Compute Engine为您的虚拟机提供直接和完整的操作系统管理 . 要展示您的应用程序，您将需要资源，而Google Cloud 端存储非常适合存储您的资产和数据，无论它们用于何种用途 . 您可以通过全球托管获得快速数据访问 . 可靠性保证在99.95％的正常运行时间，Google还提供备份和恢复数据的功能，不管您信不信，存储是无限的 .
您可以使用Google Cloud 端存储管理资产，存储，检索，显示和删除资产 . 您还可以快速读取和写入保存在 Cloud 存储中的平面数据表 . Google Cloud阵容中的下一个是BigQuery . 使用BigQuery，您可以在几秒钟内分析大量数据，我们正在谈论数百万条记录 . 通过简单的UI或Representational State Transfer或REST接口处理访问 .
正如您可能怀疑的那样，数据存储不是问题，并且可以扩展到数百TB . BigQuery可以通过许多客户端库访问，包括Java，.NET，Python，Go，Ruby，PHP和Javascript . 可以使用类似SQL的语法NoSQL，可以通过这些客户端库或Web用户界面访问 . 最后，我们来谈谈Google Cloud 平台数据库选项，Cloud SQL和Cloud Datastore .
有一个主要的区别 . Cloud SQL用于关系数据库，主要用于MySQL，而Cloud Datastore用于使用noSQL的非关系数据库 . 使用Cloud SQL，您可以选择在美国，欧洲或亚洲托管，每个数据库实例具有100 GB的存储空间和16 GB的RAM .
Cloud Datastore每月最多可提供50 K读/写指令，每月也可存储1 GB数据 . 但是，如果超过这些配额，则需要付费 . App Engine还可以与其他鲜为人知，更具针对性的Google Cloud 平台成员合作，包括用于创建API后端的Cloud Endpoints，用于数据分析和趋势预测的Google Prediction API，或用于多语言输出的Google Translate API .
虽然您可以单独使用App Engine，但当您考虑其使用其Google Cloud 平台平台服务轻松高效地工作的能力时，它可能会飙升 .
基本区别在于Google App Engine (GAE)是Platform as a Service (PaaS)而Google Compute Engine (GCE)是Infrastructure as a Service (IaaS) .
要在GAE中运行您的应用程序，您只需编写代码并将其部署到GAE中，没有其他问题 . 由于GAE具有完全可扩展性，因此在流量较高时会自动获取更多实例，并在流量减少时减少实例 . 您将被收取 really use 的资源费用，我的意思是，您将收到真正使用的应用程序的 Instance-Hours ， Transferred Data ， Storage 等费用 . 但限制是，您只能在 **Python, PHP, Java, NodeJS, .NET, Ruby and Go 中创建应用程序 .
另一方面，GCE以 Virtual Machine 的形式为您提供完整的基础设施 . 您可以完全控制这些VM的环境和运行时，因为您可以在那里编写或安装任何程序 . 实际上，GCE是虚拟使用Google数据中心的方式 . 在GCE中，您必须手动配置基础结构以使用 Load Balancer 来处理 scalability .
GAE和GCE都是Google Cloud Platform的一部分 .
Update: 2014年3月，Google在App Engine下宣布了一项名为 Managed Virtual Machine 的新服务 . 托管虚拟机为应用程序引擎应用程序提供了比应用程序平台，CPU和内存选项更多的灵活性 . 与GCE一样，您可以在这些VM中为应用程序引擎应用程序创建自定义运行时环境 . 实际上App Engine的托管虚拟机在某种程度上模糊了IAAS和PAAS之间的边界 .
简单地说：计算引擎为您提供了一个您完全控制/负责的服务器 . 您可以直接访问操作系统，并安装所需的所有软件，通常是Web服务器，数据库等......
在app引擎中，您不管理任何底层软件的操作系统 . 你只上传代码（Java，PHP，Python或Go）和瞧 - 它只是运行...
应用程序引擎可以节省大量的头痛，特别是对于没有经验的人来说，但它有两个明显的缺点：1 . 更昂贵（但它确实有一个免费配额计算引擎没有）2 . 你控制较少，因此某些事情不是可能的，或者只能以一种特定的方式（例如保存和写入文件） .
App Engine 是一种平台即服务 . 这意味着您只需部署代码，平台即可为您完成其他所有操作 . 例如，如果您的应用变得非常成功，App Engine将自动创建更多实例来处理增加的卷 .
Read more about App Engine
Compute Engine 是基础设施即服务 . 您必须创建和配置自己的虚拟机实例 . 它为您提供了更大的灵活性，并且通常比App Engine的成本低得多 . 缺点是您必须自己管理您的应用程序和虚拟机 .
Read more about Compute Engine
如有必要，您可以混合App Engine和Compute Engine . 它们都适用于Google Cloud Platform的其他部分 .
编辑（2016年5月）：
一个更重要的区别：如果没有请求进入，在App Engine上运行的项目可以缩小到零实例 . 这在开发阶段非常有用，因为您可以持续数周而无需超过实时小时的慷慨免费配额 . 灵活的运行时（即“受管VM”）需要至少一个实例不断运行 .
编辑（2017年4月）：
Cloud Functions （目前处于测试阶段）在抽象方面是App Engine的下一级别 - 没有实例！它允许开发人员部署一小部分代码，这些代码响应不同的事件而执行，这些事件可能包括HTTP请求， Cloud 存储中的更改等 .
与App Engine最大的区别在于功能的价格是每100毫秒，而App Engine的实例仅在15分钟不活动后关闭 . 另一个优点是Cloud Functions立即执行，而对App Engine的调用可能需要一个新实例 - 冷启动新实例可能需要几秒或更长时间（取决于运行时和代码） .
这使得Cloud Functions非常适合（a）罕见的调用 - 不需要保存实例，以防万一发生，（b）快速更改实例经常旋转和关闭的负载，以及可能更多的用例 .
Read more about Cloud Functions
或者使其更简单（因为有时我们无法区分GAE标准和GAE Flex）：
Compute Engine 类似于虚拟PC，您负责设置DNS等 .
Google App Engine (Standard) 就像一个只读的沙盒文件夹，您可以在其中上传要执行的代码，而不必担心其余的（是：只读） . DNS /子域等更容易映射 .
Google App Engine (Flexible) 实际上就像一个完整的文件系统（不仅仅是一个锁定的文件夹），你的功能比标准引擎更强大，例如您具有读/写权限（但与计算引擎相比较少） . 在GAE标准中，您为您安装了一组固定的库，您无法随意部署第三方库 . 在Flexible环境中，您可以安装应用程序所依赖的任何库，包括自定义构建环境（例如Python 3） .
尽管GAE标准处理起来非常麻烦（虽然谷歌听起来很简单），但是当它处于压力之下时，它的扩展性非常好 . 这很麻烦，因为您需要测试并确保与锁定环境的兼容性，并确保您使用的任何第三方库不使用任何其他您不知道的可能无法在GAE标准上工作的第三方库 . 在实践中设置它需要更长的时间，但对于简单部署而言，从长远来看可能会更有 Value .
6 回答
除了上面的App Engine vs Compute Engine注释之外，此处的列表还包括与Google Kubernete Engine的比较以及基于从小到大的各种应用程序的经验的一些注释 . 有关更多要点，请参阅Google Cloud Platform文档，在页面Choosing an App Engine Environment上对App Engine标准版和Flex版中的功能进行高级描述 . 有关App Engine和Kubernetes部署的另一个比较，请参阅Daz Wilkin的文章App Engine Flex or Kubernetes Engine .
App Engine Standard
优点
对于低流量应用而言，直接成本以及维护应用的成本非常经济 .
自动缩放速度很快 . App Engine中的自动缩放基于轻量级instance classes F1-F4 .
版本管理和traffic splitting快速方便 . 这些功能本身内置于App Engine（标准版和Flex版）中 .
最小的管理，开发人员只需关注他们的应用程序 . 与GCE一样，开发人员无需担心像GCE一样可靠地管理VM，也不需要像GKE一样了解集群 .
访问数据存储区很快 . 首次发布App Engine时，运行时与Datastore位于同一位置 . 后来的数据存储区被拆分为独立产品Cloud Datastore，但App Engine标准服务与数据存储区的共址仍然存在 .
支持访问Memcache .
App Engine沙箱非常安全 . 与GCE或其他虚拟机上的开发相比，您需要自己努力防止虚拟机在操作系统级别被接管，默认情况下，App Engine Standard沙箱相对安全 .
缺点
通常比其他环境更受限制实例更小 . 虽然这对于快速自动扩展很有用，但许多应用程序可以从更大的实例中受益，例如GCE实例大小高达96个内核 .
网络未与GCE集成
无法将App Engine置于Google Cloud Load Balancer之后 . 受支持的运行时限制：Python 2.7，Java 7和8，Go 1.6-1.9和PHP 5.5 . 在Java中，有一些对Servlet的支持，但不支持完整的J2EE标准 .
App Engine Flex
优点
可以使用自定义运行时
与GCE网络的本机集成
版本和流量管理方便，与标准相同
较大的实例大小可能更适合于大型复杂应用程序，尤其是可以使用大量内存的Java应用程序
缺点
网络集成并不完美 - 不与内部负载 balancer 器或共享虚拟私有 Cloud 集成
访问托管的Memcache通常不可用
Google Kubernetes Engine
优点
与容器的本机集成允许自定义运行时和对集群配置的更好控制 .
体现了许多使用虚拟机的最佳实践，例如immutable runtime environments以及回滚到以前版本的简便能力
提供一致且可重复的部署框架
基于开放标准，特别是Kubernetes，用于 Cloud 和本地之间的可移植性 .
版本管理可以使用Docker容器和Google Container Registry完成
缺点
交通分配和管理是自己动手，可能利用Istio和Envoy
一些管理开销
一段时间来提升Kubernetes概念，例如pod，部署，服务，入口和名称空间
需要公开一些公共IP，除非使用现在处于测试阶段的Private Clusters消除了这种需求，但您仍然需要提供对将运行kubectl命令的位置的访问权限 .
监控集成并不完美
虽然Kubernetes Engine本身支持L3内部负载 balancer ，但L7内部负载 balancer 是自己动手，可能利用Envoy
Compute Engine
优点
易于提升 - 无需在Kubernetes或App Engine上使用，只需重复使用您之前的经验 . 这可能是直接使用Compute Engine的主要原因 .
完全控制 - 您可以直接利用许多计算引擎功能并安装最新的所有您喜欢的东西，以保持最前沿 .
无需公共IP . 如果在公共IP上暴露任何内容，某些传统软件可能难以锁定 .
您可以利用容器优化的操作系统来运行Docker容器
缺点
尽管您可以重复使用来自各个地方的解决方案，包括Cloud Launcher，但主要是自己动手，为充分提高可靠性和安全性可能具有挑战性 .
更多管理开销 . Compute Engine有许多管理工具，但他们不一定了解您如何部署应用程序，例如App Engine和Kubernetes Engine监控工具 .
Autoscaling基于GCE实例，可能比App Engine慢
趋势是在雪花GCE实例上安装软件，这可能需要一些维护工作
App Engine使开发人员能够控制Google Compute Engine内核，并为Google Compute Engine数据处理应用程序提供面向Web的前端 .
另一方面，Compute Engine为您的虚拟机提供直接和完整的操作系统管理 . 要展示您的应用程序，您将需要资源，而Google Cloud 端存储非常适合存储您的资产和数据，无论它们用于何种用途 . 您可以通过全球托管获得快速数据访问 . 可靠性保证在99.95％的正常运行时间，Google还提供备份和恢复数据的功能，不管您信不信，存储是无限的 .
您可以使用Google Cloud 端存储管理资产，存储，检索，显示和删除资产 . 您还可以快速读取和写入保存在 Cloud 存储中的平面数据表 . Google Cloud阵容中的下一个是BigQuery . 使用BigQuery，您可以在几秒钟内分析大量数据，我们正在谈论数百万条记录 . 通过简单的UI或Representational State Transfer或REST接口处理访问 .
正如您可能怀疑的那样，数据存储不是问题，并且可以扩展到数百TB . BigQuery可以通过许多客户端库访问，包括Java，.NET，Python，Go，Ruby，PHP和Javascript . 可以使用类似SQL的语法NoSQL，可以通过这些客户端库或Web用户界面访问 . 最后，我们来谈谈Google Cloud 平台数据库选项，Cloud SQL和Cloud Datastore .
有一个主要的区别 . Cloud SQL用于关系数据库，主要用于MySQL，而Cloud Datastore用于使用noSQL的非关系数据库 . 使用Cloud SQL，您可以选择在美国，欧洲或亚洲托管，每个数据库实例具有100 GB的存储空间和16 GB的RAM .
Cloud Datastore每月最多可提供50 K读/写指令，每月也可存储1 GB数据 . 但是，如果超过这些配额，则需要付费 . App Engine还可以与其他鲜为人知，更具针对性的Google Cloud 平台成员合作，包括用于创建API后端的Cloud Endpoints，用于数据分析和趋势预测的Google Prediction API，或用于多语言输出的Google Translate API .
虽然您可以单独使用App Engine，但当您考虑其使用其Google Cloud 平台平台服务轻松高效地工作的能力时，它可能会飙升 .
基本区别在于Google App Engine (GAE)是Platform as a Service (PaaS)而Google Compute Engine (GCE)是Infrastructure as a Service (IaaS) .
要在GAE中运行您的应用程序，您只需编写代码并将其部署到GAE中，没有其他问题 . 由于GAE具有完全可扩展性，因此在流量较高时会自动获取更多实例，并在流量减少时减少实例 . 您将被收取 really use 的资源费用，我的意思是，您将收到真正使用的应用程序的 Instance-Hours ， Transferred Data ， Storage 等费用 . 但限制是，您只能在 **Python, PHP, Java, NodeJS, .NET, Ruby and Go 中创建应用程序 .
另一方面，GCE以 Virtual Machine 的形式为您提供完整的基础设施 . 您可以完全控制这些VM的环境和运行时，因为您可以在那里编写或安装任何程序 . 实际上，GCE是虚拟使用Google数据中心的方式 . 在GCE中，您必须手动配置基础结构以使用 Load Balancer 来处理 scalability .
GAE和GCE都是Google Cloud Platform的一部分 .
Update: 2014年3月，Google在App Engine下宣布了一项名为 Managed Virtual Machine 的新服务 . 托管虚拟机为应用程序引擎应用程序提供了比应用程序平台，CPU和内存选项更多的灵活性 . 与GCE一样，您可以在这些VM中为应用程序引擎应用程序创建自定义运行时环境 . 实际上App Engine的托管虚拟机在某种程度上模糊了IAAS和PAAS之间的边界 .
简单地说：计算引擎为您提供了一个您完全控制/负责的服务器 . 您可以直接访问操作系统，并安装所需的所有软件，通常是Web服务器，数据库等......
在app引擎中，您不管理任何底层软件的操作系统 . 你只上传代码（Java，PHP，Python或Go）和瞧 - 它只是运行...
应用程序引擎可以节省大量的头痛，特别是对于没有经验的人来说，但它有两个明显的缺点：1 . 更昂贵（但它确实有一个免费配额计算引擎没有）2 . 你控制较少，因此某些事情不是可能的，或者只能以一种特定的方式（例如保存和写入文件） .
App Engine 是一种平台即服务 . 这意味着您只需部署代码，平台即可为您完成其他所有操作 . 例如，如果您的应用变得非常成功，App Engine将自动创建更多实例来处理增加的卷 .
Read more about App Engine
Compute Engine 是基础设施即服务 . 您必须创建和配置自己的虚拟机实例 . 它为您提供了更大的灵活性，并且通常比App Engine的成本低得多 . 缺点是您必须自己管理您的应用程序和虚拟机 .
Read more about Compute Engine
如有必要，您可以混合App Engine和Compute Engine . 它们都适用于Google Cloud Platform的其他部分 .
编辑（2016年5月）：
一个更重要的区别：如果没有请求进入，在App Engine上运行的项目可以缩小到零实例 . 这在开发阶段非常有用，因为您可以持续数周而无需超过实时小时的慷慨免费配额 . 灵活的运行时（即“受管VM”）需要至少一个实例不断运行 .
编辑（2017年4月）：
Cloud Functions （目前处于测试阶段）在抽象方面是App Engine的下一级别 - 没有实例！它允许开发人员部署一小部分代码，这些代码响应不同的事件而执行，这些事件可能包括HTTP请求， Cloud 存储中的更改等 .
与App Engine最大的区别在于功能的价格是每100毫秒，而App Engine的实例仅在15分钟不活动后关闭 . 另一个优点是Cloud Functions立即执行，而对App Engine的调用可能需要一个新实例 - 冷启动新实例可能需要几秒或更长时间（取决于运行时和代码） .
这使得Cloud Functions非常适合（a）罕见的调用 - 不需要保存实例，以防万一发生，（b）快速更改实例经常旋转和关闭的负载，以及可能更多的用例 .
Read more about Cloud Functions
或者使其更简单（因为有时我们无法区分GAE标准和GAE Flex）：
Compute Engine 类似于虚拟PC，您负责设置DNS等 .
Google App Engine (Standard) 就像一个只读的沙盒文件夹，您可以在其中上传要执行的代码，而不必担心其余的（是：只读） . DNS /子域等更容易映射 .
Google App Engine (Flexible) 实际上就像一个完整的文件系统（不仅仅是一个锁定的文件夹），你的功能比标准引擎更强大，例如您具有读/写权限（但与计算引擎相比较少） . 在GAE标准中，您为您安装了一组固定的库，您无法随意部署第三方库 . 在Flexible环境中，您可以安装应用程序所依赖的任何库，包括自定义构建环境（例如Python 3） .
尽管GAE标准处理起来非常麻烦（虽然谷歌听起来很简单），但是当它处于压力之下时，它的扩展性非常好 . 这很麻烦，因为您需要测试并确保与锁定环境的兼容性，并确保您使用的任何第三方库不使用任何其他您不知道的可能无法在GAE标准上工作的第三方库 . 在实践中设置它需要更长的时间，但对于简单部署而言，从长远来看可能会更有 Value .