When to choose App Engine over Cloud Functions?

Question

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".

• both CF and AE are stateless
• both suppose to execute during limited period of time
• both can interact with dbs and other gcp apis.

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?

Answer 1

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.

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.

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

• 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.