4 ms·
It's a pretty different model, so not really an apples-to-apples comparison. Cloud Functions are bits of code that run in response to events, whether those are
by habosa 10y ago
It's a pretty different model, so not really an apples-to-apples comparison. Cloud Functions are bits of code that run in response to events, whether those are events from Google Cloud / Firebase or HTTP triggers. These functions scale up and down as the event load changes.
App Engine is a more traditional PaaS offering where you upload and entire web app, something you might otherwise run on your own server or a bare VM.
- skybrian 10y agoOkay, but App Engine also scales up and down on demand. And an HTTP trigger is just an HTTP request; it can be stateless if you like. So that sounds an awful lot like a function in the cloud. The part I'm not clear about is whether you can send non-HTTP events to App Engine or not? It seems like it might be useful.
- deleted 10y ago[deleted]
- camus2 10y agoBoth can be used as a swarm of workers, that's basically what "functions as a service" are. The difference is usually in the pricing strategy. with "FAAS", you pay only when the worker works, you're not paying when the server running them is idle, as opposed to classic server instances. App Engine standard has a few nice ideas in the way it implements push and pull worker queues, but given its limitations it was never going to be a huge success. But "FAAS" is obviously not suitable to serve a "user facing" website, and rely heavily on vendor locked in API that cannot be transferred to another vendor. Containerized worker jobs make more sense than "FAAS" IMHO. SAAS like iron.io provide that.
- katowulf 10y agoI'd argue there's a maintenance cost to consider as well. Functions are "serverless" from the dev point of view, where the dev needs to maintain App Engine services, scaling strategies, and so on. It's basically the next step up in the abstraction chain: On prem (you build) > Compute > App Engine > Functions.