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

451–460 of 476 posts

Re: Reliability: It’s not great

#451

Post by IshKebab »

throwawaaarrgh wrote: post #407
capableweb wrote: post #360

Earlier quoted context omitted.

I'd say it depends more on the person rather than the technology. A master in bash will build more reliable API (in bash no less!) than a beginner in Rust, simply because of experience and knowing their way around the tools they're using. Newer/different technologies won't simply solve a problem unless the person has some sort of domain knowledge of said problem.

I agree. Like, you could build two houses: one out of sticks, the other brick. Depending on who's building it, if they've not built a house out of brick before, it's very easy to make a mistake. Versus someone who's been building stick houses forever will get it right the first time. Also, brand new software in general is like a new hybrid plant. How does it behave in this environment compared to other plants? Does i…

> Depending on who's building it, if they've not built a house out of brick before, it's very easy to make a mistake. Versus someone who's been building stick houses forever will get it right the first time.

Decent analogy. And of course if you have people of vaguely similar skill levels then the brick house is going to be way more robust. Which was my point.

Re: Reliability: It’s not great

#452

Post by bovermyer »

otterley wrote: post #420
bovermyer wrote: post #413

Earlier quoted context omitted.

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.

That's a fair point... but at the same time, we shouldn't hold off on starting something just because we don't have perfect information.

Re: Reliability: It’s not great

#453

Post by spoiler »

gizmo wrote: post #118
spoiler wrote: post #95

Earlier quoted context omitted.

I'm not sure why the cynicism around their candor. Do you think it's not genuine just because it was posted by a company employee? Your post implies corporate messaging is bad. And anything posted by a company—or at least I don't know where you draw the line—can be considered corporate messaging. Am I just reading too much into your phrasing?

It's strategic messaging. It can't be genuine, because of what it is. The benefit they get is publicity and damage control, and as you can tell by the many responses here, it buys them time because many developers are willing to give them the benefit of the doubt. Companies that engage in this kind of candor are careful not to disclose those things that would really hurt their business. Those things are still kept se…

I don't think this means that it can't be genuine. I mean, the intent was to buy some good will with their customers who have experienced problems, that's for sure. But it's not a "bad" motive I think.

If I had a bad day and didn't get to complete something within my estimate, I'll tell my boss I had a bad day and ask for more time. Does that mean I have ulterior some ulterior motives? No, I just had a shit day, and needed some compassion.

They have been going through a rough patch recently with their scalability problems. And they realised they might not address it as easily or as quickly as they'd like. So they just wanted to buy time. I think that's better than "bunkering" and not letting your customers know what's up.

They do have the benefit that their audience is tech savvy as they are, so they can go into more details (and be less formal, I suppose) to get some understanding from their customers. As in, most devs have struggled at some point with a problem that exceeded the initial scope/time estimate. It sucks, and we know it sucks. So, why not give them the benefit of the doubt here?

Like, I think understand what you mean: their goal was to buy more time, and they achieved that. But even though it was corporate messaging, I still think it was genuine. I assume they felt a bit like "ok shit, we gotta talk to our customers, they deserve to know what's going on".

I guess they wouldn't air most their internal issue, since those don't aren't felt by the customers. So there's no need to apologise and explain themselves.

Re: Reliability: It’s not great

#454

Post by lawik »

alex_sf wrote: post #440
tpxl wrote: post #411

Earlier quoted context omitted.

> 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,…

This simply isn't true. Look at the absurdity of all the cookie banners just to support basic login functionality. I'm all for internet privacy, but these laws are so sweeping that it's impossible to be compliant without a dedicated function for it.

No need for cookie banners for functionality like login. Ref: https://law.stackexchange.com/a/32157

Re: Reliability: It’s not great

#455

Post by snapetom »

anthlax wrote: post #415
snapetom wrote: post #100

Earlier quoted context omitted.

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 :)

There is a part of the app that extracts and parses a database log. There is C, Java, Perl, Go, and bash scripts all over the repo. The bootstrapper is written in Java, but the core work is done in Go. Commandline arguments that are documented in comments may or may not even work. The Go section is one big state machine.

That's just to take a database log, put it into JSON, and zip it up.

That all for just one step in the data pipeline. The others are slightly less hairy, but 75% of this pipeline is literally just moving data around. It goes from JSON to MySQL to Postgres to Parquet. There is no data enrichment at all during these steps. It literally just unpacks from one format, packs to another and repeat.

The whole fucking thing is just one big masturbation circlejerk for a bunch of engineers that have thankfully been RIFed/forced out...

Re: Reliability: It’s not great

#456

Post by TheDong »

machinawhite wrote: post #387
TheDong wrote: post #376

Earlier quoted context omitted.

> The one thing I am sure of is there is no way to just engineer your way to reliability. That is to say, no person, no matter how smart, can just invent some whizbang engineering thing and suddenly you have reliability. It's seems true for fly's problem space, but in many problem spaces there really are easy engineering solutions to reliability problems. For a very easy example, I once worked on a rails app that cra…

I'm actually surprised such a simple app would have such bad performance and crash at all?

I don't think the fact that it did effectively:

    data_1 = `cat ./data1.json | grep "city" | awk ....`
    data_2 = `cat ./data2.json | grep "city" | awk ....`
was exactly helping it to perform well. I'm sure rewriting the rails app to load all the data at startup, not to read each file via several hundred subshells on each request, would have made it perform well enough.

However, pretty much no matter how well or poorly the rails site is built, a static site will be easier to run reliably.

Re: Reliability: It’s not great

#457

Post by mike_d »

LunaSea wrote: post #361
mike_d wrote: post #229

Earlier quoted context omitted.

Yes. Whenever a US law and a foreign law conflict, the US law always wins when you are in the United States. Complying with US laws is also a perfectly valid defense if a European citizen or state ends up bringing action against you in a US court.

European states simply sue in their own territory or in front of the European Union Court of Justice.

Yup. Which is basically a no-op. You need a court having jurisdiction over the defendant to have any relief. Even if you receive a financial judgement, international law does not put much weight in absentia cases.

Re: Reliability: It’s not great

#458

Post by LunaSea »

mike_d wrote: post #457
LunaSea wrote: post #361

Earlier quoted context omitted.

European states simply sue in their own territory or in front of the European Union Court of Justice.

Yup. Which is basically a no-op. You need a court having jurisdiction over the defendant to have any relief. Even if you receive a financial judgement, international law does not put much weight in absentia cases.

If you have customers in the EU than the court has jurisdiction.

If the company doesn't comply, fines will be directly taken from customer payments for example.

Re: Reliability: It’s not great

#459

Post by mike_d »

LunaSea wrote: post #458
mike_d wrote: post #457

Earlier quoted context omitted.

Yup. Which is basically a no-op. You need a court having jurisdiction over the defendant to have any relief. Even if you receive a financial judgement, international law does not put much weight in absentia cases.

If you have customers in the EU than the court has jurisdiction. If the company doesn't comply, fines will be directly taken from customer payments for example.

Again - regardless of if a domestic court believes they have jurisdiction, any court case not brought in the venue of the defendant is effectively meaningless as you cannot be granted meaningful relief.

If the destination bank account is outside the EU, they can't touch it without cooperation from the defendant countries courts - which requires you to file in the defendants venue. If an EU country unilaterally seized intra-bank remittance they would be cut off from the international banking system without hesitation.

You seem to really be grasping at straws here, but the EU is not some all powerful entity that can enforce its laws outside its jurisdiction.

Re: Reliability: It’s not great

#460

Post by tpxl »

LunaSea wrote: post #414
tpxl wrote: post #409

Earlier quoted context omitted.

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 c…

I honestly can't tell if you're trolling or you said 'AWS' and 'Microsoft 360' and meant cloud and managed email.

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

There are plenty of browser alternatives (firefox, safari, vivaldi, even chromium).

There are dozens if not hundreds of email providers, and you can even provide your own.

You can 'centralize data storage' on disks on hardware you own, on premises or colocated. You could even use one of the dozens to hundreds of managed service and cloud providers.

Post reply on HN