I'm planning out a microservice adoption for a rather big monolith.The current plan is to create new features using microservices and constantly extracting features from the monolith into services.During that process is it problematic to let microservices talk to the old monolith?For example, A new Product is developed but the Cart Service is still located inside the monolith, so the new microservice has to call the monolith in order to add items and remove them.Does anybody have experience with this kind of problems?Is this generally considered a bad practice and why?Is it better to just go through the pain and only migrate services that can run independently of the monolith?Note:I'm generally aware that to much chatter between the services is considered bad, but in some cases, it's still required.
Should Micro services talk to the monolith that they where extracted from?
architecture;microservices
If you split a monolith into microservices, then those microservices will need to talk to each other to obtain the result you requested (instead of one monolith doing all, you have communicating services doing the same). Sure, they should not be too chatty, but they still need to communicate with each other when needed.If the part you need to communicate with is still in the monolith then there is no problem talking to the monolith. You are work in progress at this point, you have still to split the Cart service (or whatever it is) from the monolith. Besides, a service does not care it talks to another service or the monolith, it just talks to another party.Just make sure the services you have extracted so far (and will extract next) are self-contained, independent, cohesive, loosely coupled, and split on a business boundary (i.e. you have split a functionality from the monolith, and not just code), otherwise you will have worse issues than that of talking to the monolith.