Software is not really random. Mostly, they all fail or none of them fail. But in case only 1 server has a problem. You'd just use a script that removes that se

Software is not really random. Mostly, they all fail or none of them fail. But in case only 1 server has a problem. You'd just use a script that removes that server from your load balancer so you can inspect it, fix it, etc.. I dont do rollbacks. If you deploy code that bugs out, you already failed. Because clearly the coders & reviewers did NOT understand the code. Proper testing helps also. And if doom day comes, just deploy a previous commit. It's pretty much the same as what u do with kubernetes. That being said. Kubernetes is indeed much easier for this. It all comes down to: "do you actually know what you are doing?". If you know what you are doing, all these problems dont happen. If you feel it's important to be able to spin up new servers from scratch every time you deploy. i guess kubernetes is great for that. it's not for me. As for being able to know what is happening, i do understand that can be impossible sometimes in large companies. Too many developers, too much code. Still, it shouldnt be used as an execuse for breaking the live servers.