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…
11 years of hosting a SaaS
171–180 of 222 posts
Re: 11 years of hosting a SaaS
#172> 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…
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
#173So what are the new Herokus? What do you recommended for starting a serious project? AWS AppRunner? How about something open source?
Re: 11 years of hosting a SaaS
#174Earlier 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…
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> 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".
Those get quite expensive.
Re: 11 years of hosting a SaaS
#176the 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.
Re: 11 years of hosting a SaaS
#177Earlier 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.
Re: 11 years of hosting a SaaS
#178Earlier 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.
Re: 11 years of hosting a SaaS
#179Earlier 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.
Re: 11 years of hosting a SaaS
#180Earlier 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…
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.