3 ms·
Sure, but there's different levels of complexity, risk, cost, recovery with different services. And it depends on your design. If you do go with a NoSQL distrib
by throwaway20371 5y ago
Sure, but there's different levels of complexity, risk, cost, recovery with different services. And it depends on your design. If you do go with a NoSQL distributed DB, I would absolutely push the maintenance off to cloud hosting; that shit is a nightmare to do yourself. RDBMS you can totally do yourself, but if you're not really great at DBA/infra/etc and it's the lynchpin for your service, will you really do a better job than a dedicated cloud hosting team?
- toast0 5y agoHaving done some of this, I know how sometimes 'no impact' scheduled maintenances become total system outages. Having no real input into when those get scheduled and sometimes having them happen without notice sounds like a great way to have my stuff down with no control. Sure, I've got someone to blame, but that doesn't help me serve my customers. I'd rather have potentially less uptime but more control, but maybe that's me.
- throwaway20371 5y agoI completely agree that scheduling has to be controlled by the customer (you) and having more context on the change helps. In AWS I can schedule the maintenance windows, and I know if it's because it's a major version bump or a patch, and I can talk to support if I'm concerned. For me the major consideration is getting away from toil so I can spend time improving things that will move the needle. If somebody else can do a half-decent job, and there's a backup plan in case things go wrong, please somebody else do it for me!
- PeterCorless 5y agoAlso, you might want to check with your DBaaS provider if backups, upgrades or other administrative tasks can be "pause and resume." Because you never know when you'll have a burst of real-time traffic even in a projected lull time for your production systems.