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

331–340 of 476 posts

Re: Reliability: It’s not great

#331

Post by josegonzalez »

outworlder wrote: post #24

> This is a theme. Existing open source is not designed for global deployment Eh? Unless you are consuming something as a service and it actually advertises it as a feature, nothing is ready for 'global deployment'. If you have a 'centralized' secret storage, then you have made it tied to a region. Want to have redundancies and lower latency? You'll have to distribute it. Vault has docs about this: https://developer.…

This one is interesting because Vault has an enterprise product which I assume (hope?) Fly is paying for. That enterprise version includes performance replicas, which allows for cross-region replication of secrets with region-local reads (and slightly lower writes). The OP almost makes it sound like they are using the non-enterprise versions (or at the very least, not taking advantage of this particular functionality).

That said, I'd imagine with large enough scale, these sorts of features break anyways.

Re: Reliability: It’s not great

#332

Post by chillfox »

quickthrower2 wrote: post #272
chillfox wrote: post #265

Earlier quoted context omitted.

I am willing to pay a little extra for a nice dev/ops experience and simple/easy solutions that doesn't require spending days reading docs and diving into dashboards with thousands of options. Usually this results in me jumping on new platforms and then abandoning them once they add too much complexity.

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

Sadly I think you are likely correct.

Re: Reliability: It’s not great

#333

Post by josegonzalez »

doodlesdev wrote: post #326
josegonzalez wrote: post #255

Earlier quoted context omitted.

Dokku Maintainer here. I don't really have a business model. I do take donations from Open Collective (and Github Sponsors, which funnels to OC) and there is Dokku Pro, but those don't collect anywhere near the funds I'd need to stop my dayjob (at least now. Maybe someday?). My business model is that code releasing is something I'm pretty passionate about. Dokku isn't even originally my project (Jeff Lindsay started…

Oh that's really cool to know, wasn't expecting the Dokku maintainer to read my comment LOL. From what I had looked at some time ago I though the project was run with the profits from Dokku pro, although upon further thought I understand that that's probably not enough to keep someone working full-time on it LOL. I checked the repo and yeah, it checks out, Dokku _is_ pretty manageable with a decently small codebase.…

Nah Dokku really is mostly a labor of love. Originally I started working on it to provide a Heroku alternative for a group of students that couldn't afford what they needed to on Heroku (this was like... in 2014) and I've since been using it to run all my own stuff and the occasional client install when I do freelance.

Re: Reliability: It’s not great

#334

Post by milani »

samwillis wrote: post #18

Fundamentally I think some of the problems come down to the difference between what Fly set out to build and what the market currently want. Fly (to my understanding) at its core is about edge compute. That is where they started and what the team are most excited about developing. It's a brilliant idea, they have the skills and expertise. They are going to be successful at it. However, at the same time the market is…

> lower cost as you scale

The cost aside, I'm wondering how fly or heroku support their customers when they grow to microservices ecosystems.

The problem shifts from deploying easily to deploying reliably meaning one release of a service should not break the other services. Other problems appear too, like service discovery, peer authentication, gateways, test and staging environments where there are downstream dependencies, etc.

Are customers supposed to leave when they grow to this level? Or are there solutions for these?

Re: Reliability: It’s not great

#335

Post by [deleted] »

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.

[deleted]

Re: Reliability: It’s not great

#336

Post by miyuru »

latchkey wrote: post #319
vineyardmike wrote: post #140

Earlier quoted context omitted.

Google associates different accounts that are from the same owner when handling issues FYI. So if they think your account is doing something wrong on GCP, be wary of associated accounts.

Never once heard of that.

https://news.ycombinator.com/item?id=17115643

Re: Reliability: It’s not great

#337

Post by pcthrowaway »

tptacek wrote: post #292
pcthrowaway wrote: post #291

Earlier quoted context omitted.

Are there any plans to make Corrosion open source? Or are you able to talk at all about the technologies/patterns used to create it? I feel like service discovery is still ripe for disruption

Yeah, we'll for sure talk about it more some other time. Mostly today we want to talk about how we were sucking ass at customer comms.

Definitely looking forward to it!

Re: Reliability: It’s not great

#338

Post by injinj »

tptacek wrote: post #330
dastbe wrote: post #327

Earlier quoted context omitted.

> I do disagree that there are opportunities to benefit from distributed consensus there's some benefits to static stability and grey failure, but sure, whatever. the important bit is to have clear paths of aggregation and dissemination in your system. that being said > it doesn't matter what some server in SJC says it's hosting it kind of does matter doesn't it? assuming that server in SJC is your forwarding proxy t…

My point is just that there isn't a consensus algorithm that needs to get run to know which of the two proposals to accept.

It doesn't need a raft consensus algorithm, but corrosion does converge to a consensus, doesn't it? In the OSPF example, that does needs to converge to a state that is consistent and replicated on all the routers, otherwise loops and drops will occur. I'm curious if any convergence benchmark has been done that compares raft to corrosion.

Re: Reliability: It’s not great

#340

Post by onethought »

Aeolun wrote: post #275
anurag wrote: post #136

Earlier quoted context omitted.

(Render founder) I'd love to understand why you think this is the only outcome. Render has positive gross margin and a clear path to profitability based on both our growth so far and the tailwinds in this space. I'm also aware of other companies like ours that have grown all the way to IPO or are well on their way. I'm very explicit both internally and externally that an acquisition is a failure mode for Render. We'r…

> I'd love to understand why you think this is the only outcome. I’m curious why you think it isn’t? On a long enough timescale all good things seem to be acquired by large megacorps for a fuckton of money. Slack, Linode, Minecraft, the list goes on. Eventually they all make the thing less than it was before under the founders’ vision. At least from my perspective. It won’t stop me from cheering them on, but I’m stil…

Spotify, Apple, Amazon, Facebook, Twitter (kinda), Valve all have not been acquired and have existed for a long timescale...
Post reply on HN