Live data from Hacker News

Reliability: It’s not great

community.fly.io

411–420 of 476 posts

Re: Reliability: It’s not great

#411

Earlier quoted context omitted.

As an EEUU resident, we also don't care. We can survive without youtube and instagram and the whole surveillance industry. Some of the laws place a heavy burden on giant tech companies, but for good reason.

They place a burden on everyone. A burden that's going to create a two-tier internet where service is immediately refused to EU citizens by every provider except the giant tech companies that can afford to comply.

> giant tech companies that can afford to comply

Where does this sentiment come from? Cost of compliance for Facebook is many orders of magnitude higher than cost of compliance for a website for your hairdresser or a restaurant.

In my startup, GDPR was barely a blip on our radar. We had to delete website logs and that's about that. You have to keep record of customers/payment information for laws that supersede GDPR, and that's it if you run a legitimate business not reliant on stealing.

Re: Reliability: It’s not great

#412
post #409

Earlier quoted context omitted.

All of these will absolutely contain PII every time.

Nice bit of FUD you got there. You can use Google Search and be 100% compliant, because Google doesn't see any customer data. Google chrome isn't even a service, I can't imagine how you'd manage to stick customer data in there. And if you think there are no companies without AWS and Microsoft 360, you need to expand your horizon. I work for one such company, and so do many of my peers.

There are also lots of companies that use AWS etc. for everything but customer PII and keep that in some SAP system on-prem.

Re: Reliability: It’s not great

#413

Earlier quoted context omitted.

We are asking to HashiCorp products to do things they were not designed to do, in configurations that they don't expect to be deployed in. Take a step back, and the idea of a single global namespace bound up with Raft consistency for a fleet deployed in dozens of regions, providing near-real-time state propagation, is just not at all reasonable. Our state propagation needs are much closer to those of a routing protoc…

Well, why did you do that? If you’d asked them whether this was a supported configuration or intended purpose, they’d have said no; and anyone who had experience deploying Consul at large scale would have told you the same. There is truly no compression algorithm for experience.

This feels unnecessarily antagonistic. "If you were experienced, you would have made the right decision, _obviously_."

Did Fly.io kick your puppy or something?

Re: Reliability: It’s not great

#414
post #409

Earlier quoted context omitted.

All of these will absolutely contain PII every time.

Nice bit of FUD you got there. You can use Google Search and be 100% compliant, because Google doesn't see any customer data. Google chrome isn't even a service, I can't imagine how you'd manage to stick customer data in there. And if you think there are no companies without AWS and Microsoft 360, you need to expand your horizon. I work for one such company, and so do many of my peers.

Google Chrome through telemetry and account history synchronisation which log PII in URLs and searched.

Google Search will see PII go by if your marketing team is researching leads on LinkedIn for example.

> And if you think there are no companies without AWS and Microsoft 360, you need to expand your horizon. I work for one such company, and so do many of my peers.

And that's great.

What is the services stack your company is implementing?

What kind of alternatives do you use for your email, browser, centralised data storage, etc. ?

Re: Reliability: It’s not great

#415
post #5

I'm not a user of Fly.io. I can't help but notice how remarkable the effect of open communication on potential end users like me. I remember reading about their reliability problems on HN some time ago. That biased my view of the company. After reading this, the open communication and transparency restored my trust in them, and would make them again a potential candidate for future projects. Because now I know that t…

This is probably therapy, but your message and fly.io's post resonates a lot with what I'm going through. I took a product owner role about 6 months ago, my first, with a company that has turned out to be just a mired mess, and a product universally hated both internally and externally. Long story short, it's completely over-engineered by a bunch of intellectual engineers with no focus, no discipline, and no oversigh…

Could you further elaborate on “intellectual engineers”? What mistakes were made? Esoteric languages? Obfuscating design patterns?

Partially so I could learn from mistakes and partially since I’m a sucker for post-mortems :)

Re: Reliability: It’s not great

#417
post #16

Not a client of fly.io, but dang impressive for the company to be this open and honest. Definite respect - wish more companies were like this. It puts them on my short list almost immediately for future needs.

Why would you shortlist a company that admits to reliability issues?

All companies have reliability issues, especially in this problem space. I’d rather go with someone who acknowledges their failings in public.

Re: Reliability: It’s not great

#418

Earlier quoted context omitted.

As an EEUU resident, we also don't care. We can survive without youtube and instagram and the whole surveillance industry. Some of the laws place a heavy burden on giant tech companies, but for good reason.

They place a burden on everyone. A burden that's going to create a two-tier internet where service is immediately refused to EU citizens by every provider except the giant tech companies that can afford to comply.

Close, the giant tech companies may or may not comply but they surely can afford the fines that the various EU Data Protection authorities dream into reality by twisting an ever-changing body of interpretation of ambiguously written rules.

Re: Reliability: It’s not great

#419

Earlier quoted context omitted.

I suspect, in general, acceptability (or desire) for complexity in the cloud solution, and budget are positively correlated in customers.

The ridiculously overwhelming complexity is stickiness. Think it’s bad to potentially technically move your solution from $CLOUD vendor? Wait until you turn around and realize you have at least one full time hire who’s entire role is “$BIGCLOUD Certified Architect” (or whatever) and your entire dev staff was also at least partially selected for experience with the preferred cloud vendor. At any kind of scale you have…

This is really an oversimplification. MS and Oracle have licensing that's explicit in the way that it wants to lock you in, although in different ways. AWS and GCP posting public pricing that can apply all the way until you reach an absurd spend goes a long way, and the ability to turn off a workload tomorrow incentivizes these platforms to provide a high quality of service.

When working at AWS, a large part of the convincing for an MS shop would be around showing that we can offer a lower price than the 'discounting' that MS provides. Oracle was all about contract expiry.

While there's some complexity around migrating a workload, regardless of where it's at, many places are going into cloud migrations hoping to remain relatively platform agnostic. I've seen many successful migrations to and from different vendors, and often at an SMB or ME scale, in weeks not years.

Re: Reliability: It’s not great

#420

Earlier quoted context omitted.

Well, why did you do that? If you’d asked them whether this was a supported configuration or intended purpose, they’d have said no; and anyone who had experience deploying Consul at large scale would have told you the same. There is truly no compression algorithm for experience.

This feels unnecessarily antagonistic. "If you were experienced, you would have made the right decision, _obviously_." Did Fly.io kick your puppy or something?

I can see how it would be interpreted that way, and I apologize if it came across that way, but it wasn’t my intent. See my other comment below. What I’m really saying is that we need to be better about engaging subject matter experts early on when we are selecting technologies to power core business functions; and I think it’s a good illustration of why we need to continue to hire experienced people at startups.
Post reply on HN