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

Reliability: It’s not great

community.fly.io

Post reply on HN
Print view View original

471–476 of 476 posts

Re: Reliability: It’s not great

#471

Post by mike_d »

LunaSea wrote: post #470
mike_d wrote: post #469

Earlier quoted context omitted.

> Of course you can, you simply reach for assets within the border of said member country or the EU. Which is exactly what I said. If the US company has an EU subsidiary you sue in that venue that can grant you relief. There are US tax implications of holding foreign assets, so the 1% of US companies with overseas interests create a foreign subsidiary, the other 99% have absolutely nothing within the reach of the EU.…

Let me make it simpler for you. If say Google were to not follow the GDPR for example, even if they didn't have any European subsidiaries, the EU or a member country would simply make all Google customers pay their subscription fees to them instead of Google as fine payment for the fine. Customers would see no service disruption.

In your example Google would not receive the funds and credit the customers account. How would they differentiate an EU government stealing the money from a customer who just didn't pay and say they did?

Feel free to call up your credit card or power company and ask them what happens if you send them a payment but it gets seized by the government along the way. Their answer will be that you still owe them money.

In your example the EU customers would be out the money, not Google. With no EU nexus (in your hypothetical) they cannot compel Google to provide services they were not paid for.

Re: Reliability: It’s not great

#472

Post by Timon3 »

alex_sf wrote: post #441
Timon3 wrote: post #402

Earlier quoted context omitted.

Why exactly is it seemingly so expensive not to sell your customer data?

That's not the issue. I don't want to see personal data sold either. It's all the little rules. There are hundreds of pages just in GDPR. You need a banner and explicit opt-in just to support login/logout functionality.

Can you explain why you believe this to be the case? Let's say you log the user in. Yes, you need consent to store a login cookie, but that doesn't mean you need "a banner and explicit opt-in". You only need explicit opt-in, which you can do by... putting a "remember me" box next to your login form[1]. Is that really so hard?

[1] https://law.stackexchange.com/a/32157

Re: Reliability: It’s not great

#473

Post by LunaSea »

mike_d wrote: post #471
LunaSea wrote: post #470

Earlier quoted context omitted.

Let me make it simpler for you. If say Google were to not follow the GDPR for example, even if they didn't have any European subsidiaries, the EU or a member country would simply make all Google customers pay their subscription fees to them instead of Google as fine payment for the fine. Customers would see no service disruption.

In your example Google would not receive the funds and credit the customers account. How would they differentiate an EU government stealing the money from a customer who just didn't pay and say they did? Feel free to call up your credit card or power company and ask them what happens if you send them a payment but it gets seized by the government along the way. Their answer will be that you still owe them money. In y…

> How would they differentiate an EU government stealing the money from a customer who just didn't pay and say they did?

Because they would have been notified by a court beforehand and the fine would constitute an outstanding debt linked to a lost lawsuit.

Once that happens, the national collection agencies would take over and use the tools at their disposal, like collecting from customers directly, which is the equivalent of garnishing wages but for companies.

They would then receive regular updates about the remaining debt and what was already paid and by whom.

> Feel free to call up your credit card or power company and ask them what happens if you send them a payment but it gets seized by the government along the way. Their answer will be that you still owe them money.

If Google then refused service to the customers who's payments were redirected to that country's collection agencies, then additional punitive measure would be taken by the country.

Some of the punitive measure could be:

- growing interests on the outstanding debt

- blocking the service within the country or EU

- advertise that Google is delinquent and is refusing to pay it's debt to financial institutions

- prevent banks and financial institutions from loaning money or investing in Google

- configure an embargo for imports and exports towards Google

- extradition requests for C-suite or adding them to Interpol and Europol wanted people list

- etc.

> In your example the EU customers would be out the money, not Google. With no EU nexus (in your hypothetical) they cannot compel Google to provide services they were not paid for.

They can't force Google to provide services but Google will also lose that market (for the EU that's 450M people) and increasing punitive measures.

Also, Google refusing to pay would probably discourage financial institutions anywhere from servicing Google in the future and other countries from authorising Google on it's national market.

Re: Reliability: It’s not great

#474

Post by bostik »

chrisshroba wrote: post #280
bostik wrote: post #79

Earlier quoted context omitted.

There's a wonderfully blunt saying that applies here (too): you are not in the business you think you are, you are in the business your customers think you are. If you offer data volumes, the low water mark is how EBS behaves. If you offer a really simple way to spin up Postgres databases, you are implicitly promising a fully managed experience. And $deity forbid, if you want global CRUD with read-your-own-writes sem…

> if you want global CRUD with read-your-own-writes semantics, the yardstick people measure you against is Google's Spanner. I’m trying to build more of an intuition around distributed systems. I’ve read DDIA and worked professionally on some very large systems, but I’m wondering what resources are good for getting more on the pulse of what the latest best practices and cutting edge technologies are. Your comment sou…

The best practices are built on solid first principles, and you can get a pretty good grip on them from the High Scalability archives. Back when they posted actual tech articles, their content was some of the best available anywhere. Since you've read DDIA you will probably get quite a lot out of the archive. In fact, you should be able to identify at least some of the unstated problems.

Re: Reliability: It’s not great

#475

Post by otterley »

mixmastamyk wrote: post #466
otterley wrote: post #424

Earlier quoted context omitted.

While I largely agree with you, this isn’t one of those cases. If Fly wasn’t supposed to scale in due course to this size, it probably wouldn’t have been funded. If your business model is predicated on you scaling, yes, you should hire appropriately in anticipation of that. Besides, I’m not even necessarily talking about hiring here - even consulting would have been sufficient to avoid this catastrophe.

Yes, although it's rarely possible to know which bottlenecks will hurt the most up front. Unless you've done the same thing before, which is not the case with anyone pushing boundaries. Basically this is an argument around so-called premature optimization. Good to have issues now while it is mostly enthusiasts that are the customers. Guessing that this bump will be forgotten in five years? And not like AWS et al don'…

Consul has been around for close to 9 years now, and people have in fact tried to use Consul in the very same way Fly did, in many different business and industries, with similarly failing outcomes. Hashicorp knows this and almost certainly would have counseled against it if asked.

Re: Reliability: It’s not great

#476

Post by mixmastamyk »

otterley wrote: post #475
mixmastamyk wrote: post #466

Earlier quoted context omitted.

Yes, although it's rarely possible to know which bottlenecks will hurt the most up front. Unless you've done the same thing before, which is not the case with anyone pushing boundaries. Basically this is an argument around so-called premature optimization. Good to have issues now while it is mostly enthusiasts that are the customers. Guessing that this bump will be forgotten in five years? And not like AWS et al don'…

Consul has been around for close to 9 years now, and people have in fact tried to use Consul in the very same way Fly did, in many different business and industries, with similarly failing outcomes. Hashicorp knows this and almost certainly would have counseled against it if asked.

Insert Donald Rumsfeld quote about un/known un/knowns.
Post reply on HN