4 ms·
You can't get out of it completely, but you can reduce the risk of it actually occuring and, maybe more importantly, reduce the constant paranoia whether the sy
by smoe 6y ago
You can't get out of it completely, but you can reduce the risk of it actually occuring and, maybe more importantly, reduce the constant paranoia whether the system is ok or not.
What has helped me as the only technical founder, as freelancer or in very small teams in general:
- Choose boring technology. Especially when alone I prefer reliability and tons of state of the art on how to operate it, over shiny features
- Choose technolgy and infrastructure that you know. It is a whole lot easier to maintain a stable system with something that you have ample experience with.
- Keep system complexity roughly aligned with team size. E.g. when alone, it might not be the best idea to maintain 5 very different database systems altough on paper each is "the best tool for the job"
- I don't think you need any super advanced, well tought out archiecture, but if you are constantly fire fighting while at work, it might not even be good enough
- Setup basic automation so the system can recover iteselffrom the unavoidable but benign hickup every now and then.
- Don't deploy before going for lunch, coffee break, dinner, weekends, etc.
- While working, observe your systems behaviour over time, and especially the impact of changes on it. If you see a degradation, fix it or at least put it in the backlog. Otherwise it will bite you eventually out of nowhere.
- Have nice error pages and messaging that are shown to users when the system fails. In my experience in early stage companies, crashes suck, but aren't actually that bad after all and users are quite lenient as long as they see that the system is down instead of having the bad experience of it just not working correctly.
- ncallaway 6y agoI think this last point is super important! Focus on making the experience of your app crashing as not miserable as possible. Try to eliminate as much as possible user loss of effort if your server crashes (if you have a long form a user needs to fill out, consider persisting the data and restoring it from local storage, so if the server is down and the user has to come back later to submit their data isn't lost). If you can have a not awful experience when your small SaaS crashes, then it's probably okay to aim for 2-nines* of reliability instead of 5-nines. You're not Amazon as a small SaaS, it's okay to have a little bit of downtime now and again. Your product is important, but it's also important to keep in mind your quality of life. Spending the time to polish the failure scenario, means you can be a little more tolerant of failure scenarios. * maybe slightly more than 2-nines, but that's the general idea.
- aprdm 6y agoYes, unless your SaaS deals with life and death or 99.999% uptime contract, you're pretty safe running something like Django+Redis+Postgres+NGINX in a single box for years and sleeping well... once you hit some really big number of users you might want to change it a bit and hire some people.
- deleted 6y ago[deleted]
- fraserharris 6y agoThis is great advice for any SaaS company. We scaled to ~80 engineers and >1,000 customers on an almost entirely monolithic app running JARs on EC2 instances with a single Postgres database. Keep it simple & focus on delivering product features that create customer value.
- pfranz 6y agoTwitter's Fail Whale is an example of the last. I was surprised how long the good will lasted. Twitter started in 2006, the SXSW where it gained a lot of traction was in 2007, FailWhale looks like it was publicaly "named" in 2007/2008 and they discontinued it in 2013. The image itself was a stock image they bought.