Thanks for the article James. Good points noted here.
I do have one concern, which I think the example you have provided may just be slightly leading down the wrong path. Ideally, a microservice from my understanding should be able to work independently. By having direct service calls within the methods, the initial goal of decoupling is not quite achieved. We are still coupling the service and a break down of product service will still cause order service to fail.
What would be your suggested approach and communication methods to tackle that problem?
My though process would be that we could continue to use the methods you have provided here, but at an async level (perhaps worker svc) which will capture the relavent data and store in the order microservice. There can then be a standard in process call to the data store in the order service. Any thoughts on that or suggestions?
I completely agree on the coupling point, and that they should be able to work independently. That's one of the main reasons I always gravitate towards an event-based communication model.
All of the best message brokers support some level of state, so if the order service publishes an event and the product service is offline the event will just wait. Once the product service is back online then the event will be processed.
Srini, unfortunately, a completely isolated microservice that works independently is a myth. Services have to communicate with each other using any available mechanism.
Think about this: get the code of your monolith and refactor in such a way where its components don't interact with each other. It is simply not possible and does not make sense. Then instead of having in-memory method calls, adding a network layer and process isolation comprise microservices.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for the article James. Good points noted here.
I do have one concern, which I think the example you have provided may just be slightly leading down the wrong path. Ideally, a microservice from my understanding should be able to work independently. By having direct service calls within the methods, the initial goal of decoupling is not quite achieved. We are still coupling the service and a break down of product service will still cause order service to fail.
What would be your suggested approach and communication methods to tackle that problem?
My though process would be that we could continue to use the methods you have provided here, but at an async level (perhaps worker svc) which will capture the relavent data and store in the order microservice. There can then be a standard in process call to the data store in the order service. Any thoughts on that or suggestions?
Thanks.
Hey Srini, thanks for the comment!
I completely agree on the coupling point, and that they should be able to work independently. That's one of the main reasons I always gravitate towards an event-based communication model.
All of the best message brokers support some level of state, so if the order service publishes an event and the product service is offline the event will just wait. Once the product service is back online then the event will be processed.
Srini, unfortunately, a completely isolated microservice that works independently is a myth. Services have to communicate with each other using any available mechanism.
Think about this: get the code of your monolith and refactor in such a way where its components don't interact with each other. It is simply not possible and does not make sense. Then instead of having in-memory method calls, adding a network layer and process isolation comprise microservices.