We are trying to implement Microservice Architecture creating our new applications in our current environment using Asp.NET Core. The first generation of our Microservices will use a Request/Reply communication pattern and there is no need for any Message Broker. However, we are going to have a Message Broker after 2 years.
Will it take much effort in terms of development to adapt our Microservices to use the Message Broker and go for a Publish/Subscribe communication pattern after two years?
What do you think is the best approach? Should we use something like Akka.NET already now without having a Message Broker? Should we implement Akka.net later to make the Microservices use a pub/sub communication pattern?
Thanks and I appreciate all kinds of advice.
Take it right from start. The major purpose of microservices is loosely coupled services. you may not realize initially but at some point you may need it. technically req/resp is refactored monolithic. using event driven architecture with message broker is little more complex but the benefits are far reaching. imagine you have more and more microservices joining the club it be very easy with pub sub.
coming back to your second point it could be significant effort to refactor and include message broker later. e.g. you decide to go for CQRS and event sourcing which is very common patterns for distributed applications. you would require major re architect of your system. but for simple applications these patterns may not be required and depending on your business need you have to decide how resilient, available and decoupled your services should be and will it be worth the effort when requirements could be met simply.
If you want to go for truly microservices architecture then it starts with async communication that is possible with message broker.
Hope that helps.