Programming

Maybe it's because my career has been based around microservices for the past few years, but I don't think the need for microservices is as narrow as many folks think. At least within a large company it's as much about segregating lines of concern and responsibility as it is about speed and efficiency. It's a lot easier and cheaper to spin up new hardware than it is to manage and coordinate all the varied interests in a monolith.

You point out the problems of a monolith that has grown beyond the ability to effectively manage it, but every application only grows (until it is replaced). I think we are in agreement other than you minimize the usefulness more than I would.

My experience is every monolith either grows until it is so full of tech debt that it can't be maintained effectively any more, or it gets cloned over and over with minor variations and you wind up with huge messes of rewriting the same code over and over necessitating a massive development undertaking when a new business need comes along - and then the whole shebang gets shit-canned to be replaced by a new product.

Properly architected microservices segregate concerns and make huge efforts easier to do in small units and often simultaneously. It doesn't have to be this way. It's fair to say that only is a problem with poorly architected monoliths, but my experience is bad architecture always creeps in or is never fixed because it works well enough for now. The forced segregation is inefficient, and frustrating as hell for juniors, but at the project management level it's a huge boon.

Just my perspective after twenty five years. But as I say, I'm heavily invested in microservices and don't claim to be unbiased. Monoliths have their place, but I think businesses that are serious about their software need microservices.