Both Cloud Functions (CFs) and Google App Engine (GAE) are designed to build “microservice architecture” in the “serveless” environment.
Google says that Cloud Functions is basically for SERVERLESS FUNCTIONS & EVENTS where as App Engine is for SERVERLESS HTTP APPLICATIONS. However,when I read this short description I am still confused since if I am running SPA application what prevents me to use just CFs for my serverside code? When exactly would use GAE instead of CFs?
I made a small investigation on this and here are my findings.
Little bit more longer description from Google:
Cloud Functions
An event-driven compute platform to easily connect and extend Google and third-party cloud services and build applications that scale from zero to planet scale.
Use Cases
- Asynchronous backend processing
- Simple APIs (like one or two functions, not RESTful stuff)
- Rapid prototyping and API stitching
|
App Engine standard environment
A fully managed serverless application platform for web and API backends. Use popular development languages without worrying about infrastructure management.
Use Cases
- Web applications
- API’s like Mobile and SPA backends
|
I found this answer from StackOverflow which I am updating here with few of my edits.
When creating relatively complex applications, CFs have several disadvantages compared to GAE.
- Limited to Node.JS, Python, and Go. GAE supports also .NET, Ruby, PHP, Java.
- CFS is 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.
Note that nothing prevents us from mixing both notions. An AppEngine application can launch jobs through cloud functions
Summary
Use Cloud Functions (CFs) for “tasks” and use Google App Engine (GAE) for “full applications”.
