News for hackers. Stuff that matters.
Re:Docker in Production: A History of Failure (2016) by crummybowley on Tuesday July 27, 2021 @01:33PM (#27975148)
The issue is not docker, the issue is you treat your servers like pets.

Folks need to start building systems that destroy all and re-image fresh. Any other way you are just setting your self up for failure.

Re:Docker in Production: A History of Failure (2016) by abraxas on Tuesday July 27, 2021 @07:11PM (#27978714)
And at the heart of this there will be a database or some other data store that will be very much a pet. A very precious, important and fickle pet. Even if it's "serverless" it will have its own needs and wants.

This whole "cattle not pets" charade gets on my nerves. Yeah, it's easy to "scale" that which is stateless. Not so fast with stateful. I don't care that I can spin up gazillions of web server instances. My data store is still one and very much stateful.

Re:Docker in Production: A History of Failure (2016) by sureglymop on Tuesday July 27, 2021 @09:49PM (#27979579)
I think stateless is good but don't forget that the state is just in another place, another stateful "gear" in your machine. And that, as you said, has to be treated like the pet it is.
Re:Docker in Production: A History of Failure (2016) by tene on Wednesday July 28, 2021 @11:45AM (#27985164)
Persistent identity is fine, it just doesn't belong on individual servers. If the data matters, then it's better for it to be reproducibly managed, durably persisted, etc.

For many database needs, there are great options that natively support a highly available cluster.

For those needs that don't have a good clustering option, there are great network storage systems that are easy to deploy and use.

You don't need to treat hardware as a pet to have a database with persistent identity.

Re:Docker in Production: A History of Failure (2016) by crummybowley on Tuesday July 27, 2021 @10:06PM (#27979656)
Even so, the topic is docker. Your storage is else where in docker -- not in docker. If it is in docker, then you are already in trouble.

Simple solution is storage is a secondary drive/partition -- still automate OS install.