Live data from Hacker News

Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

blog.tomilkieway.com

371–380 of 397 posts

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#371

Earlier quoted context omitted.

The downside of disabling active resources is huge. It would mean a catastrophic interruption to the customers application exactly when its the most popular/active. And theres no practical way to determine whether the customer is “trying it out” or running a key part of their business on any particular resource. On the other hand retroactively forgiving the cost of unexpected/unintentional usage doesnt impact the cus…

This. App Engine used to offer hard spending limits, and they were removed with precisely because so many users set them up to shoot themselves in the foot at precisely the worst possible moment.

^^ this. Hard spending limits seem great until your app/service gets super popular and you have to explain to the CEO why you were down during the exact window you needed to be serving the demand.

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#372
post #269

As an ex-Googler working in a customer facing role in Cloud you did very well to get a $72k bill written off! It's definitely possible but requires a lot of approvals and pulling in a few favours. I went through the process to write off a ~$50k bill for one of my customers and it required action every day for 3 months of my life. Whoever helped you inside Google will have gone to a LOT of trouble, opened a bunch of t…

OP here. Thanks for sharing! I have no idea what they did internally, but something like this was my guess. I only communicated through customer support channel and replied to emails, and shared my doc (which cited all the loopholes) with them. It took them 10-15 days to get back and make a one-time good will contribution. The contribution didn't cover logging cost, so we did pay few hundred dollars.

Sounds like you found an amazing support rep and made a great case for it - good job!

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#373

Earlier quoted context omitted.

This is a solved problem for every other service out there. You don't just delete the data, you give the customer a few days, weeks, or a month to pay their bill and if they don't, then you delete their data.

The problem with this though is it opens a vector for exploitation: users could just use the grace period to store data for free for a period of time. This can quickly become a heavy financial burden if enough people do it. You could factor that into the price, but then you're potentially making the price point even more unattractive to users than it already is, and users that are responsible with their budgets would…

I've accidentally let my OVH subscription go unpaid, and they gave a 7 day window to pay my invoice or delete my data. That's seems pretty fair to me, and they seem to have wide enough margins to eat the cost and still offer some of the cheapest prices out there right now.

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#374
post #238

Earlier quoted context omitted.

Well, the real question for all cloud providers, for which I expect crickets as an answer, is: Why don't cloud providers allow setting a budget which cannot be exceeded? A simple, 1-click way to say: this account should never go over $500 a month. Just stop creating resources or responding to requests if it does.

This is a outage waiting to happen for every customer: - Early dev sets a limit. - Product launches. - Slowly grows. - One day suddenly the entire business grinds to a halt. Globally. Across the carefully isolated shards. Everyone scrambles to figure out why! Tens of thousands of dollars are lost because of going $10 over a budget. End-users are lost. Trust is burned. If it's providing a critical system, maybe even p…

So ?

This is would be one more checklist that you need to regularly review, just like domain name registration and certificates, ...

Any of those expiring will cause outage also.

Outages happen. Will happen. This just one more way that they can happen. It happens you learn and move on.

Hell even the biggest providers with the beset admin teams on the planets have outages.

And Google doesn't need to explain anything just like your name register doesn't have to explain anything if you cc was declined/not current ...

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#375

Earlier quoted context omitted.

You've explained why it's hard for Google to not give me resources I can't pay for, but that's not what I care about, or what I'm asking for. What I'm asking for is a feature where I set a hard limit of $100 and that's the most I get billed - if my account accidently uses $5000 of resources before Google reconciles the usage with my budget then Google automatically waives the additional $4900 and then limits my accou…

So...you're saying that Google should give away $4900 of usage? How will Google automatically differentiate between an "honest mistake" and someone taking advantage of this feature?

So...you're saying that Google should give away $4900 of usage?

Yes. But they should also develop mechanisms to warn users that they've made a mistake before it happens, and improve the speed they can detect mistakes to lower the cost, and invent some way to detect someone intentionally abusing the feature.

But mostly they should make the fact they do give away $4900 when a mistake happens explicit. That isn't actually a change. They just need to make it clear that's what happens.

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#376

Earlier quoted context omitted.

And this comment makes you look incredibly naive and narrow minded. Running some code on a CPU != running a startup. Great you can buy a Dell server on eBay, or you can build a powerful desktop, or rent a VM or get a droplet or scrape on lowendbox. These are not a secret and there is a great reason no one does this other than hobbyists and neckbeards. You do your testing and it works, then what? You have to deliver s…

Really, "a million other supporting services and all the systems that come with it" ? You get a server with SSH, then you need something expose your container stacks over HTTPS like Traefik (which auto configures), and something for alerting such as Netdata (which auto configures too!), both of which are just a single binary to configure and setup, and probably it won't take long before you have scripts to automate t…

I'm a huge fan of open source and open standards, in fact I always push for and expect portability and avoid proprietary systems where possible. Abstractions like Kubernetes are a fantastic middle ground to provide portability across platforms whilst taking advantage of cloud provider services where they exist. The same for apps and frameworks built on open standards like Kubeflow and Apache Beam.

The supporting services and systems come when you run services that require strong guarantees for reliability and resiliency, and meeting the needs of different lines of business.

If I think of a mid-size company that wants to run these kind of workloads and demands minimal downtime, resilience against local disaster and minimal data loss: - Customer facing applications in a reasonable scalable manner to meet peaks and troughs of demand without needing to size of peak demand

- CRM/ERP systems to manage customer data, payments, sales processes and inventory that CANNOT have corrupted or lost data

- Data platforms for running reasonable scale analytics and analysis on reasonable size volumes of data (say a few Petabytes online accessible, analyse 10s of Terabytes per quer)

- Capability for mid-level machine learning and access to modern acceleration hardware, up to date GPUs and maybe some NVIDIA Ampere type equipment

- Tools and platforms for operations and security that can capture, store and analyse all the logs produced by all those systems, plus some half decent cyber services - network level netflow analysis, maybe IDS if you are feeling fancy, endpoint scanning and analysis, threat intelligence capabilities to correlate against all of that data

- Tooling and platforms for developers - source control, artifact repositories, container registries, CI platforms like Jenkins ideally with automated security scanning integrated, CD for deployments like Spinnaker to canary and deploy your releases safely

- Networking for all of that equipment, ideally private backbones, leased Ethernet or MPLS - and that all needs to be resilience, redundant and duplicated

- Storage for all of the above that meets performance and cost needs, replicated, and backed up offline

Yes, you can do all of that yourself! But let's be clear, buying a server on eBay is not even a fraction of 1% of the reality of running real infrastructure for real systems for real businesses. There ARE reasons why you might do this but that is increasingly the exception due to either extreme scale, regulatory and privacy requirements typically from data sovereignty or very unique hardware requirements.

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#377
post #205

Earlier quoted context omitted.

If I'm the only developer on a project and I really need to get to market I might do just that. I sometimes do day hikes on weeknights so this is actually a likely scenario for me.

Do you go hiking alone without your phone? That seems dangerous. And why would you start a test if you won't be there to see the results of the test? Seems more sensible to either leave after you've run the test or wait to do so until you get back.

If a test is going to take more than an hour then I'm not going to sit around after work waiting for it to finish.

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#378
post #301

Earlier quoted context omitted.

If I were in this situation I would probably offer 10% of the bill to the employee as a reward for their help.

That's too low. I usually tip my customer service reps 25% of whatever they save me.

So zero.

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#379
post #229

(Cloud Run PM here) I am sorry for the experience described in the blog post, we could definitely be better at bill management. I am glad that it worked out in the end and the customer was not required to pay for the bill. Based on this experience, we decided to lower the default value of "max instances" to 100 for future deployments. We believe 100 is a better trade off between allowing customers to scale out and pr…

Why don't you just allow customers to set a limit if they would like to?

Re: Burnt $72k testing Firebase and Cloud Run and almost went bankrupt

#380
For anyone who wonders, the summary of the mistake: created a web crawler without any stop condition and without adding any checks for not visiting the same page twice. The crawler just kept running for a day, making around 9 million requests per minute.
Post reply on HN