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

301–310 of 476 posts

Re: Reliability: It’s not great

#301

Post by eyelidlessness »

snapetom wrote: post #100
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 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…

When I was in an engineering IC version of this role, I longed for someone like you to have my back in management and have customers’ backs too. If I had a time machine and a magic lamp I’d team up with you.

As a future representation of past me, I can tell you:

1. Everything it’s making you feel is valid.

1b. If you’re feeling burnt out, please listen to it. It gets worse if you let it.

2. While I can’t hire you now, I can already tell you’re eminently hireable. If you have any cautious inclination to move, you will probably be better served by greener pastures.

3. Just take care of yourself.

4. When 3 contradicts 2, favor 3.

Re: Reliability: It’s not great

#302

Post by ricardobeat »

alex_sf wrote: post #298
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.

Not exactly related to the OP, but: I think I speak for a large number of folks when I say that we don't care. The EU keeps passing all sorts of absurd laws that require dedicated auditors to comply with. It's just not going to happen. If they decide to actively enforce these things, they'll just isolate themselves from the rest of the world.

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.

Re: Reliability: It’s not great

#303

Post by teaearlgraycold »

anurag wrote: post #218
mrkurt wrote: post #159

Earlier quoted context omitted.

This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want Heroku but close to users. It's not exactly edge compute. In some cases, it's "Heroku in Tokyo". In others it's "Heroku, but running in all the english speaking regions". I think the t…

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. :(

Re: Reliability: It’s not great

#304

Post by simonw »

richardhod wrote: post #82
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…

What are the limitations to heroku that people are going to Fly for? Maybe there's a standard article that would be useful to read about it?

People don't trust it any more, because Salesforce have been under-investing in it for years and recently rug-pulled on everyone who had ever used the free tier (after providing that free tier for 15 years already - long enough for people to reasonably expect it to continue).

Re: Reliability: It’s not great

#305

Post by kelp »

mrkurt wrote: post #159
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…

This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want Heroku but close to users. It's not exactly edge compute. In some cases, it's "Heroku in Tokyo". In others it's "Heroku, but running in all the english speaking regions". I think the t…

Your margins are going to end up being a lot better than any other PaaS that's built on top of the big cloud providers.

Re: Reliability: It’s not great

#306

Post by simonw »

gizmo wrote: post #237
dadrian wrote: post #180

Earlier quoted context omitted.

Sorry, what? Do you expect that no company can think about what to write before they post it, or that any post about anything internal must cover all internal issues? Posts must be either all roses or a no-thought laundry list of everything bad?

Of course not. The point is that the reader should recognize corporate communication for what it is: fundamentally self-serving. Corporate communication should therefore be met with thoughtful skepticism, and not with naivety or cynicism.

There is a world of difference between the tone and content of that Fly post and the tone and content that most people expect from cover-your-ass corporate blog posts.

Sure, both are examples of "self-serving corporate communication" - but it's clear that the way Fly communicate here is more valuable and trustworthy than so many other examples of this kind of thing handled poorly.

Re: Reliability: It’s not great

#307

Post by mrkurt »

say_it_as_it_is wrote: post #271
mrkurt wrote: post #159

Earlier quoted context omitted.

This is, indeed, the exciting part. As Heroku fans, we never really felt like it needed a replacement. And if it did, it seemed like Render was the natural Heroku v.next. One thing we've noticed, though, is that people do actually want Heroku but close to users. It's not exactly edge compute. In some cases, it's "Heroku in Tokyo". In others it's "Heroku, but running in all the english speaking regions". I think the t…

Can you please explain what the Vault related failure is about? Is this about timing out services failing to start within an acceptable time range?

Yeah, basically that. One of the servers in our Vault cluster failed and prevented Vault agents from receiving secrets. For Nomad apps, this showed up as "allocation failures" and failed deploys. Machine based apps took an abnormally long time to start and caused other issues.

Re: Reliability: It’s not great

#308

Post by nl »

scubbo wrote: post #64
pid-1 wrote: post #54

Earlier quoted context omitted.

No

Can you elaborate?

(No the OP)

I like Amplify and use it often. However, it isn't well integrated with "normal" backends, so if you want to keep a backend and frontend deployed together you either have to use their Amplify backend API or work out your own deployment.

Re: Reliability: It’s not great

#309

Post by nwienert »

notpushkin wrote: post #184
satvikpendem wrote: post #104

Earlier quoted context omitted.

I'm going to plug Coolify, an open source Heroku alternative (with Docker support too) that I'm using on a cheap $5 Hetzner server which is a lot cheaper than the equivalent Fly or Render etc service, and it really doesn't have much upkeep from me even if you add in the time setting up the server initially, which is like an hour, and afterwards, it Just Works™. https://coolify.io

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.

Re: Reliability: It’s not great

#310

Post by moondev »

notpushkin wrote: post #238
arjvik wrote: post #211

Earlier quoted context omitted.

Lunni has got an interesting concept — and I can actually see some good uses for it! Is the actual "production" workflow still pasting a Docker Compose file in? I would much rather have an automated deployment process that doesn't require human input, that way it can be scripted as part of CI/CD, etc. Personally, I fell in love with `git push production` (naming a git remote `production`) to trigger a deploy. Ironica…

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?

Post reply on HN