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...
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.
Ooh, I like that phrase for the front line of triage. "Is this troubleshooting, a bug report, or a feature request?" I kind of wish GitHub issues separated things that way, too.
Another disappointing limitation is being restricted to Node.js. AWS Lambda lets you write your code in Node.js, Python, Java, or C#. This is particularly useful for tuning your Lambdas based on their expected usage. If you have a Lambda that is being constantly invoked, it might be better to write it in Java. It has a longer start up time but has better performance after the initial startup. However, if your Lambda is invoked infrequently (and thus is frequently shutdown from inactivity), it would better to write it in Node.js or Python to take advantage of the snappier start up time.
Additional languages will come, but we're starting with Node.js. We'd rather take the approach of doing one language really well than a bunch of languages with a poor developer experience.
Image magick's binaries are already installed on the image. Any native binary node module that has a preinstall script should work too. If you hit an unsupported syscall error, contact firebase support at firebase.google.com/contact/troubleshooting and we'll triage.
For the record, you can also write Lambda programs in C, Haskell, Rust, Ocaml, Go, or basically whatever compiled language you want, as long as you can manage to produce a binary whose dynamically linked library paths are compatible with Amazon Linux, which is quite easily done either by building on EC2 or using a Docker image with the Amazon Linux file system --- or building static binaries.
Well...there's ways to call into Go, Rust and C++ from Node with very little performance penalty. Rust and C++ can even build native Node modules with no need to even write a single line of glue code in JavaScript. If you need performance, Node gives you quite a few options.
Lambda's billed in 100 millisecond increments. EC2 servers are billed in one hour increments. If you need short tasks that run in bursty workloads, Lambda's (potentially) a no-brainer.
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 big strides towards this vision in the past, we always had one big hole: trusted code execution. Today, we’re completing the story with Cloud Functions for Firebase so that you can easily run server-side code in response to events from your Firebase app.
We think you’re going to love it, and we can’t wait to see what you build with it!
Brendan, this is exciting news for lots of people! I'm developing a product on Firebase now and trusted code execution has always been my biggest concern.
Sure, it could be mitigated, but all the workarounds added unnecessary overhead and breaking points.
Want to thank you and your team for working on this. Firebase is a great product and this will make it just fantastic.
One thing if I have your ear - I'd love to give Firebase team some money by purchasing paid support - ideally as a part of the new Google Cloud support options announced yesterday. I hope this is on your roadmap as well :-)
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.
Cloud Functions for Firebase tech lead here. We'll get there in the future. We're looking forward to getting more feedback from users & prioritizing what is next.
No. All events are asynchronous. This use case is best simulated by having clients post to a queue. Cloud functions then either discards or applies writes in that queue.
You should add this technique to the docs! It makes you realize that the Cloud Functions feature is a lot more powerful than you might initially think.
Thanks to the mods for un-duping this and linking to the blog post, which went live like 7 minutes after I hit submit, haha.
Anyways, this was the last piece of the Firebase puzzle for me. Between this, Authentication, Analytics, the DB (obviously) and Storage, Firebase has been indispensable in getting my side project app up and running -- and most importantly, feeling "real."
My only request at this point would be a bit more TLC given to how Firebase integrates with React Native. I'm sure it's coming as it's likely a "still-small-but-growing" subset of use cases. As an example, there's not an obvious way to say, get Twitter auth working in a React Native app (last I checked a few weeks ago.) There are workarounds, of course.
PS- The Firebase console and docs are some of the most slick and well-designed examples of what they do I've seen. I really enjoy the web console and the CLI tool. Just a real joy to use, and I'm not being sarcastic. :)
+1 For React native support! In fact emailed tech support about just yesterday. Got a really quick response in which they essentially said -- "....We're exploring potential solutions, but I can't share any details or timelines at this time."
That's awesome! I might do the same thing in a bit. It's neat we can use the Web SDK with RN (in a limited capacity), but an official (or even semi-official) library would be the best.
The extremely poor JOIN functionality is what turned me away from Firebase a couple of years ago.
I come from 25+ years of SQL, and Firebase was my choice for essentially my first 'real world' NoSQL project. I was enjoying it right up to the bit where I had to extract data from 2, and 3 data tables at the same time in a single query. Couldn't believe how verbose and painful it was and it made me drop NoSQL for a while before more recently going back to it (with RethinkDB).
A lot of the join functionality can now be simulated by using functions to effectively create views or map reduce data to distilled output. We've got a lot more to come on this front. Functions was just first on the list.
As a 2+ year user of Firebase, this is long overdue. I built my own cloud function infrastructure using their Java SDK and Digital Ocean and I couldn't have built my app (ProBooks.com) without it. It's good to see Cloud Functions moving from Alpha to Beta!
I don't understand all the firebase and parse clones. They are not significantly better than firebase and they all entail vendor lock-in. The only real alternative is couchdb which unfortunately lacks document level read permissions (and filtered replication wastes storage) and still requires you to have an additional minimal server for the signup and passwort reset process.
One feature of my app is the PDF creation of invoices and estimates. I use a Java library to make these PDFs. Developing an iOS, web, and Android app that syncs in real-time is much easier (or even possible) when your PDFs are made on the backend.
Part of the primary power of cloud functions is you can extend firebase services instead of intermediating them. This lets you still take advantage of all the great features in the firebase SDKs.
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!).
Quite exciting. I just recently used Firebase for the first time in years and I was absolutely amazed at the level of productivity. The best part is how seamless and brain-dead everything is compared to AWS. Also the client side JS library for database storage makes handling application state a dream. Auth and static hosting require almost no configuration, and the only thing I couldn't use firebase for was server side compute based tasks.
This is the final missing piece will allow me to develop an entire app on the google cloud with no more server admin. Can't wait.
Oh man. This is great. Firebase is now a one-stop shop for the majority of app infrastructure needs, and really is the closest thing to a "serverless" infrastructure. Vendor lock-in aside, I can't think of a reason not to use it, at the MVP level at least.
Firebase offers a lot, but it's no longer the only game in town that offers a sorta-serverless baas. Here are some compelling alternatives (I'd love to see a complete list of the best Firebase alternatives):
I'm in the process of migrating a few GAE services to AppScale on AWS (Beijing) to set up a separate backend for the China-localized version of a mobile app. AppScale supports a lot of App Engine functionality, but not other Google services. No Firebase or GCM for me.
I don't really understand how to use this to build a real backend. Everything seem to be revolving around reactions (new thing happening in the DB, file uploaded etc) but isn't the more common use case that you actually want to call the function directly?
I'm building a simple React Native/Expo app where I want users to join random chat rooms so I obviously need some logic to delegate this process. Is Firebase/Cloud Functions something I can consider?
My first thought was "oh, maybe I can let my app call the function directly to add the user to a random chat room" but I don't see how that is possible.
When it hits YouTube, check out our talk "Cloud Functions and Firebase". We have a much more complex chat room example than has been possible in the past
2 - The timeout is configurable in the Google Cloud console with a maximum timeout of 9m
3 - The official tooling is what the "for Firebase" part is all about. We've designed an SDK for Firebase users and integrated it tightly with our CLI. We'll be giving an overview of these features at https://cloudnext.withgoogle.com/schedule#target=google-clou...
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.
To clear things up: You Can use the Blaze plan which is pay-as-you-go and starts at 0$ and has a large free tier. External requests are disabled on projects that do not have billing enabled but you can have billing enabled and still be within the free tier of usage. The Flame plan is the "fixed cost" plan starting at 25$ and also includes external requests.
Oh, so if my app is currently under all the Free tier quotas for DB/Hosting/Storage/transfer, I could sign up for Blaze and my cost would be $0? I didn't realize that, the pricing page doesn't seem to make that clear to me.
Edit: Actually, if I'm exploring this price calculator right, it appears that there is no free tier for DB if you are on Blaze, only a free tier for Functions. Which suggests I should leave my Free tier plan as is, set up a second project that only has Functions that make external calls in it, sign that up for Blaze, and call those functions from my free tier functions... Convoluted, but hey, it'd be free.
As mentioned in some other comments, the restriction on outbound requests without a billing account is to prevent abuse. I'm sure you could imagine some bad behavior if Cloud Functions allowed anyone to spin up a few million executions per month and hit any arbitrary web services.
Based on https://cloud.google.com/functions/pricing it seems like you can't pick and choose ram and CPU speed, so I'm not sure what the reason is to split the pricing between the two. I was quite interested in this because I've just found myself having to provision ~4x the amount of ram I actually need on lambda because I need more compute power.
Edit - It's interesting to see another player in the field though, so I'll be watching how things go.
On the Google Cloud Console you can change the memory allocation of your Cloud Functions: https://console.cloud.google.com/functions/list?project=_ we'll be providing better integrations with Firebase tools and also looking into providing more options in the future.
It looks like that is tied to the processing power, is that right? I can't see a way of picking them independently in that section, unless I'm missing something.
I'm surprised by the progress and uptake of the node vm lib; it's really found a ton of cool business models. From powering the Screeps game world, enabling smart message routing for PubNub BLOCKS, to stuff like this. I'm excited to see more advances with time.
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.
I have been waiting for this feature for a long time. This was the final missing piece for building an entire software product entirely on Firebase. Right now, I'm running servers on Google Cloud that use firebase-queue to handle server-side requests like payments and restricted actions. Google Cloud Functions would have been overkill because it would involve setting up a whole new workflow for the team. This is perfect because it is integrated to the CLI and easy for anyone to use.
All they need to work out now is educating their customers on the benefits of using Firebase over building a backend from scratch, especially in the trade-off between developer productivity and not owning your data.
We've been using this product in production for about 6 months now and it's been great once we've figured out best implementations (for us) like database structures.
Finally! This was the feature that made me go with parse.com when I started making backend-less apps. For Firebase apps I have to spin-up tiny node.js bots to capture events and do some cloud code magic.
Built our app, Wander, an IRC-like chat app, 100% with Firebase. We've been using Firebase Queue to get server scripting abilities. Can't wait to migrate to using Cloud Functions instead, just waiting for the (awesome) team at Firebase to iron out any teething beta-related issues.
If only Realm made their server-side scripting available for free (or much less than the $1.5k/mo they're asking for Enterprise). That would give Firebase a run for their money.
This is just great, the two things missing from Firebase that we kept hacking around were its very limited database querying abilities, and simple hooks around database events. Now one is part of Firebase and the other is more easily hackable than before, closing that little gap would make this the ultimate platform tool.
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.
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.
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.
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.
Look, I'm going to be honest - this is exciting, and Firebase is one of the best. But Google pushing this feature spells even more vendor-lock-in doom.
My disclosure is obvious, I'm an Open Source competitor, switch to us ( https://github.com/amark/gun ) and get "cloud functions" for free which can deploy to any services ( Docker enabled, Heroku 1 click install, run on GCS, AWS, etc.).
And don't worry, we just load tested the system doing a sustained almost 2K throughput messages/second across a distributed system on low end hardware. We plan on getting this up to 10K inserts/second on a free Heroku box.
Cloud Functions for Firebase is not a dupe of Cloud Functions. It is an extended offering with additional features. It's also prob of more interest to HN users.
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...