[rco8786]

Yes! I call them “modular monoliths” and fight tooth and nail to get people to stop introducing network when it doesn’t need to be there.

I want to make people do Bart Simpson style writing on the chalkboard “Microservices don’t make things easier” 200 times

[adra]

When you're releasing changes daily, a dozen groups are all touching the same code, and all of a sudden one of those ten changes kill the application with OOMs galore, your ops people are going to have a bad day. Oh some minor component written by a newer dev added a non-reversible DB migration in that same push? You're having a very bad day(s). Microservices are not the panacea that will work for all organizations/products/workflows, but damn do they do amazing things for others. Running a platform with dozens of teams with loose organization, distributed timezones, conflicting priorities abound, it's nice to not worry about other teams poofing our perfectly happy chunk of the company from doing it's thing.

[sroussey]

Yes, but these services need not be “micro”.

If someone twist my arm and off and convinces me to do some consulting, I’ve seen thousands of services started by individual developers, where there is no accounting, so the ops people don’t know what needs to be kept up or what can be shut down.

Definitely separate regulatory differences (marketing vs credit card processing for example). Generally, separate out high velocity code changes from slow velocity code if possible.

I wouldn’t get in the habit of database migrations having anything to do with code pushes. Unless you have no users, I guess. Yikes. So much to say on that topic alone.

[rco8786]

There are plenty of genuinely good reasons to split up monoliths. I’m not attempting to say that all SOA is bad.

What I am saying is that companies who break apart monoliths as a code organization tool are making a very bad decision. They’re getting all the downsides and none of the upsides of microservices.

[treis]

I do agree that at some point it breaks down. But dozens of teams probably should be split for organizational reasons anyways so splitting up tech isn't much more overhead.

[rco8786]

> splitting up tech isn't much more overhead.

This is the fallacy. Splitting up tech has huge overhead.

There’s lots of good reasons to do it. But “operational efficiency” is not one of them, even though it’s oft cited as one.