The distinction of stateful and stateless is one of the main criteria how we're dividing responsibilities between platform-infra and development.

I know it's a bit untrue, but you can't do that many things wrong with a stateless application running in a container. And often the answer is "kill it and deploy it again". As long as you don't shred your dataset with a bad migration or some bad database code, most bad things at this level can be fixed in a few minutes with a few redeployments.

I'm fine having a larger amount of people with a varying degree of experience, time for this, care and diligence working here.

With a persistence like a database or a file store, you need some degree of experience of what you have to do around the system so it doesn't become a business risk. Put plainly, a database could be a massive business risk even if it is working perfectly... because no one set backups up.

That's why our storages are run by dedicated people who have been doing this for years and years. A bad database loss easily sinks ships.

▲

mrkeen 5 days ago | parent [-]

> but you can't do that many things wrong with a stateless application running in a container

> As long as you don't shred your dataset with a bad migration or some bad database code, most bad things at this level can be fixed in a few minutes with a few redeployments.

At some point between these statements you switched from stateless to stateful and I can't follow the rest of the argument.

	▲	tetha 5 days ago \| parent [-]
		If you mess up your application code in a stateless container, that's boring. Roll code back, and you're back where you want to be. This is stateless and easy. If you introduce a migration like "UPDATE billing SET prices = 0 ; WHERE something < 5", that's an entirely valid migration, but you mess up your state and then everyone is in a world of pain. This could, however, still be caught by various code review strategies, incremental rollouts and a large number of good development practices. This is still easy, you can catch it before it hits prod so you don't have to fix prod. And prod could still be fixed if your database layer manages backups, just with a day or two of downtime. If you don't have backups, you may have permanently lost information, which could kill the company.