Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

11 years of hosting a SaaS

ghiculescu.substack.com

Post reply on HN
Print view View original

211–220 of 222 posts

Re: 11 years of hosting a SaaS

#211

Post by anurag »

flippy_flops wrote: post #186
ksajadi wrote: post #14

the progression from Heroku to AWS is very common as SaaS businesses grow. However one thing that’s missing from all “alternatives to Heroku” is what I call life after deployment or Day-2 operations. Many solutions show you a sleek demo of how easily you can deploy a Hello World app to their platform but leave you in a straight jacket when it the app is deployed and you need tools to keep it running, like changing an…

I hate what Salesforce has done to Heroku but after a year of running our saas on aws, render, and fly - here I am, back on Heroku. It sucks, but slightly less than the alternatives. Fly has potential, but they've changed/grown so much that most docs are out of date, everything is buggy, support is not very responsive, and their security posture leaves a lot to be desired. Not a fun place to be production issues pop…

(Render CEO) What can Render do better?

Re: 11 years of hosting a SaaS

#212

Post by rudi_mk »

jmuguy wrote: post #209
rudi_mk wrote: post #208

Earlier quoted context omitted.

Hello! Author of that little blog post there. Happy to be hit up with thoughts/feedback when you give it a shot!

Thank you so much for writing that. I was starting to lose hope of getting our data out of Heroku without some insane amount of downtime.

Please feel free to DM me should you need any tips with this. Email - me[at]rudimk.com.

Re: 11 years of hosting a SaaS

#213

Post by flippy_flops »

friism wrote: post #210
flippy_flops wrote: post #186

Earlier quoted context omitted.

I hate what Salesforce has done to Heroku but after a year of running our saas on aws, render, and fly - here I am, back on Heroku. It sucks, but slightly less than the alternatives. Fly has potential, but they've changed/grown so much that most docs are out of date, everything is buggy, support is not very responsive, and their security posture leaves a lot to be desired. Not a fun place to be production issues pop…

(I work at Heroku) Do you have more details on what sucks? Anything we're not already tracking to fix in our public roadmap? https://github.com/heroku/roadmap/issues

Glad to hear there's a roadmap. In my PAAS thrashing I've got quite a few notes:

- no wildcard subdomain ssl - poor metrics, nothing per instance - poor dyno granularity - (jumps from 2.5GB RAM to 14, no cpu/storage control) - no transparency on what each dyno actually is - external postgres replication disabled (deal breaker) - no first class postgres metrics and access logs/alerts (kibana recommended, but not great) - no external postgres backups (e.g. S3) - no deletion locks on dynos and add-ons, esp databases!!! - no warning when add-ons like databases are being deleted as a result of apps being deleted - deleting an add-on also irreversibly deletes all replicas and backups - painfully inconsistent naming for databases through their connection str env - dyno types for build processes use Perf-M? Not configurable - No lambda or github action style computing - No scheduled scaling - Unable to choose aws-us regions - Hard 30s timeout limit - Limited to 1 api key per user. No labels, configurable permissions, usage logging - no http/2 - frustrating enterprise offering. massive over-sell, near zero value

Re: 11 years of hosting a SaaS

#214

Post by friism »

flippy_flops wrote: post #213
friism wrote: post #210

Earlier quoted context omitted.

(I work at Heroku) Do you have more details on what sucks? Anything we're not already tracking to fix in our public roadmap? https://github.com/heroku/roadmap/issues

Glad to hear there's a roadmap. In my PAAS thrashing I've got quite a few notes: - no wildcard subdomain ssl - poor metrics, nothing per instance - poor dyno granularity - (jumps from 2.5GB RAM to 14, no cpu/storage control) - no transparency on what each dyno actually is - external postgres replication disabled (deal breaker) - no first class postgres metrics and access logs/alerts (kibana recommended, but not great…

> dyno types for build processes use Perf-M? Not configurable

What are you looking for here? Larger build dynos? Heroku provides the build service for free so we use perf-m dynos to get fast builds with reasonable cost (for us).

Re: 11 years of hosting a SaaS

#215

Post by whynotmaybe »

tacker2000 wrote: post #171
whynotmaybe wrote: post #131

Earlier quoted context omitted.

Do you know how long the downtime might be? Have you tested your backup recently? Gitlab had a long downtime because the backup was huge and on the other side of the country. The backup server was on a low speed network. https://www.arcserve.com/blog/lessons-learned-gitlabs-massiv... How much money would you lose if you were down for one week? How many customer would you lose? How much credibility would you lose? For…

I get what your saying here, but its again the comparison with Github and extremely large sites thats the problem. Most of us dont run google/fb/github scale sites and the backup will probably fit on an external HDD and in some cases would be even downloadable over S3 in an hour.

That's what I can't be comfortable with : "would".

How long does it take to try it? A day?

Well then try it, either it'll work flawlessly on the first try, either you'll learn that the backup you have doesn't include logins, password and the security configuration that goes with it. Or that the dump you took lost some data because it wasn't in the right encoding.

Or the tape drive you're using need specific drivers that aren't available on the web anymore because the company website's closed.

... This is a work of fiction. Any similarity to actual events might be purely coincidental...

Re: 11 years of hosting a SaaS

#216

Post by Ambix »

Radim wrote: post #17
rozenmd wrote: post #12

> Use managed services for as long as possible Big agree here. Yes, you can save stupid money by handrolling postgres on an extremely beefy Hetzner server, or you can pay someone else and keep building your product: https://onlineornot.com/self-hosting-vs-managed-services-dec... This isn't to say, "don't bother learning how to do it yourself", but more "learn to pick your battles".

It may be a generational thing, a matter of familiarity with computing and computers. For someone who's lived through the 80s, "handrolling postgres" doesn't sound nearly as scary as you imagine. I expect the cost/benefit analysis of "handrolling postgres on a beefy Hetzner server" vs "navigating the menus and options of AWS services" would be different for different teams.

Yep, I'd always prefer freedom and power of hosting my own PG instance upon a some robust VM offering to guiggling with clumsy AWS menus.

Re: 11 years of hosting a SaaS

#217

Post by Ambix »

speedgoose wrote: post #39
Radim wrote: post #17

Earlier quoted context omitted.

It may be a generational thing, a matter of familiarity with computing and computers. For someone who's lived through the 80s, "handrolling postgres" doesn't sound nearly as scary as you imagine. I expect the cost/benefit analysis of "handrolling postgres on a beefy Hetzner server" vs "navigating the menus and options of AWS services" would be different for different teams.

I'm looking at the ansible playbooks to setup my favourite beefy baremetal Hetzner server (128GB ram, Ryzen 9 5950X 16-Core, 450Gb fast NVME SSD, 3.5TB x2 NVME SSDs, 155€/month): - Install Debian 11 while booted in rescue mode. - Setup the root file system encryption using cryptsetup and dropbear (to enter the key during the boot through SSH). Involves chroot and some fun commands. - Setup ZFS encrypted mirror filesy…

OMG you do not need this bloatload for just PG hosting. Just harden SSH, harden PG configs and voila :)

Re: 11 years of hosting a SaaS

#218

Post by PaulRobinson »

Radim wrote: post #17
rozenmd wrote: post #12

> Use managed services for as long as possible Big agree here. Yes, you can save stupid money by handrolling postgres on an extremely beefy Hetzner server, or you can pay someone else and keep building your product: https://onlineornot.com/self-hosting-vs-managed-services-dec... This isn't to say, "don't bother learning how to do it yourself", but more "learn to pick your battles".

It may be a generational thing, a matter of familiarity with computing and computers. For someone who's lived through the 80s, "handrolling postgres" doesn't sound nearly as scary as you imagine. I expect the cost/benefit analysis of "handrolling postgres on a beefy Hetzner server" vs "navigating the menus and options of AWS services" would be different for different teams.

If you're managing AWS infra through the web application, you're definitely not doing things as per AWS-prescribed best practice.

Re: 11 years of hosting a SaaS

#219

Post by jarebear6expepj »

ValtteriL wrote: post #117
jarebear6expepj wrote: post #2

I'm sure its interesting but I am making a conscious choice to not read or linger on user hostile articles. As soon as I want to scroll I am interrupted by a page takeover requiring action and subsequently compelling me to lose interest. Did you want me to read it or click buttons for you? Too bad your UI gets in the way of the U.

Firefox's reader view gets rid of all that on top of reducing other distractions

So does closing the tab.

Re: 11 years of hosting a SaaS

#220

Post by chillfox »

AndroTux wrote: post #77
chillfox wrote: post #62

Earlier quoted context omitted.

I don’t think it’s unreasonable to expect that multiple channels of communication will be tried before cutting off service, especially not for services provided to a business.

For a business that makes checks notes 50 bucks a month in revenue with DO? If this were the case, prices would be astronomically high because there would be tons of scammers and bad actors abusing this system, leaving their servers running for months, because apparently DO has to send them a letter via snail mail to Antarctica and wait for their response. All of this would then have to be paid for by legitimate cust…

"For small $50 charges? No way."

Why not? If the phone companies here can extend that courtesy to normal consumers then I find it ridiculous to suggest that a cloud provider couldn't afford to do the same.

Post reply on HN