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…
11 years of hosting a SaaS
101–110 of 222 posts
Re: 11 years of hosting a SaaS
#102> But the worst Digital Ocean incident we ever had was when they turned all our droplets off all at once. The credit card entered into the account had expired, there was no backup card, and the contact email on the account went to a shared inbox that was not monitored. So for probably a month we were getting and ignoring billing alerts, until we really paid attention when everything was offline and not responding to…
Re: 11 years of hosting a SaaS
#103Well I do not feel any of the 3 advice he gives, good advice. First the longer you stay in heroku ,the most complex is it to exit it the time you really need it and the less flexible you are in the time being. Second, wish he had pay for a pit team sooner, but could this money better used investing in marketing or sales like he probably did ? The guy has obviously succeeded as a business owner, would it still be the…
"Made him successful" implies a causality that is a bit too strong.
Indeed, we will never know for sure.
Maybe implementing these advice would have impeded development of other critical areas of his business.
Maybe it would have would have helped make is business more successful as he would have had a more reliable product.
Or maybe the business impact would have been neutral, but would have resulted in better quality of life/less stress for him and his employees.
But in general, the way I read this article is: they made good decisions overall, but as everything in the world, it was not optimal (switching platform too early, making some big mistakes like the credit card one, etc).
It's a very interesting read nonetheless, with clear take away:
* chose boring tech you know and focus on your product, not the tech, specially in the early days
* grow your infrastructure and complexity with your product needs
* accept you will mess-up but properly learn from it, and grow your organizational knowledge, structure and processes accordingly.
Re: 11 years of hosting a SaaS
#104> But the worst Digital Ocean incident we ever had was when they turned all our droplets off all at once. The credit card entered into the account had expired, there was no backup card, and the contact email on the account went to a shared inbox that was not monitored. So for probably a month we were getting and ignoring billing alerts, until we really paid attention when everything was offline and not responding to…
It's not as simple as that. Do you know how quickly a business loses customers without being flexible? It's also reputation damaging for the market to know that DO draws a hard line.
Re: 11 years of hosting a SaaS
#105At least one tradeoff is that you'd have to be physically in a location with adequate bandwidth / latency but for various use cases it might be very cost effective during some phase of the startup.
I wonder also how the AI induced focus on specialized hardware might change the calculus
Re: 11 years of hosting a SaaS
#106> But the worst Digital Ocean incident we ever had was when they turned all our droplets off all at once. The credit card entered into the account had expired, there was no backup card, and the contact email on the account went to a shared inbox that was not monitored. So for probably a month we were getting and ignoring billing alerts, until we really paid attention when everything was offline and not responding to…
It's not as simple as that. Do you know how quickly a business loses customers without being flexible? It's also reputation damaging for the market to know that DO draws a hard line.
It’s like saying car is a shitty transportation service because it stops working once the gas runs out.
Not paying attention the the reserve light, instrument msg and pings is solely your problem. More so because you are running a business…
Re: 11 years of hosting a SaaS
#107Earlier quoted context omitted.
> The credit card entered into the account had expired, there was no backup card, and the contact email on the account went to a shared inbox that was not monitored. The using of an unmonitored email is the one that really gets to me.
Yeah. I'm not proud of it.
Re: 11 years of hosting a SaaS
#108Re: 11 years of hosting a SaaS
#109> We started on Heroku, because in 2012 if you did any Ruby on Rails tutorial that included deploying your app, you ended up with a Heroku account. Couldn't be more accurate. Heroku and Rails is almost as much of a throwback as Node and Express. You just had to be there. And it was great. Web dev was always a hobby for me as a teen, but then I turned to the rails book as a means of learning a professionally designed…
Re: 11 years of hosting a SaaS
#110What you want from day one is a completely managed hosting for tech stack you work with, but are not hard tied to forever.
Right now I am starting some new/modern meteor.js stuff again, there is meteor galaxy for hosting that "just works" for that stack, you bring your own mongodb (I prefer atlas itself, they even have serverless now), and everything is taken care of, including CI/CD/Monitoring/... . Its like a few minutes of initial configuration, and never think about it again, and if done correctly you shold have horizontal autoscale of some kind automatically nowadays.
Yes, this is significantly more expensive than directly using AWS (which they use under the hood), and even though I am personally highly trained in this stuff+terraform/cdk/..., I don't want to have all this work anymore when I also can shell out a few hundred bucks per month instead. Just in case Galaxy becomes a problem for some reason, I _still_ can deploy the app stack to some VPS provider, but I'd use some already existing automation (like meteor-up in this case) instead of really digging into typical devops topics for it.
There is a bad feeling in the mouth as an engineer to shell out "more than needed" for infrastructure, but my rule of thumb now is that I am happy to eat that frog as long as the potential cost saving is less than 2 infrastructure engineer FTEs, thats my trigger to _maybe_ discussing it.