[tdeck]

Microservices are a solution to an organizational challenge: how do we set clear boundaries of ownership within a complex system? From a technical perspective there are pros and cons.

Unfortunately, I don't see a wealth of other ready-made practices for companies to copy when they grow and need to solve this problem. I once worked on an enormous Rails monolith that was very well organized and had layered on several additional patterns to improve modularity and maintainability. Still, a SEV in a minor product area could (and did) bring down the whole system, and they were in the process of dismantling it.

[drewcoo]

Actually, loosely-coupled microservices improve testability, too. And improve it by far if we're comparing with monoliths (where tight coupling is considered a "feature").

One of the troubling practices is tightly-coupled containerized services, though, which only gives us all of the problems of microservices at the same time as we have all of the problems of monoliths.

[sisve]

A microservice architecture is a good way to solve the problem with the monolith. The problem is the word mikro. It should have a better name. If it was called "boundary architecture" or similar it would make people stop creating to small pieces. One team should not manage 15 services.

[jamesfinlayson]

This - I worked with a guy that had been to a conference where someone from Atlassian said that S3 was made up of over 500 microservices, so this guy made it has mission to create as many microservices as possible in a 100 person company.

[tdeck]

I agree, the precise granularity of "micro" isn't well-defined and I've seen teams (usually ones without prior practical experience) try to implement an "every database table is a new service" approach that ends up being ridiculous. I suppose the term Service Oriented Architecture avoids this problem, but it sounds a little too "Oracle enterprise" for my taste.