There are cases where it makes sense. In my own case I've splitup several parts of a "simple web application" into services. For example if a new user joins m

There are cases where it makes sense. In my own case I've splitup several parts of a "simple web application" into services. For example if a new user joins my site I want to send them a welcome email. The traditional way to do that would be to have the back-end send the mail directly. But of course sending email can block and take a while, so you really want to do it in a different process, not inside your Rails/PHP/Perl CGI process. So in this case I submit a "new.user.joined" event to a work queue. I then have a micro-service which pretty much sits idle, until it sees such an event, and then it sends the mail. I have a bunch of these little services that just listen for events that they care about, and do one specific job. If I were in ruby they could be sidekiq workers, but since I'm not I'll just call them "microservices". They can be started/stopped independently, and though they do have application knowledge (e.g. where to load email templates from) they're pretty decoupled. Perhaps I could have picked a better example, but I think it still counts!