>Is it, though? There's more complexity due to more moving parts, sure. But being able to solve issues by just issuing a "scale" kubernetes command in the CLI is priceless. As is killing pods with no drama.

On the contrary, getting to the place where you can issue commands over k8s on a project not specifically designed for it has a very real and very significant cost. Companies are killing themselves trying to do this for no good reason.

Need a new node? Fire up whatever it is that you fire up: Ansible, Chef, AMI, bundle of custom bash scripts, whatever. No need for the massive complexity of k8s.

Specifically, what benefits are you seeing from k8s (i.e., what unique utility does the "scale" or "delete pod" command bring that is not reasonably resolved by less complex solutions)? It's just causing me a lot of frustration right now. I can see Google's need for it. Not having much luck seeing its use in non-Google-scale businesses.

If you're doing a from-scratch thing that you can architect around k8s and think that's more convenient than more traditional approaches and can accept its currently-quite-serious limitations, that's whatever. If you're talking about some tangible objective benefit that most companies need to be able to enjoy here, please do elaborate.

> > Avoid microservices where possible, the operational cost considering devops is just immense

> Is it, though? There's more complexity due to more moving parts, sure. But being able to solve issues by just issuing a "scale" kubernetes command in the CLI is priceless. As is killing pods with no drama.

> However, what are we talking about here? Small business ecommerce? Your monolithic app is probably going to work just fine.

Maybe I just haven't seen enough projects, but every significant criticism of microservices I've seen assumes that "microservices" effectively means "each team does their own thing in a way that greatly increases complexity and maintenance costs of our monolith app."

Of course it's not going to pay off if you're maintaining all your own hardware / servers and each team is using their own stacks, languages, and frameworks... especially if they're all bottle-necked to the same database instance anyway. That's basically magnifying the potential downsides and minimizing the benefits.

Our industry definitely has some "use the new stuff because it's cooler" sentiment, but I think we also have another distinct mentality that shows up a lot.

> "I'm most familiar with hammers. We tried a cordless drill once a few years ago but its battery died and we had to wait for it to charge! The hammer still worked, though. So we stick to hammers and I recommend others stay away from drills."