How do you setup your (web) Saas backend architecture ?

Hi, in DigitalOcean you can do weekly backups of the whole instance, just enabling backups. You can also do manual snapshots of instances and/or volumes (I don't recommend using DO volumes for the DB as they have low IOPS compared to the native instance storage).

I've used this guide to do daily backups as I'm using Postgres:
https://coderbook.com/@marcus/how-to-automatically-backup-postgres-to-s3-and-cloud/

But there are plenty of guides out there depending on the database you are using and where do you want to store the backups.

Hi Arvid, yes we had some issue like that in the past, a third-party provider for one important "micro" service that was having downtime decreasing the quality of our service, and I know that feeling.

What I want to highlight is, you don't really need autoscaling and high availability when you are just starting out, I've committed the mistake of creating the perfect state-of-the-art high available and scalable infrastructure for some projects that never worked and it was just a waste of time.

I forget about authentication. Authentication with firebase is the easiest I have seen. I think email and social media authentication for my project https://watermark.ink is completed in couple of hours.

It sounds kind of like optimizing for divorce considerations when planning a first date.

Let's say you've build a system that runs on dedicated Hetzner servers and requires special knowledge to operate. There is a number of hacky shell scripts for deployments, code pushes trigger certain scripts, and cron jobs handle overnight backups.

Compare this to a containerized system that is being built on a CI system with config files that are fully documented. The deployment process is being done through version tags, and it triggers a rolling update.

When your business is being acquired, there is a thorough due diligence phase. In that phase, the purchasing party will inspect all of your tech. The hosting/deployment mechanisms will be of particular interest, as this determines if their existing resources can handle this in the future, if they will need to hire experts in those technologies, or if they might even have to hire you to do this job. This will impact the value of your business significantly.

You can also think of it another way: you will eventually need to hire someone to either take over the dev/admin job or at least help out. The second scenario will mean less training, a bigger pool of candidates and thus likely lower expenses for you.

I argue that building for the exit will result in lower long-term expenses (while it might lead to higher short-term expenses). I have been burned badly by "ah, this will be fine for now"-choices before, and this position is a result of that.

Like in the other comment, I was not aware of the DO of today, I still had their offerings from a few years back in mind when I wrote this.

I would like to add that some companies that are known to purchase software companies have many, most or all of their portfolio companies on the same host, which seems to be rooted in having negotiated non-standard contracts with those hosting companies. That, for any business that is looking at exiting this way, results in needing to be at least conscious of maybe having to move the software from one cloud provider to another.

Thank you for your performance insights. I will take a closer look at DO for future endeavors.

I do recall reading about someone having a lot of trouble with DO shutting down their business (due to same false positive in their abuse alarm system) a while back. Have there been more of these kinds of problems?

Digital Ocean is perfectly fine for most sites, you don't need multi-zone for example, the vast majority of businesses never reach that scale (including some which make a lot of money).

It is cheaper yes.

I would say it's not, and here is the reason:

Most cloud provider offerings, particularly with their orchestrated solutions like GKE and Google Cloud SQL have features like automatic backups, multi-zonal deployments, maintenance window control priced in.

I can not speak for UpLoad, but on DigitalOcean, getting these additional features set up will end up costing you more than setting stuff up yourself on the big cloud hosters.

Services like DO have started offering hosted solutions with additional features too.

So if you go by price, then they might be cheaper for the same amount of features you need now. You might be fine with that for a while, maybe even forever.

Whatever you do, make sure you use a Service that gives you all the tools you think you'll need a year from now. Moving a production system from one host to the other is quite complicated once you have customers.

Failover is handled by UpCloud. They can move to VM to different physical machines when needed, and have a 100% SLA.

As for scaling, I've done some experiments and calculations, and expect to be able to scale to 100k -1M or so users by only scaling the "hardware" (amount of RAM en number of CPU's). After that, I'll need to change the architecture. Worrying about that makes little sense now though :)

Failover is important for your data only, the other instances can just be replaced by another instance in a few minutes (you can just redeploy in a few minutes hopefully, if not, try to fix that).

For the data if you make sure you have great data backups and can failover the db (you can set up streaming replication for example), you really don't need to worry much about failover of app instances - put a couple behind a load balancer if you're worried about it (Digital Ocean offers this for example). Assets you may have to do something similar or use cloud hosting. Try to keep anything unique off your app instances so that they can be thrown away.

Scale is not really important till you have customers and even then you can't really plan well for it, just accept that you'd have to adapt a little at each new level of scale.