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?

Solution 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, Go, Java, .NET Core, and Ruby. 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
  • (most of the time) the handling code is already loaded; CFs' code still needs to be loaded. Not too sure about this one; I guess it depends on the underlying implementation.

Solution 2

App Engine is better suited to applications, which have numerous pieces of functionality behaving in various inter-related (or even unrelated) ways, while cloud functions are more specifically single-purpose functions that respond to some event and perform some specific action.

App Engine offers numerous choices of language, and more management options, while cloud functions are limited in those areas.

You could easily replicate Cloud Functions on App Engine, but replicating a large scale App Engine application using a bunch of discrete Could Functions would be complicated. For example, the backend of Spotify is App Engine based.

Another way to put this is that for a significantly large application, starting with a more complex system like App Engine can lead to a codebase which is less complex, or at least, easier to manage or understand.

Ultimately these both run on similar underlying infrastructure at Google, and it's up to you to decide which one works for the task at hand. Furthermore, There is nothing stopping you from mixing elements of both in a single project.

Solution 3

Google Cloud Functions are simple , single purpose functions which are fired while watching event(s).

These function will remove need to build your own application servers to handle light weight APIs.

Main use cases :

1. Data processing / ETL : Listen and respond to Cloud Storage events, e.g. File created , changed or removed )
2. Webhooks : Via a simple HTTP trigger, respond to events originating from 3rd party systems like GitHub)
3. Lightweight APIs : Compose applications from lightweight, loosely coupled bits of logic
4. Mobile backend: Listen and respond to events from Firebase Analytics, Realtime Database, Authentication, and Storage
5. IoT: Thousands of devices streaming events and which in-turn calls google cloud functions to transform and store data

App Engine is meant for building highly scalable applications on a fully managed serverless platform. It will help you to focus more on code. Infrastructure and security will be provided by AE

It will support many popular programming languages. You can bring any framework to app engine by supplying docker container.

Use cases:

1. Modern web application to quickly reach customers with zero config deployment and zero server management.

2. Scalable mobile backends : Seamless integration with Firebase provides an easy-to-use frontend mobile platform along with the scalable and reliable back end.

Refer to official documentation pages of Cloud functions and App Engine

Comments

[stkvtflw]

Spotify example is misleading: it's developed before CF was introduced.

[Cameron Roberts]

I still think it serves as a good example of a complex application better suited to App Engine than Cloud Functions, because it requires things like session management and consists of many individual components presented as a cohesive application.

[stkvtflw]

Can't i create "inter-related" CF? i'm pretty sure there is no problems with that. If i understood it correctly the rest of your answer says that AE more complex than CF - i understand that, but i don't see any benefits in this.

[stkvtflw]

again, AE suppose to be stateless, so i don't understand how does it help to manage session?

[Cameron Roberts]

Well depending on how you look at it all web based services are inherently "stateless", that doesn't mean they aren't tailored for certain tasks more than others. I have not said App Engine is more complex (although it may be seen that way), I'm saying it's better suited for supporting complex applications, there is a big difference there.

[stkvtflw]

Thank you, Cameron! i think i understand what you mean, i just don't see how exactly "it's better suited for supporting complex applications".

[Cameron Roberts]

I'm trying to think of how to put it more clearly, but the reality is it's difficult because you are right in thinking you can ultimately use either of them to do similar jobs. I think the best way to put it is that sometimes having a more complex system (AE) to build a big project on means the overall application ends up being less complex than it would on a simpler system (CF).

[chaiyachaiya]

Note that nothing prevents us from mixing both notions. An AppEngine application can launch jobs through cloud functions.

[Dan Cornilescu]

@chaiyachaiya Yes, that's possible, too, if it makes more sense in the app's context.

[Amit Bens]

I think another way of putting it - CF are more basic building blocks and AE is a more advanced framework with more out-of-the-box capabilities, so you could either implement with the small building blocks or with the more comprehensive solution.

[Luke359]

CFs aren't limited only to Node.js because now it supports Python too.

[Jens]

And Go is supported as well

[Sventies]

Is there a way to 'quantify' this? Say I have an express app that manages 8 db models and handles 20 different endpoints, would app engine or cloud functions be a better suit?