> > 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."
> 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."