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 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 efforts in terms av development to adapt our Microservices to use the Message Broker and go for a Publish/Subscribe communication pattern after two years?
What is the good approach? Should we use something like Akka.NET already now without having a Message Broker? Our should we implment Akka.net later to make the Microservices use pub/sub communication pattern?
Thanks and appriciate all kind 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.