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

431–440 of 476 posts

Re: Reliability: It’s not great

#431

Post by jen20 »

nprateem wrote: post #395
nu11ptr wrote: 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?

Because if they admit to them they’re probably in the process of fixing them. When compared to a certain B tier cloud who gaslight users about flaws in the product and API, the amount of effort expended to get to an admission of fault is much lower for companies not inclined to lie by omission.

Re: Reliability: It’s not great

#432

Post by crabbone »

I'm not in the Web business, and have no idea what fly.io is offering, but whenever I hear anyone trashing Consul, I give them a standing ovation. An application which decided to use Base64-encoded JSON for its communication protocol deserves every bit of mockery it can get.

Re: Reliability: It’s not great

#433

Post by lucasyvas »

vendiddy wrote: post #381
leerob wrote: post #85

Earlier quoted context omitted.

One of the key design choices of Next.js was to enable granularity on the runtime (Node.js or Edge[1]) and the rendering method (static or dynamic[2]) on a per-route basis. If you want a full SSR site, that's okay. If you want a full static site, that's also okay. We often see folks wanting a mix of both. For example, maybe the /about page is static, but the home page is dynamic and personalized based on the visitor.…

What I love about Next.js is not having to think about hosting, webpack, hosting, typescript, scss, and so on. It just works. I initially fought to get SSR working, fixing hydration errors and making sure our code was isomorphic. I later realized that I can just use the parts of Next.js we need and turned off SSR. It wasn't a big value add for our particular product. But doing this wasn't straightforward. I hadn't ev…

FWIW, not currently using Next.js, but I'm someone who values everything else but not necessarily SSR. I've been eyeing to use Next.js in SPA mode. There are dozens of us!

Re: Reliability: It’s not great

#434

Post by randomswede »

azurelake wrote: post #214
mota7 wrote: post #193

Earlier quoted context omitted.

Like most things, it's more complex than that, and as a result it can be either faster or slower than 'median(RTT to each DC in quorum)'. It's a delicate balance based on the locations that rows are being read and written. In the case where a row being repeatedly written from only one location and not being read from different location, the writes can be significantly faster than would be naively expected.

> Like most things, it's more complex than that, Sure, no doubt. My point wasn't really about the particularities. It was around the mistaken idea that I see sometimes where people believe that TrueTime allows for synchronized global writes without any need for consensus.

The speed of light in vacuum is a hard upper limit. Most signal paths will be dominated by fibre optics (about 70% of C) and switching (adding more delay).

But, yes TrueTime will not magically allow data to propagate at faster-than-light speeds.

Re: Reliability: It’s not great

#435

Post by anurag »

teaearlgraycold wrote: post #303
anurag wrote: post #218

Earlier quoted context omitted.

I shared your post with Render's engineering team and it got a lot of love because we know the struggle and can truly empathize because of our own Heroku-accelerated growth. What Fly and Render are doing is hard, but someone needs to do it. If the market is big enough to support AWS/GCP/Azure as $N00B businesses each, it’s not a leap to imagine a future where both Fly and Render are incredibly successful, loved, and…

I've just started using Render and it's great! Goodbye Heroku. :(

Thanks!

Re: Reliability: It’s not great

#436

Post by HPsquared »

throwawaaarrgh wrote: post #324

I've been doing reliability stuff for near two decades. 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. Reliability is a thing that grows, like a plant. You start out with a new system or piece of software. It's fragile, small, weak. It is threatene…

Good engineering helps reliability but doesn't guarantee it.

Bad engineering causes bad reliability.

Re: Reliability: It’s not great

#437

Post by KSteffensen »

PeterisP wrote: post #410
fmajid wrote: post #62

Earlier quoted context omitted.

The US CLOUD Act means a EU customer cannot use a US cloud provider to host PII, even if the server itself is physically in the EU, because US law will still compel the provider to yield the data to US authorities. The European Commission is trying to paper over the cracks with a fig leaf of judicial review, but it's only a matter of time until a Schrems III decision from the CJEU invalidates that polite fiction.

I haven't put much thought in this, but is a Frankfurt data center provided by Amazon Web Services EMEA SARL (a Luxembourg-based company) considered a US cloud provider or a EU one? I mean, being wholly owned by a foreign owner doesn't generally change your jurisdiction, and employees of that wholly owned subsidiary (including its directors) are not required to obey USA laws or court orders but are required to comply…

My understanding is that the distinction hinges on whether the data is available to a US based employee. Can the NSA show up at a US address and tell the people there to hand over the data? Can this data transfer happen without an EU based person taking some action? If the answer to both questions is yes, the data handling is not compliant.

Of course, IANAL, do your own research, etc.

Re: Reliability: It’s not great

#438

Post by trilobyte »

cowl wrote: post #355
karmelapple wrote: post #72

Earlier quoted context omitted.

I agree. And I know this is unpopular, but I think none of these companies should be expected to have a free tier. A low-cost tier? Certainly. Perhaps even a free trial with a credit card? Great. But our team, who has used Heroku for over a decade, got bit multiple times by Heroku having a free tier. Why were we impacted by other apps? Because Heroku’s load balancers are shared amongst all their apps. That includes a…

Most of these platform have reached their critical mass to stay in business (and time to attract the customers like you) only because of the free tier. Sorry but even a low cost tier is too much for most wanting to give a try to a new infrastructure/stack. Most of these adoptions come from hobby projects trying it first and then recommending to use it in a professional setting. In a professional setting yes. you can…

Do you have examples of companies in this space that actually reached break-even? Heroku never hit profitability as far as I remember and with the Salesforce acquisition the question of profitability is moot. AWS is a counter-example to using a free tier as a GTM strategy. AWS did not start with a free-tier offering for S3 or EC2, that only came years later. By then they already had significant traction in the market.

Re: Reliability: It’s not great

#439

Post by notpushkin »

nwienert wrote: post #309
notpushkin wrote: post #184

Earlier quoted context omitted.

Dokku is also nice and battle-tested: https://dokku.com/ And may I also plug Lunni, a self-hosted Docker Swarm-based PaaS I'm working on right now: https://lunni.dev/ Both work pretty well on $5 servers.

I use Swarm for my own little app and love it, you should set up a Twitter so I can follow along on progress.

Thank you! No Twitter yet but if you're on Mastodon by any chance: https://fosstodon.org/@lunni/

Re: Reliability: It’s not great

#440

Post by alex_sf »

tpxl wrote: post #411
alex_sf wrote: post #329

Earlier quoted context omitted.

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

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.
Post reply on HN