4 ms·
You would not get redundancy or scale and you would need to do offsite backups yourself which is why it's not recommended over cloud DBs. Building stateless co
by aleem 10y ago
You would not get redundancy or scale and you would need to do offsite backups yourself which is why it's not recommended over cloud DBs.
Building stateless containers is good practice.
There will always be exceptions but it's good to know the tradeoffs before making those exceptions.
- tokenizerrr 10y agoRight, and third party software is a thing. There are also plenty of reasons to prefer the simplicity of SQLite even if that means you have the task of managing your own backups.
- vidarh 10y agoThere are plenty of reasons to prefer that simplicity if you intend to write software meant to run on a single computer. The moment you want to deploy a service, unless the data is "mostly static" (e.g. something you might update offline and ship copies of), the simplicity that makes things like Sqlite great often ends up creating complexity.
- tokenizerrr 10y agoNot everything needs to be highly available. Using docker does not mean that you are using it in a highly available environment. Plenty of things I run in docker containers can be down for a few hours every night to run backups.
- ngrilly 10y agoYes, I'm aware stateful services need redundancy, scaling and backups. That's exactly my point. 12 Factors only address stateless processes, which is the easy part. But most applications are stateful. It doesn't matter if data are stored in an embedded database (like SQLite, LevelDB, BoltDB) or in a client-server database (like PostgreSQL, MySQL, MongoDB, RabbitMQ, Redis). 12 Factors doesn't address this issue at all.
- icebraining 10y agoThe point of 12 Factors is to isolate the application from the data store, making it easy to manage and upgrade the former. That's important because they recognize applications are stateful. But yes, 12 Factors doesn't purport to guide people on how to manage the stateful part.