121–130 of 132 posts
Earlier quoted context omitted.
> Is that really a thing, with HNers of all people? You want it to be hitless. Unfortunately DNS can take days to fully propagate and you may not see mistakes until it's too late to fix them. This can cause horrifying outages. HNers should be respectful of DNS changes and plan accordingly.
You can change your DNS TTL to let say 5 minutes before you move to new IP. You can change it 3 days before the movement(?).
Earlier quoted context omitted.
Looks really expensive. And weird pricing. I click "pricing" and it gives me per user costs. Wat? I thought I was hosting stuff, not managing teams. Click on +Computing costs and it's like $0! $0! $0! Check the fineprint and its like 4GB RAM and 2 CPUs is $85/mo, or you can get the same at DigitalOcean for $24. Then add Postgres for another $95. Or if you're cheap like me, you self-host that in your $24 droplet and p…
It's a managed service. You pay a premium for it. Features like their blueprint file make it worth the price IMO - https://render.com/docs/blueprint-spec If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go. If you just have some random one-off production environment and you are happy to either manage the stat…
Looks like k8s yaml.
> If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go.
But I get that with k8s + docker too. Everything's containerized. Just run the config, it even brings up the cron jobs.
> or a k8s cluster yourself (which comes down to will more so than skill) then DO is the way to go.
Yeah...that's the rub. Takes a few weeks to learn. Worth the time cost to save the $ cost and vendor lock in IMO.
Earlier quoted context omitted.
Looks really expensive. And weird pricing. I click "pricing" and it gives me per user costs. Wat? I thought I was hosting stuff, not managing teams. Click on +Computing costs and it's like $0! $0! $0! Check the fineprint and its like 4GB RAM and 2 CPUs is $85/mo, or you can get the same at DigitalOcean for $24. Then add Postgres for another $95. Or if you're cheap like me, you self-host that in your $24 droplet and p…
Everyone charges for convenience. A lot of people don't want the headache to run and secure their own Postgres, for example. It's a trade-off, same as servicing your car vs just handing it off to a garage mechanic.
Earlier quoted context omitted.
Yes, chargeback is pretty much a nuclear option. But in his case they'd already closed his account and are not responding, so time for the nukes.
Just a heads up, Salesforce owns Heroku, so if OP did this he had better be willing to lose access to anything else Salesforce related. Like Slack or Quip
Earlier quoted context omitted.
OP here: that’s a good idea that did come up to mind (specifically rotating the Redis queue credentials). I was just sure Heroku’s gonna take care of this shit by now. BTW, I’m not 100% sure it’ll work: if Heroku updates that zombie dyno’s environment variables, it may still have access to the new credentials :/ (My Redis instance is also a Heroku add-on)
> BTW, I’m not 100% sure it’ll work: if Heroku updates that zombie dyno’s environment variables, it may still have access to the new credentials :/ (My Redis instance is also a Heroku add-on) If the configuration only read once during startup, the celery process won't use the new configuration unless it's restarted, right?
>> So is it Celery then? This awesome library has its fair share of complaints about duplicated task execution — most are due to misconfiguration. I scanned dozens of Stack Overflow threads and GitHub issues in Celery’s repository. Very few were relevant to my case, and none of the fixes were. I was so annoyed by the pain of configuring Celery I stopped my project and wrote my own job queuing system. Job and message…
Earlier quoted context omitted.
It's a managed service. You pay a premium for it. Features like their blueprint file make it worth the price IMO - https://render.com/docs/blueprint-spec If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go. If you just have some random one-off production environment and you are happy to either manage the stat…
> It's a managed service. You pay a premium for it. Features like their blueprint file make it worth the price IMO - https://render.com/docs/blueprint-spec Looks like k8s yaml. > If you are working on a team and you want everyone to be able to spin up a copy of the production infrastruction for each pull request then PaaS is the way to go. But I get that with k8s + docker too. Everything's containerized. Just run the…
As I said, there’s more of a issue of wanting to maintain your infra than knowing how to.
Earlier quoted context omitted.
File a chargeback each time they charge your card. The merchant has to pay the transaction fees both ways and a fee for the chargeback.
But don't do it if its Google. I had been charged for g-suite for domain that expired and someone else picked it up (and parked), long story short after 3 months of back-and-forth with "support" I gave up and started with chargebacks. It was 7 of them, each month one for $6, until one sunny day I woke up and my own gmail account, my youtube TV and Google Play on 2 Android devices all got blocked with messages popping…
This is why I use the git commit short hash as part of the identification of the service (eg: container name). Allows for quick check of which is the running code version and identify problems like these.
Earlier quoted context omitted.
you clearly have no idea how things work outside of hobby projects, what about reliability? scalability, guaranteed uptime, resolving incidences,... You can account for all for that for yourself by creating a mini cloud provider.. good luck with that
Half of the "robust" and highly complex solutions I see employing modern practices go down way more often than the simple version that the GP described.