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

381–390 of 476 posts

Re: Reliability: It’s not great

#381

Post by vendiddy »

leerob wrote: post #85
vendiddy wrote: post #63

Earlier quoted context omitted.

I can second this. We were evaluating moving off Heroku and to Fly.io, but we didn't need all of the edge compute stuff. We just want a better Heroku without having to think about infrastructure and having to think about edge compute just got in our way. I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to t…

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 even realized it was a possibility until I stumbled across a blog post.

I had to copy a NoSSR implementation of the internet. It wasn't just some flag I could toggle for a page.

I've also found myself recommending Next to folks saying "Use Next.js, but btw you don't need use SSR. Make sure the trade-offs make sense."

I'm curious if I'm in the minority of Next.js users. What percentage of them don't need SSR but value everything else?

Re: Reliability: It’s not great

#382

Post by jorangreef »

nikita wrote: post #107
mmcclure wrote: post #15

Earlier quoted context omitted.

That comment jumped out to me too, my recollection was that they've been pretty vocal about that not being something they wanted to solve themselves as a core competency. I'm not quite parsing if these two blurbs should still be taken together or if the second sentence is refuting the first. > The second problem we have with Postgres was a poor choice on my part. We decided to ship “unmanaged Postgres” to buy ourselv…

(Neon CEO) We are launching our paid tier March 15th and will be production ready shortly after. We are running 20K+ databases and measuring reliability and uptime. Generally reliability is a function of architecture (we are solid there), good SRE practices, and a long tail of event you live through, fix, and make sure they never happen again. The bigger the fleet the faster the learning.

Looking forward to it!

Re: Reliability: It’s not great

#383

Post by notpushkin »

Aeolun wrote: post #283
notpushkin wrote: post #238

Earlier quoted context omitted.

I'll start with the Swarm since it's a major point actually: Docker's Swarm mode is comparable to Kubernetes or Nomad: you can launch a cluster of servers and run your application there. Unlike Kubernetes or Nomad though, it uses mostly the same concepts Docker Compose does, to the point that your development docker-compose.yml file will likely just work there (with some minimal tweaks). I love this website that talk…

You can set up a git hook on repositories that listens for the completion of the docker_build task and then redeploys the app while pulling new images?

Not a git hook, but you can do that as a part of CI workflow. So, you can have a script like:

    docker buildx build --push ...
    curl -X POST https://lunni.example.com/api/webhooks/c8aaa9b8-1bda-4a99-820c-36a75d31f8a7
that will rebuild a Docker image, then trigger the redeploy.

Re: Reliability: It’s not great

#384

Post by vendiddy »

alexgrover wrote: post #81
vendiddy wrote: post #63

Earlier quoted context omitted.

I can second this. We were evaluating moving off Heroku and to Fly.io, but we didn't need all of the edge compute stuff. We just want a better Heroku without having to think about infrastructure and having to think about edge compute just got in our way. I feel like Next.js is in a similar position. While their main vision is SSR, I wonder if they are missing out on a chunk of the market that simply doesn't want to t…

Why would they be missing out? Vercel can host static sites just fine, whether that’s one generated by Next or any other framework or written by hand

To clarify, I'm referring to folks who just need to write single page apps, but don't benefit from SSR.

(I didn't find disabling SSR straightforward.)

I wonder if Vercel is underestimating the size of the market that just wants a "Heroku for React".

Re: Reliability: It’s not great

#385

Post by notpushkin »

moondev wrote: post #310
notpushkin wrote: post #238

Earlier quoted context omitted.

I'll start with the Swarm since it's a major point actually: Docker's Swarm mode is comparable to Kubernetes or Nomad: you can launch a cluster of servers and run your application there. Unlike Kubernetes or Nomad though, it uses mostly the same concepts Docker Compose does, to the point that your development docker-compose.yml file will likely just work there (with some minimal tweaks). I love this website that talk…

> Most important though, it would allow you to add more nodes later on, and it will then scale your services across the whole swarm – so you can start with just one server and scale to hundreds if needed. Have you in all honesty and with first hand experience, deployed and supported in prod on swarm over hundreds of servers?

Nope :') I do know a guy though, and I've heard good things. I'd love to hear about your experience too!

I know that it is possible to outgrow Swarm – I think that's a nice problem to have actually. We might include some tools for “graduating” from Lunni to something more serious like Kubernetes at some point.

Re: Reliability: It’s not great

#386

Post by speedgoose »

LunaSea wrote: post #206
speedgoose wrote: post #91

Earlier quoted context omitted.

It’s not true. I know people who lost contracts because they were using Azure and the customer wanted to respect the law.

I've talked with companies like that as well and they start with strict rules and end up allowing clouds because no solution is compliant anyway.

I guess it works when you don't have any compliant competitor.

Re: Reliability: It’s not great

#387

Post by machinawhite »

TheDong wrote: post #376
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…

> 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?

Re: Reliability: It’s not great

#388

Post by iLoveOncall »

yamrzou wrote: 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…

Really? For me it's the contrary, posts like this from companies are a signal to say "Jump out of the ship while you still can".

Kinda like when crypto exchanges tweet "Yo we're definitely not blocking withdrawals, we're perfectly healthy".

You know what would make me consider a company? The fact that they don't have a bad reputation to begin with, and don't need to make posts like that to try to save their reputation.

Re: Reliability: It’s not great

#389

Post by iLoveOncall »

alfalfasprout wrote: post #145
yamrzou wrote: 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 huge. Even as a member of a larger company, this stuff matters. If you have a vendor that doesn't bullshit you when things go wrong, you can actually trust. This is how you avoid companies having the "hmmm they seem to be having lots of issues recently, let's consider moving off them" conversation.

> This is how you avoid companies having the "hmmm they seem to be having lots of issues recently, let's consider moving off them" conversation.

Yeah, this is how you get companies to have the "well, it SEEMED they were having lots of issues, now it's clear that they indeed did, moving off of them is priority #1".

Re: Reliability: It’s not great

#390

Post by LunaSea »

speedgoose wrote: post #386
LunaSea wrote: post #206

Earlier quoted context omitted.

I've talked with companies like that as well and they start with strict rules and end up allowing clouds because no solution is compliant anyway.

I guess it works when you don't have any compliant competitor.

That is exactly the problem at hand.

It's a combination of low to no enforcement, competitivity-killing laws and unrealistic efforts for said companies to take on.

Post reply on HN