> I’ll never use fly because of the people that work their and their rage bait nonsense

Get fucking mad you sad little internet.

> Most of the time. If heroku is having downtime. Then Amazon is having downtime. Then half the internet is down. Let customers know Amazon is down. Sit back and relax.

Yeah, if AWS is down you're fucked anyways. Probably can't pay rent, use your bank or sometimes even your credit card. You have bigger problems at that point.

Hope you have extra cash!

>> hthrowaway5
> As someone that was a very active Heroku user for years and then worked there for years: I wouldn't trust it as my host. There is nowhere near enough people maintaining it in order to have confidence it'll run without reliability or security issues. They aren't exactly in a position to retain or attract talent either.
> I thought Cedar was going to fall over years ago but ironically I think people migrating off the platform are helping it stay alive.

I think I have worked with this person, they have the good takes. Cedar is falling.

> I think people misconstrue the benefits of k8s to be related to reliability or similar. Ultimately it's about the API and the consistency and productivity it offers.

apiVersion: christine.website/shitpost/v1
kind: Retort
in_reply_to: hn://31391662
name: whydoihavetonamethis
data: |
Yeah IDK man this is pretty simple or something. No overly complicated bullshit at all. Fuck norway and ontario amirite.

> It's also trivial to serve read requests from a caching layer or via a CDN. At any sufficient scale, you're probably going to need a CDN anyway, whether your database is replicated or not.

Most of the time adding a CDN is 1 step: having the CDN reverse proxy to your shit.

> You don't want every read to hit your database.

Don't use a database then.

> what if they want to use a CMS?

Use a CMS then

wow such amaze

> The failure wasn't in the prohibitive cost at scale (though that factor didn't help); it was that for most real-world stuff we need IaaS, not PaaS.

No, you think you want IaaS, but PaaS is really good enough for the p90 of apps. You're probably in the p10 of apps that are shit for PaaS stuff and that's fine. But p10 is not p90, that's a difference of at least 80.

> But no periodic tasks with a scheduler that is part of the platform.

Yeah, run cron in a container though

> Perhaps for looking back to see the history of things, a unified ledger is convenient.

Use git.

> For low-latency workers like that it might make sense to just run them on the same instance as the web servers.

Nirvana has been found.

> Of course none of that matters if you have 4 developers like OP but for folks like myself that routinely end up at places with 300+ engineers then it's a huge deal.

Excuse me I have 6 developers you internet. That is at least 2 more than 4.

> Wow, that's a horrible way of thinking about the user experience. And honestly, I'm not surprised. That's why companies that really care about the user experience will always steal market share from those that don't.

What the fuck are you supposed to do then? This is the horror of the cloud.


What do you do when your datacenter gets hit by a meteor? Think about this. Really think!

@f0x Then you have no more datacenter problems though

@cadey Follow your Disater Recovery (DR) and Business Continuity (BC) plans, of course. Right? Right? <Crickets chirping>

I live and work in California. We have earthquakes. Data center down is a realistic part of our threat model.


Sign in to participate in the conversation
Manechat on Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!