Firebase outages and misleading status reporting
1–10 of 52 posts
Re: Firebase outages and misleading status reporting
#2AppEngine had the same problems - seemingly every week some component of the service would be down for some non-negligible amount of time (laughably it was often search -- we're talking about Google here).
I've generally found AWS more reliable than GCP - even when GCP isn't having downtime, you'll occasionally get 503's from their APIs, so you need to wrap all your calls to them in retries.
AWS has had multiple instances of cascading EBS backplane failures, but outside of that I've found their core services pretty reliable -- 400+ days of uptime on a lot of VMs in systems I've worked on -- I avoid EBS when I can.
My advice is to keep your stuff simple - PaaS might seem attractive, but you have so little control as you mention when something goes down. Embrace multi-cloud by using the lowest common denominator of tech available - virtual machines, dns, networking, and instance storage if that suits your needs. Treat vms as disposable - and make sure you have system, service, and data redundancy at that level to survive the failure of an entire availability zone across your application.
Re: Firebase outages and misleading status reporting
#3AppEngine had the same problems - seemingly every week some component of the service would be down for some non-negligible amount of time (laughably it was often search -- we're talking about Google here). I've generally found AWS more reliable than GCP - even when GCP isn't having downtime, you'll occasionally get 503's from their APIs, so you need to wrap all your calls to them in retries. AWS has had multiple inst…
Pretty amazing how virtualization has come to the point that we even need to virtualize our reliance on cloud vendors across multiple vendors to ensure realiability
Re: Firebase outages and misleading status reporting
#4AppEngine had the same problems - seemingly every week some component of the service would be down for some non-negligible amount of time (laughably it was often search -- we're talking about Google here). I've generally found AWS more reliable than GCP - even when GCP isn't having downtime, you'll occasionally get 503's from their APIs, so you need to wrap all your calls to them in retries. AWS has had multiple inst…
Appreciate the thoughtful reply and summary of experiences with GCP vs AWS.
Re: Firebase outages and misleading status reporting
#5AppEngine had the same problems - seemingly every week some component of the service would be down for some non-negligible amount of time (laughably it was often search -- we're talking about Google here). I've generally found AWS more reliable than GCP - even when GCP isn't having downtime, you'll occasionally get 503's from their APIs, so you need to wrap all your calls to them in retries. AWS has had multiple inst…
Pretty amazing how virtualization has come to the point that we even need to virtualize our reliance on cloud vendors across multiple vendors to ensure realiability
I'll say, I've only really done multi-cloud for cases where I liked different products on different clouds -- the main app and data on AWS, but using Google's data stack (BigQuery >> Redshift imho).
In terms of reliability, I think the first step is multi-region -- being able to failover to another region should your primary region have major failage. But assuming you can do that, doing multi-cloud for the same thing shouldn't be so hard provided you have some sort of common open source runtime to run on both platforms.
Re: Firebase outages and misleading status reporting
#6Check out the AWS offerings (Amplify + AppSync) if you're rolling off Firebase:
https://aws-amplify.github.io
https://docs.aws.amazon.com/appsync/latest/devguide/welcome....
Re: Firebase outages and misleading status reporting
#7Serves you right for using a “real-time database” (whatever that is). I’m sure your chat product feature could have been designed using a flat file as a datastore and a simple web socket server.
Re: Firebase outages and misleading status reporting
#8Serves you right for using a “real-time database” (whatever that is). I’m sure your chat product feature could have been designed using a flat file as a datastore and a simple web socket server.
Please don't be a jerk on Hacker News. The idea here is: if you have a substantive point to make, make it thoughtfully; if you don't, please don't comment until you do.
Re: Firebase outages and misleading status reporting
#9Firebase is really awesome. However there kinds of reliability issues and the lack of integrity and communication with which Google handles such things are major reasons I would avoid committing to it. On top of that, Google's history of overlapping products (Firebase or Firestore?) and discontinuing or foot dragging support make decisions confusing and commitment harrowing.
Amazon on the other hand has a history of committing to clear product direction which makes committing to their platforms much easier. Amplify and AppSync for instance feel like safer choices.
Re: Firebase outages and misleading status reporting
#10Check out the AWS offerings (Amplify + AppSync) if you're rolling off Firebase: https://aws-amplify.github.io https://docs.aws.amazon.com/appsync/latest/devguide/welcome....
Amplify+AppSync client SDK support is pathetic compared with Firebase. No official support for Flutter, Xamarin and Unity apps.