When you're 1 man show (or tiny team) working on some web oriented application beyond POC level and beyond heroku (for whatever reason) — managing your CI, deployments/rollbacks, DBs etc. looks like a nightmare to me.
Just properly setting up and maintaining a small k8s cluster looks almost like a fulltime job.
I wonder how do your CI, deployment workflows look like?
Any particular tools, practices, guidelines, architecture patterns to reduce pain & timewaste?
How do you CI => deploy/rollback stateless instances?
How do you manage your DBs and backups?
k8s, ci, etc are all really useful and solve a lot of hard problems, but god are they a bitch to set up and then monitor, fix when something weird happens, secure from nasty people outside, patch when some update becomes necessary, resist the urge to “improve”, etc. This doesn’t include the time it takes to work these tools into your project, like k8s for example really requires you grok its model of how stuff it runs is supposed to look. There’s a reason entire companies exist that simply offer managed versions of these services!
If you’re using fewer than like 10 boxes and don’t work with many people, you can get away with spooky arcane oldhat sysadmin deploy techniques (scp release to prod hosts, run deploy script, service or cron to keep running) and honestly it’s pretty fun to just run a command and poof you’re deployed. Then you can just wait until it starts making sense to use fancier tooling (more load, more sites/DCs, more services, more people/teams, etc). Monitoring is always good to start with, for other stuff a good litmus test is that price points for hosted k8s & ops stuff will start to make sense, you’ll be paying in time in any case. Who knows, maybe when that happens something new will pop up that makes even more sense. Until then, reducing the amount of stuff you need to worry about is always a good strategy.