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

A startup’s Firebase bill suddenly increased from $25 to $1750 per month

medium.com

Post reply on HN
Print view View original

151–160 of 516 posts

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#151

Post by kbart »

moduspol wrote: post #101
kbart wrote: post #52

That's the same, old vendor lock-in approach. It has happened with the servers, databases, network equipment etc. now it happens with cloud -- nothing unexpected, prepare to see more of these when cloud market stabilizes and clear leaders emerge. That's why I always prefer open solutions, that can be moved/migrated/replaced easily and advise others to do the same.

Eh, it looks like the service provider hadn't taken into account an oddball use case in the pricing / metering, and then suddenly did. They certainly should have communicated that better and their tools / charts should have a way of showing the billable data, but it's a bit of a stretch to call it vendor lock-in. It's not like everyone on Firebase is complaining and the author admits they made major mistakes.

I'm not implying that this was made on purpose -- vendor lock-in might happen "naturally" as well, when company becomes big enough that they can start unilaterally change prices/conditions/services knowing that costumers will accept that (even grudgingly), because they have nowhere else to go or it is too expensive/complex. Google is the perfect example of this strategy. Smaller player or startup would probably go bankrupt very fast if acted with such disregard for their costumers.

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#152

Post by kelvin0 »

flipp3r wrote: post #14

Reminds me of getting Bait-and-Switch'd by Google App Engine in 2011. From 10's of euros to 1000's. > They have no phone number to contact, no way to dispute this other than email — which they have ignored us for over a month now without replying to our continued requests. Trapped. Doomed. We have no further options. Sounds like Google did a great job with Firebase. Definitely gives you that Google-feel of unresponsi…

Well of course they would charge that much: their customer support is stellar but it comes at a cost ... Errrrrrr ;)

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#153

Post by mwexler »

snomad wrote: post #140
flipp3r wrote: post #14

Reminds me of getting Bait-and-Switch'd by Google App Engine in 2011. From 10's of euros to 1000's. > They have no phone number to contact, no way to dispute this other than email — which they have ignored us for over a month now without replying to our continued requests. Trapped. Doomed. We have no further options. Sounds like Google did a great job with Firebase. Definitely gives you that Google-feel of unresponsi…

> They have no phone number to contact, no way to dispute this other than email — which they have ignored us for over a month now without replying to our continued requests. Trapped. Doomed. We have no further options. I don't understand why the larger internet/tech community keeps giving Google a pass on this. Anything where money comes in or out should ultimately have a support line where ultimately a human custome…

Is it because so many of Google's customers would then feel obligated to also offer support or service? While it's easy to pike at Google as a huge company which should provide this level of service, where do you draw the line? As I look across the collection of services I pay for, I don't see many of them with much more than "contact us" forms on sites, and in-app, no way to contact them at all.

Is there a certain size of vendor or price point where we expect to have human support and an SLA for response?

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#154

Post by petemcc »

_asummers wrote: post #136
corford wrote: post #126

Earlier quoted context omitted.

To be honest, the best way is setting up a completely isolated account with card. If you're extra paranoid, use a different bank for this account.

To be honest, this all sounds like it should be a primary bank feature. I should be able to cap a recurring payment at $X for a specific vendor otherwise have it go through automatically.

https://news.ycombinator.com/item?id=14256300

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#155

Post by victorhooi »

Yizahi wrote: post #31

Google is famous for not having any humans in support. One robot will write abuse on you and another robot will happily oblige and ban you with no appellation possible. Building whole business on one of such platforms takes some "courage" :) .

What you said is quite untrue.

I know - because I am one of those humans in support grins. I work in the support organisation for GSuite (formerly Google Apps). And I work across the hall from the guys who support GCP (Google Cloud Platform). And there are an entire army of us, helping support many, many enterprise customers.

Even our consumer products have real people manning support phones - I know, because I've had to call them before (mostly Google Play Music issues - this was before I joined Google, so I couldn't use my internal pull...lol).

Regarding your second point - abuse is a real problem for any cloud provider. I know, because I happen to work in anti-abuse. It's a difficult problem to crack, and there's a lot of smart people (at many companies) trying to solve it. But please understand there are real humans at the other end, trying to provide a good service - and it's not very kind to take cheap shots at them.

There usually are appeal processes available for nearly any kind of action taken - if you were actually personally affected by an issue, or feel unsure about how something was handled - please feel free to reach out to me. I can't guarantee I can wave a magic wand and fix it, but I'm certainly willing to reach out to see what can be done.

Disclaimer: I work for Google, but the views expressed here are purely my own.

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#156

Post by mSparks43 »

i really really hope all you lot complaining you got burned are the same people who downvoted my previous account out of existence when i said you would get burned 12 months ago or so.

Sadly I reckon it was more likely the people who burned you who were doing the down voting.

meanwhile, the servers i bought have now more than paid for themselves many times over and our operating costs have fallen to nearly zero.

Feeling vindicated.

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#157

Post by logicallee »

pbhjpbhj wrote: post #141
apatters wrote: post #24

Wowow! In this position my first step would be to determine if there's any legal basis for disputing the charge (an informal conversation with a lawyer or even just someone who's been through a similar experience is a fine start). Even when a billing change is disclosed in advance and the customer actually uses the bandwidth, massive spikes in metered pricing are a tricky area and have attracted the attention of regu…

"Don't be evil." was dropped in 2015 or thereabouts IIRC. I'd guess when they realised it was becoming more of a joke than a motto: "Google, the company who's motto is 'don't be evil' angered customers again today when ...

Can you link to a report or some source, stating they dropped the "don't be evil"? where do you get that, and the date, please?

Thanks.

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#158

Post by i336_ »

mstade wrote: post #144
_asummers wrote: post #136

Earlier quoted context omitted.

To be honest, this all sounds like it should be a primary bank feature. I should be able to cap a recurring payment at $X for a specific vendor otherwise have it go through automatically.

That South African hackable (in the good sense of the word) bank that's been making the rounds on HN might be able to do this. (I forget the name of the bank.)

https://root.co.za/

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#159

Post by mark_l_watson »

mstade wrote: post #46
mosselman wrote: post #36

Earlier quoted context omitted.

"you retain a running instance of every previous instance I pushed?!" What? Seriously? Is this documented anywhere? Would you recommend against using GAE?

> Would you recommend against using GAE? I've been burned so hard by them, I'd recommend against using anything Google.

I use GCP for "small stuff" and never have any issues at all: using GAE with the maximum number of instances set to 1 on a paid plan, using cloud storage to host static web sites, and occasionally spin up a really large VPS (their maximum memory and CPU core offering) for a short time periods to run machine learning and other large tasks.

So, for some applications, GCP works very well.

Re: A startup’s Firebase bill suddenly increased from $25 to $1750 per month

#160

Post by mgkimsal »

logicallee wrote: post #149
mgkimsal wrote: post #84

Earlier quoted context omitted.

> It really is appalling Never quite understood what's "appalling" about it. They've never had strong support for any dev/cloud-oriented services. I know some folks who've had good experiences , but those were exceptions, not the rule. I'll say, I get the frustration with it, but it's why I've never considered using their cloud services for anything. I had a client who asked me to migrate all their stuff to google 'c…

is there a typo here? 18ms seems like soemthing that could be designed into their whole infrastructure for some reason you don't know about (such as partitioning of networks, whatever) -- after all, it's a cloud solution, right? Maybe 18 ms tacked onto every request is fine for them. To be honest, if all of my Internet requests were 18 ms slower I wouldn't even notice. if I read you correctly and it wasn't a typo, co…

Because we had a shitty codebase that made 350 SQL calls on one page (the user dashboard), so the primary page that everyone used went from 8 seconds, and the end client who had to test and accept this change didn't like it. It became unusable.

To (re?)clarify - this was 18ms per query to the SQL cloud (from a google compute engine).

Yes, were there things that could be done to reduce that? Of course. The other guy on the project put some caching in, reduced duplicate DB calls, etc, and got it down to around 3-4 seconds, but without severely diving in and learning far more about this inherited codebase, there wasn't much that could be done to make it much faster.

The other steps involved heavier caching, which changed the actual functionality of the service that was contracted before. "real time status updates" had a functional definition of being within X seconds, IIRC. Caching everything so 'new' information wasn't necessarily available to an end user for, say, 3 minutes, wasn't an option, without getting a lot of buy-in from a lot of people. Not saying it wouldn't work technically, but the client relationship was already strained.

The move to google was primarily to 'save money' (because someone had $10k service credit with google), but the effort to make it work well on google cloud and SQL combo (wasn't my call) was too much.

You can say this isn't google's fault entirely - you'd probably have a strong case - but not everyone is moving pristine clean/strong/good code over, and problems with the original base were amplified by seemingly small issues.

Post reply on HN