Firebase Costs Increased by 7,000%!
HomeAutomation
2.3K59

Umm… $2,000 a month isn’t a particularly high bill at all. Expecting to pay $25 a month for a service that is core to your business with thousands of users in every country in the world is not sustainable. You should have been expecting an increase at some point!

From what I’ve seen the suggestions have been move to AWS Lambda or an Open Source option. Both of which require a refactor of your code.

Option A — AWS Lambda. In Lambda itself there is no real lock-in. With the Serverless Framework you can easily deploy to AWS Lambda, Azure Functions, IBM OpenWhisk and Google Cloud Functions with very little code changes. The lock in with these Functions as a Service platforms is the services around it. So if you used AWS Lambda + DynamoDB your lock in would be with DynamoDB and all the data held in there. Going with Lambda or an equivalent would be cheaper than what you’re paying now due to the lower bandwidth costs and the generous free tier of these services. iRobot, for example, run their entire platform on AWS Lambda. Go read some of Ben Kehoe from iRobot posts and watch his many talks on the subject.

Option B — Open Source option. This would most definitely be your most expensive option. Once you go with an open source piece of software you would need to start managing a server estate to run the software. Now you have the complexity of managing an OS, managing capacity and scaling. You’ll start paying for idle time when those servers aren’t busy. This is beyond potentially having to hire someone to look after your servers. When there is a problem with the software where are you getting support from? Open Source is great, but it’s not free. Being vendor agnostic is always more expensive, and you still end up being locked into something (in this case whatever open source software you choose).

Option C — Refactor your code to be more efficient. The quick win is start using TLS Session Tickets and setting Keep Alive to true to reduce the traffic from SSL headers. Beyond that have you looked at using the WebSockets interface of Firebase? Why are you still using the REST API? With WebSockets you’ll get push notifications sent to the client so they won’t have to poll the REST API every 2 minutes. You should see huge changes from this, though it’s probably not a trivial change.

With any of these options you’ll need to refactor your code. I am concerned that you don’t seem to be able to update your apps easily if you’re worried about removing the hard coded address to Firebase in your app? Regardless of what you do on the back-end, you need to be able to update your client applications easily.

While I feel for you, and Firebase has been a bit shitty in supporting you. Paying $2,000 for a backend service supporting an app used by thousands of users in every country in the world isn’t huge, and by your own admission it could be less with Firebase themselves if you implemented TLS Session Ticket and set SSL Keep Alive. Regardless of the service you move to, you’ll need to make the SSL changes, as any service will charge you for all the bandwidth you use, whether the data gets to your backend or not.

You should be focusing on fixing SSL keep alive’s, removing the hard coded Firebase domain name and improve the ease of updating your deployed client applications.

Up till now Firebase has essentially been subsidising your business by keeping you on a lower plan. They screwed up by not moving you earlier, yes they been shitty in getting back to you and their support leaves a lot to be desired (I’m a former customer), but this problem you’re in is on you. Own it, and fix it. You’re never going to get $25 a month again on any service you choose.

Like what you read? Give Ant Stanley a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.