I had no expectation of that money being waived, but Amazon did anyway.
Since then I've had billing alerts turned on at about the $150 mark (which is about double what my personal monthly Amazon bill is).
I have a startup plan where you can run 60 executions in a month free of cost. Just reach out to me via https://totalcloud.io/solutions.html and refer YComb.
A 6+ year wait for such a reasonable feature sucks.
It sounds like an intentional product decision and not a technical obstacle.
The issue is that they only apply to certain GAE services (compute, legacy APIs, etc.) and not across the platform.
Imo the reason is this is for business/enterprise use cases configuring this wrong could be catastrophic, for side project/personal use cases its pretty well known you get 1 chance for a refund from the public clouds, after some manual checking to make sure you aren't trying to abuse the service.
On (1), if you get to say the 14th of the month and run out of budget, what would be the expected behaviour? - shut down all your services? delete all your data so that's not incurring a charge too? It'd probably have to be configurable on a service by service basis, and that's an awful lot of complexity to introduce for a tiny minority of their revenue base.
On (2), their billing systems are almost certainly eventually consistent in logging and charging usage, so they'd either have to shut you down early in anticipation of delayed charges, or let any delayed charges bring you over budget. Either is liable to make customers fairly unhappy one way or the other.
The TL;DR version - it'd be nigh on impossible to have good UX with such a feature, would be complicated to implement, and it's not likely to move the needle on any metric they really care about considerably.
what about devs too scared to put their CC no in the till coz they've heard horror stories about being overcharged for mistakes? Just recently had to sort out a feature that a junior dev created using openstreetmaps coz they didn't want to be on the hook by putting their card into google maps... It was for an internal portal, usage wasn't even high enough to hit the monthly free tier!
Hour 1 experience also matters.
Perhaps I've misunderstood the situation, but if I were working as a dev at a company and was expected to provide my own card details to pay for APIs, I would walk out the door.
The dude bounced off google maps as soon as he saw the form to enter payment info and went straight to open street maps.
As he should. Unless you have in written form that the company will cover the exact expense, then no one should use a personal CC for work use.
from your comment history i see you're european.Europeans have way more protections and assurances in cases like this, india is a very different business environment...
Sounds like a happy ending.
You can't use most aws things in fedramp scope.
If my business had 100k in revenue per month. Normal cloud spend is 2k per month.. some glitch made spend go to 2k a day. That sucks, and I hope I have good alerts to catch it within a day or two.. but telling my customers "screw you, bill messed up" for however long it took me to sort out the bug? I would not do that.
What would you like Amazon to do for stateful services? Should they stop and delete EBS volumes? What about databases? Simply shut them down? What happens when you lose data or it doesn’t come back up?
For non-storage resources like EC2, network bandwidth, etc. I'd be fine with having a hard limit where everything just breaks, especially for stuff that's not production.
There could also be better, self managed quotas on resources. SES is a good example. AFAIK the quota is all or none across the entire account. IMO, it's not a good idea to give a user that needs to send (made up numbers) 1k emails per day credentials that can send 250k emails a day.
I have 3 AWS accounts. I don't keep anything in my main account. It's for billing only. I have a sub account for production that I try to keep pristine. I have a sub account for development and testing. It's the development account that scares me. I spend less than $50 per month. I'd rather have my whole development account de-allocated than get a bill for $1k.
For personal stuff I would much rather a kill switch than a nasty surprise. For _some_ businesses, that is probably the wrong decision though.
For example, in this case, if a regular database was used instead of Firebase, "counting the number of supporters" would have been done inside the database using a query. The worst that the developer could have done is forget to index to the relevant column; performance would have been sub-par but still orders of magnitude better than Firebase because the bulk of the data would not leave the database if there was a proper query language. With Firebase, when doing complex calculations, not only does the data have to leave the database, it often reaches end users; the calculations then happen on the front end and this is a huge problem in terms security, performance and even correctness (due to latency and the fact that other users may be making conflicting calculations simultaneously based on slightly outdated data).
Also, based on the article's description of the application, it sounds like it may have exposed potentially sensitive data (about supporters) to all users so it may have introduced a security vulnerability. I would not be surprised if this was the case.
Any time sensitive data reaches untrusted users it is a bad practice, but this needn't be the case on Firebase just because it is serverless.
Firebase cloud functions can be triggered as a response to document saves (or authentications, or a plethora of other things) and run outside userspace, and are available for exactly this sort of work -- keeping the minutiae of upkeep away from the client.
That said, I agree that it's easy to make this kind of mistake with serverless development, but mostly due to lack of existing domain knowledge. It's trivially easy to make similar (or worse) mistakes without a serverless environment by untrained developers, too. It's just a matter of becoming familiar with the toolset, and because serverless tech is newer, fewer are as familiar with them as they are the old things (and there are fewer people to catch those mistakes when they see them.)
I recommend the atomic increment operator for counts that both Parse and Firestore offer for this problem.
> For example, in this case, if a regular database was used instead of Firebase, "counting the number of supporters" would have been done inside the database using a query.
I don't think this is connected to serverless achitecture. You have to write a database query either way. And it would be just as easy to count or retrieve entities one by one with traditional approach.
Would you pay 30k$ for 2million people to look at and try your site? I would for any business I was running. If your servers were on fire at the start of that, would you pay 30k to keep your servers up?
I had a string of sketchy accounts using my SaaS service as a file host which ran up a bill of about 1.5k. Obviously I put some safeguards in place (firewall, rules, alerts), but the scenario you're mentioning does happen and is largely mitigated by using a service with a pricing model like Cloudflare's.
The other problem with your comment is that you try to make it sound like it was a single dimension decision to use the cloud. It is never a single dimension questions though.
In a few minutes, I can set simple PHP script with curl, that will launch 100 requests each second, using a pool of hundreds of thousands of IP's thank to the rotating VPN.
This is an edge case of course, but it can happen.
I use cloud myself, but only cloud servers, which allows me to control budget better and provides me with an "escape plan", where I can just switch to dedicated quickly.
I am not sure why people think that cloud is magically will shield them from every bad decision.
You won't get many surprises there.
I need to register with medium now to actually read the article?
Oh wow, one free story for logging in! Such generosity of content other people wrote for free. Why did we all leave LiveJournal again?
It never was.
It is ridiculous that I have to install an extension to make a website usable though. I'm genuinely curious why people publish on Medium.
I honestly haven't run into slowdowns - maybe on Youtube where its known that Google doesn't play nice with other browsers.
There's also the whole issue of not letting Google control the web but that's for a different time.
* Create quality service, prioritizing user experience over money
* Grow site to significant user base
* Start running out of money, because hosting and running a site does cost money
* Try to monetize service
* Get out-competed by another service still at step 1
The presence of VC money that's all about capturing market share now, and monetizing later does not help.
In the end, we have become accustomed to a world where things that cost money are given to us for free. When there are attempts to charge us so things remain sustainable, we get angry! It's a tough problem, and I don't know the solution.
I believe it's hard, but not impossible, to refrain from abusive monetization and stay afloat longer.
Users expect these services to be free, because they are used to services being sold under-cost. The alternatives for 'platforms' that I know of are:
1) accept 10% of paying customers and 90% leaving, bad plan if you rely on the mass of present users
2) go for a tiered system, where certain features are gated by a pay-wall. This is very tricky, and asking for essential features will see free competitors come up. This can work if your sheer user-base is enough of a moat. (Reddit is still trying to make this one work)
3) sell user-data
3 is definitely seen as 'user-abusing' 2 tends to be as-well and 1 is not an option for any platform.
I can't think of a single platform that started of as 'free' and got profitable without being widely condemned for 'selling out users' except for YouTube (and I guess PornHub). The moat there is massive infrastructure needed for video and a huge, hard-to-move catalogue of content.
That is, it is too expensive for some start-up to grow and capture the market.
I'd love to hear of any other success stories. Especially one that could work for a medium / reddit / flicker kind of site.
All these platforms rake in millions of VC money to get market share (that is fine btw) but if you do not know how to monetize it, what is the point? And of course always being free and then moving to a paid model doesn't make your users really happy.
I know I've seen at least 4 articles about 'OMG Surprise horrific billing" with them. And to be quite frank, you can buy a EC2 instance, throw Postgres on it, and have a stable bill (Except for bandwidth costs, but that's trivial... usually).
I'm sure Firebase has good features, but this surprise billing is terrifying. They can't even offer a warning "10 min average indicates a bill roughly XX,000$/mo". I could not suggest it in good faith for anything, especially since it doesn't have a hard cutoff.
And one of the reasons I prefer either running web things on my own server(s) as much as possible. And can't you set a charge limit on Firebase?
With cloud you really have to optimize your code/architecture as you pay for what you use.
With your own servers that is not an issue unless you overload them, then you can have an outage.
EDIT: I thought Firebase is amazon for some reason, it is not. So in general Google panel doesn't have that functionality (from my experience with it), they have billing alerts but I never saw anything that would shut off things on reaching that alert.
You can limit by API requests usually but not by credit amount so if you use multitude of API's it can get tricky and they likely didn't limit anything.
TL;DR: minimum 1 year deprecation policy, and you've got access to the data at any time (e.g. do a backup and get everything as JSON, or download an entire store bucket and transfer it to S3).
Also that's one of the reasons I try to use the realtime database, and not firestore. But they still charge for bandwidth there (most if it is consumed by downloading the SSL certificates from the clients).
See "Dog bites man" vs. "Man bites dog"
> The app was running, all the supporters were able to support and the comments on social networks were that the app made it really simple to do support. We were very proud :)
> We didn’t want to release any new feature with that many users on the site, so we decided to merge a version with Angular V.6 […]. The site started to load slower, for some users it took them more than 30 seconds to load the page. That was weird. Our team was not comfortable with that and we couldn’t understand what was causing it and now we had our code with a completly new version of Angular, and probably many other bugs in production.
Am I reading this right: Their site was running well. They didn’t want to interrupt it by adding new features (potential bugs) so they casually update the framework and push the new version of their website to production hastily? And instead of rolling back the release they double down and optimize their code without knowing the source of the slowdown. Like WTF? Apparently they hadn’t even opened the browser’s network console to check if/what requests cause the slowdown. How did these people get $25K grant money?
Looks like incompetence really, using a framework and unable to pinpoint the bottleneck and deciding that maybe upgrading version will somehow fix their bad code.
Not a completely pointless idea as framework might indeed have been changed enough to force them into using itself correctly, but still lot of questions.
Really should've just linked to that hackernoon post though IMO, contains a lot more details thats very helpful in understanding what actually happened.
db.collection(‘Payments’).where(‘id’, ‘==’, ‘payment 1’).onSnapshot(console.log) // 1 read, then cached
Whereas specifying a document and then manually get it always counts as a read. Example;
db.collection(‘Payments’).doc(‘payment 1’).get() // always counted as a read
I've had multiple discussions with people who build apps using Firebase and then not being able to scale to 1000 concurrent people without the BE falling apart. I want to tell them that they've done something wrong, but since none of my apps haven't reached those kind of usage levels, I really don't know.
I think Firebase comes with a lot of power, and as long as so plan to scale, design your database model, have proper security rules and cache as much as you can, you can probably host a 1M concurrent users without getting scaling problems. Cost though, ooh yeez. :)
Very interesting post especially as I am myself currently working on my first firebase based app and making sure I don't get huge bills is one of my worries.
Just little correction needed:
> July last year, a crowd funding campaign went viral in Columbia
It's Colombia not Columbia.
And millenial ~= trendy.
Perhaps you're the Junior developer?!