The only application that I encountered that fit the microservice idiom well (obviously, in my opinion) was postfix (some diagrams at http://www.postfix.org/OVERVIEW.html). Note it is usually using unix pipes for communication instead of networking, so some of the complaints about the networking disappear.
Even there, the "clear" separation of concerns means that it becomes difficult to do some things that seem like straightforward business goals. You'd like to bounce emails to a user's aliases if they are over quota but allow messages to that user from support. Unfortunately the milter and the alias resolution hooks are different services and don't get to communicate, unless you use some other functionality... I'm a bit hazy on the specifics, but I can remember needing to bend over backwards sometimes to satisfy things because you couldn't chain additional information through. This ordinarily comes up quite a bit when people compare it to exim, an SMTP monolith where you are more easily able to use information from one service in another.
I think postfix is well built, but the architectural choice has consequences and it isn't a silver bullet.
Even there, the "clear" separation of concerns means that it becomes difficult to do some things that seem like straightforward business goals. You'd like to bounce emails to a user's aliases if they are over quota but allow messages to that user from support. Unfortunately the milter and the alias resolution hooks are different services and don't get to communicate, unless you use some other functionality... I'm a bit hazy on the specifics, but I can remember needing to bend over backwards sometimes to satisfy things because you couldn't chain additional information through. This ordinarily comes up quite a bit when people compare it to exim, an SMTP monolith where you are more easily able to use information from one service in another.
I think postfix is well built, but the architectural choice has consequences and it isn't a silver bullet.