Live data from Hacker News

11 years of hosting a SaaS

ghiculescu.substack.com

171–180 of 222 posts

Re: 11 years of hosting a SaaS

#171

Earlier quoted context omitted.

I've been on unmanaged MySQL for ~8 years now. Considered switching to managed but I'm not seeing any performance or stability issues, so I guess I'll just keep this train going until it craps out on me, then restore a backup onto a managed service, say sorry for the downtime, and that'll be that.

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.

Re: 11 years of hosting a SaaS

#172
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".

Yes especially data, simplicity is key as well. Where possible go with simple but abstracted cloud storage, cloud tables and then a cloud db that is managed. We use Azure mostly right now but our storage system works across Azure storage, Amazon S3, Google Cloud and others. For tables, Azure Tables mainly. For database with filtering/paging better performant and ACID compliant cloud db, CosmosDB currently which is a…

> Where possible go with simple but abstracted cloud storage

This is the total opposite of simplicity. Simple is PG and backup setup. DONE.

Maybe you mean "comfort"?

Re: 11 years of hosting a SaaS

#173
post #4

So what are the new Herokus? What do you recommended for starting a serious project? AWS AppRunner? How about something open source?

I'am a cofounder of withcoherence.com, a PaaS developer experience on top of your own cloud. We are not open-source, but we support both AWS and GCP and provide a free tier of usage. Happy to answer any questions, feel free to get in touch!

Re: 11 years of hosting a SaaS

#174

Earlier quoted context omitted.

It’s definitely not the merchant’s responsibility to catch when your card changes. We have this at work thanks to Stripe, and it’s wildly inconsistent. But beyond that, it won’t do anything for a closed/canceled card/cardholder account. That situation was fully on OP. This could have happened at GCP, AWS, Azure, Linode, OVH, Rackspace, Oracle Cloud, you name it.

> It’s definitely not the merchant’s responsibility to catch when your card changes. Well seen that the tech exists, they're not just leaving money on the table by not using it (to update card that just expired) but they're also burning money on pointless support, support which wouldn't need to happen in the first place had they updated the month/year of expiration. I mean: we're literally talking about credit cards…

Would it be a better practice to use that tool? Yes.

Are they at fault because their customer dropped the ball so badly about paying their bill? No.

Re: 11 years of hosting a SaaS

#175
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".

Which one do you recommend?

Those get quite expensive.

Re: 11 years of hosting a SaaS

#176
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…

That's what I'm struggling with. You're not wrong, but I feel like it's way too easy to go to the other extreme and suddenly you're way in over your head.

The title is correct. But any of you changes or lessons are perfectly fine. (Sure, a bit awkward to do ssh from cafes). May be reading the Google SRE PDF (or equivalent) would have been a bit more useful. At my wife's business one of the team member shall LOGIN to DO/AWS every month send a screenshot that account/CC is in good standing.

Re: 11 years of hosting a SaaS

#177

Earlier quoted context omitted.

> It’s definitely not the merchant’s responsibility to catch when your card changes. Well seen that the tech exists, they're not just leaving money on the table by not using it (to update card that just expired) but they're also burning money on pointless support, support which wouldn't need to happen in the first place had they updated the month/year of expiration. I mean: we're literally talking about credit cards…

Would it be a better practice to use that tool? Yes. Are they at fault because their customer dropped the ball so badly about paying their bill? No.

It doesn’t matter who’s at fault. They missed a chance to provide better service and lost a customer as a result.

Re: 11 years of hosting a SaaS

#178

Earlier quoted context omitted.

Would it be a better practice to use that tool? Yes. Are they at fault because their customer dropped the ball so badly about paying their bill? No.

It doesn’t matter who’s at fault. They missed a chance to provide better service and lost a customer as a result.

Sorry, I thought your comment was in support of alberth's upthread assertion that they bear some of the fault in this.

Re: 11 years of hosting a SaaS

#179
post #112

Earlier quoted context omitted.

This precisely the niche Cloud 66 tries to fill, it caters for the growth businesses, providing initial ease but without sacrificing control. This allows companies to grow without being forced out before they are ready. (Disclaimer: I work for Cloud 66)

Does Cloud 66 have any resources on migrating a large (~300 GB) Postgres DB off Heroku, with minimal downtime? This has been our biggest sticking point when thinking about leaving Heroku.

Moving data is always the trickiest part! We get a lot of Heroku customers who need help with their data migration. My honest answer is there will always be some downtime while the switch over is happening, but we know of a few ways to reduce it. Unfortunately Heroku PG databases don't allow outside replication setup, so we can't really baseline your data and then close the replication gap with a shorter downtime. But we do support multi-DB solutions so we can run against an old and new DB at the same time while data is gradually being moved over. If you're interested, ping me at hello-at-cloud66.com if you want to discuss further :)

Re: 11 years of hosting a SaaS

#180

Earlier quoted context omitted.

It’s definitely not the merchant’s responsibility to catch when your card changes. We have this at work thanks to Stripe, and it’s wildly inconsistent. But beyond that, it won’t do anything for a closed/canceled card/cardholder account. That situation was fully on OP. This could have happened at GCP, AWS, Azure, Linode, OVH, Rackspace, Oracle Cloud, you name it.

> It’s definitely not the merchant’s responsibility to catch when your card changes. Well seen that the tech exists, they're not just leaving money on the table by not using it (to update card that just expired) but they're also burning money on pointless support, support which wouldn't need to happen in the first place had they updated the month/year of expiration. I mean: we're literally talking about credit cards…

> Well seen that the tech exists, they're not just leaving money on the table by not using it (to update card that just expired) but they're also burning money on pointless support, support which wouldn't need to happen in the first place had they updated the month/year of expiration.

To lend a bit of insight as someone who works in the payments industry: This functionality is generally not free.

If most of your customers come and update their expired cards already - or you offer a service which is so essential to your customers that they generally would freely expend the effort to do so if notified, it doesn't make any sense from a financial standpoint to pay the fees to subscribe to card issuer updates.

Post reply on HN