[jakuboboza]

This feels very not-reusable to me. Guys has an idea that protocol buffers are the way to go. Cool but in many cases you really want to put a queue in front of things like email sending etc. And if you make email microservice that can't handle attachment it again isnt reusable.

I would be more in favour of having option to point every service at a rabbitmq queue to listen on and have a format of message that containes the delivery report queue to use when email is sent to notify rest of the system.

And here we come to conclusion, everyone has his own idea. This is who it is hard to make really good reusable micro services unless each of them becomes not so micro.

Nice that people try but i'm still in the camp of building from lego bricks provided in libs and creating my own microservices in a way I see them interconnect fit for given project. It might be protobuf, http or qeueue systems.

[Cthulhu_]

That's the vibe I was getting; these all feel like focused libraries, but using these in an application architecture feels like you would have a distributed monolith. You need resilient task queues to turn it into a 'proper' microservices architecture, which is honestly a much more challenging task than encapsulating concerns like sending emails or geocoding.

The other thing, as another commenter pointed out, is that these are nanoservices; I find it really difficult to imagine a situation where you would ever need 10x of one service for 1x of another, for example. It's a litmus test for microservices: do they have to scale independently.

A lot of these just interface with an external service doing the heavy lifting, so the performance requirements for each of these is low; little to no value in running them on separate, independently scalable VMs.