Messaging in a micro-service architecture [closed]

Question

I'm beginning to investigate service-oriented architectures and wonder how best to structure the messaging between processes. It seems that direct HTTP calls between services and/or a pubsub bus are two common approaches. In what sorts of situations is one more favorable than the other? I can see how pubsub would lead to more decoupled services but I also get the impression that it becomes much harder to track a message's path though the system.

What are some resources for learning more about this? I'm particularly curious about this in the context of very small, "hand-rolled" services (i.e. Ruby/Sinatra, Node/Express, Redis pubsub, etc.) as opposed to any of the prescribed SOA stacks/suites out there...though I'm sure the same principles apply.

Thanks!

Answer 1

I'll give you my two cents.

but I also get the impression that it becomes much harder to track a message's path though the system.

You're right that pubsub SOA architectures AKA (SOA 2.0) providing a great deal of decoupling, but you also pay a price, because this is exactly what happens, although tools like splunk can help a lot.

seems that direct HTTP calls between services and/or a pubsub bus are two common approaches

Actually if you look at the most used .net event soa frameworks (NServiceBus, Mule and MassTransit) they don't use http calls, but yes you can implement a microservices architecture and use http as the communication protocol.

I understand you want to start applying some of the best enterprise architecture concepts but I would say that you better off starting with simpler, yet stronger foundations. There is no point in you jumping to event soa, without knowing if you really need it. If I was starting a new system and wanted to make sure that I was properly adapting DDD and SOA principles, I would start by identifying the services for my domain. So say you have 3 services, you could start by declaring the public contracts for each of those services, you don't need anything special, you can start with WCF/ASP.NET Web API with a sync REST API. You would then make sure that each service would get its own database, because you're aiming for low coupling, and you could then create an API layer (the one visible to the outside world) again using WCF/ASP.NET Web API, because your microservices should not be exposed directly to the outside world. So at this point you would have a SOA like, yet simple in design, architecture, but because you would have well defined contracts, you could well extend your services by adding async capabilities to them and for that you would start by adding a message queue to each of the services. You know, you don't need to start with a complex system, start with something basic, well defined, which allows you to scale if you have to.

The system I described could be extended to support events easily if you wanted to, and the fact that you would at this point have already sync messages would not stop you from adding asyn messages to the system as well.

But these are just my two cents.