何时选择基于云功能的App Engine? [英] When to choose App Engine over Cloud Functions?

问题描述

抱歉，如果这是一个幼稚的问题，但是我看过Google员工的一堆谈话，仍然不明白为什么我会使用AE而不是CF?

Sorry, if this is a naive question, but i've watched bunch of talks from google's staff and still don't understand why on earth i would use AE instead of CF?

如果我正确理解的话，这两项服务的整个概念就是建立微服务架构".

If i understood it correctly, the whole concept of both of these services is to build "microservice architecture".

• CF和AE都是无状态的
• 两者都想在有限的时间内执行
• 两者都可以与dbs和其他gcp api交互.

尽管如此，AE必须包装到自己的服务器中.基本上，除了与CF相同的功能外，它还利用了许多复杂性.所以，我什么时候应该用它代替CF?

Though, AE must be wrapped into own server. Basically it utilizes a lot of complexities on top of the same capabilities as CF. So, when should i use it instead of CF?

推荐答案

云函数(CF)和Google App Engine(GAE)是用于不同任务的不同工具.使用正确的工具完成工作通常是一个好主意.

Cloud Functions (CFs) and Google App Engine (GAE) are different tools for different jobs. Using the right tool for the job is usually a good idea.

可以用钳子 来钉子，但不会像用锤子那样方便.同样，可以使用CFs 可能构建复杂的应用程序，但是使用GAE构建它肯定会更方便.

Driving a nail using pliers might be possible, but it won't be as convenient as using a hammer. Similarly building a complex app using CFs might be possible, but building it using GAE would definitely be more convenient.

与GAE相比，CF具有许多缺点(当然，在构建更复杂的应用程序的情况下):

CFs have several disadvantages compared to GAE (in the context of building more complex applications, of course):

• 仅限于Node.JS，Python和Go. GAE支持其他几种流行的编程语言
• 它们实际上是为轻量级，独立功能而设计的，试图使用此类组件快速构建复杂的应用程序变得尴尬".是的，每个请求的相互关系上下文也必须在GAE上还原，只有GAE可以从CF上无法使用的更方便的方式中受益.例如其他评论中讨论的用户会话管理
• GAE应用程序具有可在单个请求中保留的应用程序上下文，而CF则没有.这样的上下文可以使GAE应用程序对某些Google服务的访问更加高效/高效(甚至完全有可能)，而对于CF而言则不是.例如memcached.
• GAE应用程序的应用程序上下文可用性可为无法在CF上运行的其他服务支持更高效/性能更好的客户端库.例如，使用ndb客户端库(仅适用于标准env GAE python应用程序)访问数据存储区可能比使用通用数据存储区客户端库更有效/更高效.
• GAE的CF的批发"定价(基于实例小时数，而不管特定实例服务多少次请求)相对于CF的零售"定价(每次调用单独收费)更具成本效益.
li> GAE应用程序的
• 响应时间可能通常比CF短，因为通常处理请求的应用程序实例已在运行，因此:
  • GAE应用上下文不需要加载/还原，它已经可用，CF需要加载/还原
  • (大多数时候)处理代码已经加载，CF的代码仍然需要加载.不知道这一点，我想这取决于底层的实现.
  • they're limited to Node.JS, Python, and Go. GAE supports several other popular programming languages
  • they're really designed for lightweight, standalone pieces of functionality, attempting to build complex applications using such components quickly becomes "awkward". Yes, the inter-relationship context for every individual request must be restored on GAE just as well, only GAE benefits from more convenient means of doing that which aren't available on CFs. For example user session management, as discussed in other comments
  • GAE apps have an app context that survives across individual requests, CFs don't have that. Such context makes access to certain Google services more efficient/performant (or even plain possible) for GAE apps, but not for CFs. For example memcached.
  • the availability of the app context for GAE apps can support more efficient/performant client libraries for other services which can't operate on CFs. For example accessing the datastore using the ndb client library (only available for standard env GAE python apps) can be more efficient/performant than using the generic datastore client library.
  • GAE can be more cost effective as it's "wholesale" priced (based on instance-hours, regardless of how many requests a particular instance serves) compared to "retail" pricing of CFs (where each invocation is charged separately)
  • response times might be typically shorter for GAE apps than CFs since typically the app instance handling the request is already running, thus:
    • the GAE app context doesn't need to be loaded/restored, it's already available, CFs need to load/restore it
    • the handling code is (most of the time) already loaded, CFs' code still needs to be loaded. Not to sure about this one, tho, I guess it depends on the underlying implementation.

    这篇关于何时选择基于云功能的App Engine?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！