Hacker News Reader

Comment by skybrian | Hacker News Reader

How does this compare to App Engine? The most obvious difference I see is that App Engine lets you handle HTTP requests using a variety of languages, not just JavaScript.

View on HN

App Engine is great when you want a scalable service that you use to talk directly to your backend services. Cloud Functions lets you extend an existing service with custom code. The best example is Cloud Storage and thumbnailing. If you wanted to automatically create thumbnails for images you could do that easily with an endpoint on app engine. The only problem is you'd lose out on all the other features that Cloud Storage for Firebase offers like automatic resume and 3p authorization. Instead you could write a Cloud Function that creates thumbnails as a side effect and your client app keeps talking directly to a BaaS.

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.

Okay, 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.

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

I'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.

Authentication, realtime db, cloud messaging etc., which I guess are also not part of App engine offerings ?

Reply on news.ycombinator.com