Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Cloud Functions for Firebase

firebase.googleblog.com

Post reply on HN
Print view View original

21–30 of 129 posts

Re: Introducing Cloud Functions for Firebase

#21

Post by keithwinstein »

This looks like a worthy competitor to AWS Lambda, but I'm disappointed by the unalterable limit of 400 concurrent invocations of a function. (The "Quotas" page says "Max concurrent functions" is 400, with "Can be increased" as "No." https://cloud.google.com/functions/quotas)

One of the cool things about AWS Lambda is that you can use it as a short-term supercomputer with thousands of threads. We (Stanford/UCSD ExCamera) are using AWS Lambda to do massively parallel low-latency video encoding with 4,000+ concurrent threads. Our colleagues at U.C. Berkeley who built PyWren are doing machine learning on Lambda with similar numbers of threads. AWS has been encouraging to us for these kind of workloads, even if they aren't what Amazon initially envisioned.

So a hard limit of 400 (that can't be increased) would be a real bummer. I wonder if we can get around this by defining 20 identical functions and then invoking each one 400 times in parallel...

Re: Introducing Cloud Functions for Firebase

#22

Post by inlined »

drumttocs8 wrote: post #18
brendanlim wrote: post #3

(Cloud Functions for Firebase PM here) We’ve been developing this product for years, and we’ve had it in private alpha testing for well over a year, so we’re incredibly excited to finally take the wrappings off and let all of you try it. Firebase has always focused on empowering you all to build extraordinary experiences for your users, without needing to worry about building common infrastructure. While we’ve made b…

From an onboarding and testing perspective, it would be nice to be able to integrate other services ("Outbound networking"?) in the free tier. Maybe limit to one connection?

There's a bit of a nuance here. Even if you join the Blaze plan (pay as you go) there's still a large free quota. The quota is actually much larger than you get with Spark as well. We just can't allow arbitrary REST calls without a credit card. This helps avoid Cloud Functions being used for abuse/malware.

Re: Introducing Cloud Functions for Firebase

#24

Post by inlined »

nodesocket wrote: post #12

I plan on doing a benchmark and blog post of a simple node http function that just returns 200 and using Blitz.io to benchmark average startup latency of Google Functions. Curious to see how it scales as the number of concurrent requests increases and what the variance is.

Let us know what you find. Be keep an eye on your usage and quotas in the Google Cloud console if you hit any limits.

Re: Introducing Cloud Functions for Firebase

#26

Post by boulos »

Like many of you, I'm incredibly happy about how this:

> This has been the most requested feature since Firebase launched

is finally in place. Firebase is a great option for quickly getting something together, and now that you can extend it with little compute, this really is a massive expansion of what you can achieve.

Disclosure: I work on Google Cloud (and sit near the Firebase folks!).

Re: Introducing Cloud Functions for Firebase

#27

Post by inlined »

keithwinstein wrote: post #21

This looks like a worthy competitor to AWS Lambda, but I'm disappointed by the unalterable limit of 400 concurrent invocations of a function. (The "Quotas" page says "Max concurrent functions" is 400, with "Can be increased" as "No." https://cloud.google.com/functions/quotas ) One of the cool things about AWS Lambda is that you can use it as a short-term supercomputer with thousands of threads. We (Stanford/UCSD ExCa…

If you need more than 400 concurrent invocations please reach out to support (not promising whether or not we'll be able to satisfy arbitrary scale just yet). We're on day one of a Beta product and it'll keep getting better.

Re: Introducing Cloud Functions for Firebase

#28

Post by tedmiston »

habosa wrote: post #10
tedmiston wrote: post #4

So it looks like very roughly AWS Lambda in JS only for Firebase with nice user event hooks and Firebase Cloud Messaging. I'm wondering how they handle: 1 - pricing 2 - support for long-running tasks (where Lambda does not) 3 - official tooling for packaging and deployment (perhaps the biggest critique of Lambda) It sounds like one could build an entire real app in this, which is quite cool.

You can see pricing details here: https://firebase.google.com/pricing/ It's based on invocations, GB-seconds, CPU-seconds, and network egress. And there's a free tier, so you should be able to try with your use case and estimate your total future cost.

Ah, sadly no outbound networking requests on the free tier. In my opinion that is a critical use case for a tool like this.

This could be a non-starter if there's really no way try it for outbound requests without paying $25 / month. Hopefully I'm misunderstanding the pricing page.

Edit: The fine print for the custom plan:

> 3 The Spark plan only allows outbound network requests to Google owned services. On the Blaze plan, Cloud Functions provides a perpetual free tier. The first 2,000,000 invocations, 400,000 GB-sec, 200,000 CPU-sec, and 5GB of Internet egress traffic is provided for free each month. You are only charged on usage past this free allotment. Pricing is based on total number of invocations, and compute time. Compute time is variable based on the amount of memory and CPU provisioned for a function. For more information, see Cloud Functions Pricing.

Re: Introducing Cloud Functions for Firebase

#29

Post by habosa »

skybrian wrote: post #25

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.

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.

Re: Introducing Cloud Functions for Firebase

#30

Post by phpencil »

inlined wrote: post #27
keithwinstein wrote: post #21

This looks like a worthy competitor to AWS Lambda, but I'm disappointed by the unalterable limit of 400 concurrent invocations of a function. (The "Quotas" page says "Max concurrent functions" is 400, with "Can be increased" as "No." https://cloud.google.com/functions/quotas ) One of the cool things about AWS Lambda is that you can use it as a short-term supercomputer with thousands of threads. We (Stanford/UCSD ExCa…

If you need more than 400 concurrent invocations please reach out to support (not promising whether or not we'll be able to satisfy arbitrary scale just yet). We're on day one of a Beta product and it'll keep getting better.

And just to clarify, Cloud Functions for Firebase is covered under the Firebase free support, who you can reach here: https://firebase.google.com/support/contact/troubleshooting/
Post reply on HN