> Remember, Kubernetes exists to make scaling and redundancy easier, but it’s only easier if you fully understand the implications of every configuration that y

> Remember, Kubernetes exists to make scaling and redundancy easier, but it’s only easier if you fully understand the implications of every configuration that you make. It exists to make it easier. Did anyone ask if it’s something you needed to be doing in the first place? For many, I think using kubernetes is like buying something you don’t need at the store because it’s on sale and thinking it’s saving you money. I think we all have a desire to build out infinitely scalable and 100% reliable solutions because _obviously_ the site can’t go offline. But did you ever actually ask what would happen if it did? I worked with one company that, about 8 years into their existence, botched a data migration and went down for an entire month. Customers called CS every day begging them to fix it, they refunded everyone’s fees for the month, and… not one customer cancelled. That company is still around, still growing strong, and still growing. I’m not suggesting going to the other extreme but… if your site goes down for a few hours overnight until you wake up and fix it, for most projects it’s not going to be the end of things. Hell, GitLab is still around! (On that note… Take _durability_ seriously. Have backups. rclone everything you have into b2 or something. Even if it takes you a few days to restore the entire service, at least it will come back. If you lose everyone’s data _then_ you’re probably done.)