I ran my B2B SaaS on a single (physical) server for the first three years or so. I then switched to a setup with three production servers, and three staging servers (in a different data center), mostly to have the comfort of a distributed database, and a staging system to try things out.
Physical servers provide enormous computing capacity these days. And managing them isn't much different from virtual servers: you should be using a tool like ansible anyway. The only difference is that when I spin up my development cluster I use terraform to generate the ansible inventory, and for physical servers the inventory is static.
I do not anticipate needing more capacity or scalability anytime within my planning horizon.
I keep seeing people investing tons of time and effort into things like Kubernetes and I honestly have no idea why. It complicates things enormously for no good reason: the benefits, if you aren't Google, aren't interesting at all, and the drawbacks are huge. The biggest drawback for me (apart from the cost of learning, building, and maintaining the infrastructure) is the complexity and resulting unpredictable failure modes.
There are things which I'd say are really important for infrastructure, though:
* a working and tested backup strategy
* disaster recovery plan (what happens when your entire datacenter burns down)
* managing servers via a tool like ansible
* regular testing of various scenarios (including setting up an entire system from scratch on new servers, with data recovery from backups)
* a database that reliably preserves all of your customers' data when any one of your servers goes down (this unfortunately excludes many databases and makes the usual "just use Postgres" a poor choice, now flame me to high heaven)
I can't imagine a small business where Kubernetes makes business sense. Do people seriously have problems with scaling to hundreds of machines? Scalability problems with huge traffic peaks that actually cause server load? I'm having trouble keeping my CPUs busy for any meaningful amount of time, and I don't spend much time on optimizations, I just avoid doing stupid things.
> a database that reliably preserves all of your customers' data when any one of your servers goes down (this unfortunately excludes many databases and makes the usual "just use Postgres" a poor choice, now flame me to high heaven)
You mean as in, backups have the latest data? Every transactional DB does that, postgres included. You just have to back-up the correct data (what is on the docs, for every one of them).
If you mean any DB server can go down at any time and the others must take over without losing any data, then your best bet is to hire a postgres expert to set it up for you. Both Oracle and SQL Server nominally do that, but they have flaws that their experts can't correct, and you won't be able to set any of them up without acquiring some expertise first.
> * a database that reliably preserves all of your customers' data when any one of your servers goes down (this unfortunately excludes many databases and makes the usual "just use Postgres" a poor choice, now flame me to high heaven)
What do you suggest instead? My understanding was that Postgres, when properly set up with backups and replication, is the most reliable open-source database.
Physical servers provide enormous computing capacity these days. And managing them isn't much different from virtual servers: you should be using a tool like ansible anyway. The only difference is that when I spin up my development cluster I use terraform to generate the ansible inventory, and for physical servers the inventory is static.
I do not anticipate needing more capacity or scalability anytime within my planning horizon.
I keep seeing people investing tons of time and effort into things like Kubernetes and I honestly have no idea why. It complicates things enormously for no good reason: the benefits, if you aren't Google, aren't interesting at all, and the drawbacks are huge. The biggest drawback for me (apart from the cost of learning, building, and maintaining the infrastructure) is the complexity and resulting unpredictable failure modes.
There are things which I'd say are really important for infrastructure, though:
* a working and tested backup strategy
* disaster recovery plan (what happens when your entire datacenter burns down)
* managing servers via a tool like ansible
* regular testing of various scenarios (including setting up an entire system from scratch on new servers, with data recovery from backups)
* a database that reliably preserves all of your customers' data when any one of your servers goes down (this unfortunately excludes many databases and makes the usual "just use Postgres" a poor choice, now flame me to high heaven)
I can't imagine a small business where Kubernetes makes business sense. Do people seriously have problems with scaling to hundreds of machines? Scalability problems with huge traffic peaks that actually cause server load? I'm having trouble keeping my CPUs busy for any meaningful amount of time, and I don't spend much time on optimizations, I just avoid doing stupid things.