7

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.

Improve this question
3
  • why the downvote? :)
    – gries
    Commented Apr 19, 2017 at 7:05
  • The question I have is: do you have a choice? If the services to which you must communicate are still located inside the monolith,and for some reason you can't extract them at this time, the question of whether or not this is a good practice is irrelevant - it must be done.
    – HiredMind
    Commented Apr 20, 2017 at 14:05
  • 1
    Hi thanks for the clarification. I don't think it's irrelevant, that's why I'm asking for bad practices and not hard limits. Of course it has to be done, but if this creates a larger amount of technical dept it can influence the decision to extract related services earlier to avoid this technical dept that accumulates.
    – gries
    Commented Apr 21, 2017 at 8:00

2 Answers 2

Reset to default
12

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.

Improve this answer
1
  • great explanation thx
    – gries
    Commented Apr 18, 2017 at 12:56
1

I don't think this is a problem so long as all parties agree this is a means to an end.

The temptation of course is to refactor beyond moving the logic out of the layer. Be aware that any such refactoring could make testing the two code bases in parallel that much harder.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.