Microservice Decomposition

[Udit Panchal]

Hi, 

I am reading different posts and books on Microservice Architecture in the hunt to answer my question which is related to the Decomposition Strategies. The question is, should we create a new microservice specifically to handle the batch job? The batch job is suppose to read the data from the database and make REST calls to external system. 

[Peter]

hi Udit,

Decomposition is quite difficult I find as well.

In general if you have an alternative system, middleware or something that you can use for running the job it could save you some time until you have better understanding of what service the job should belong to.

If you are able to, perhaps sharing some more insights could help giving a less generic answer.

Cheers,

Peter

[Chris Richardson]

A few generic thoughts related to coupling.

The batch job (e.g. calculate monthly cell phone bill)  is likely to share business logic with the non-batch service (e.g. Billing Service for view bills online), which suggests that it belongs together in the same service.

On the other hand, the non-functional requirements are quite different than, say, a service that implements a REST API, which suggests that it should be deployed/scaled separately.

If you split, I'd have both services owned by the same team (e,g, Billing Team) since two teams working on the same business logic risks having two tightly coupled teams.

I hope this helps.

On Mon, May 11, 2020 at 8:40 AM Udit Panchal <pancha...@gmail.com> wrote:

Hi, 

I am reading different posts and books on Microservice Architecture in the hunt to answer my question which is related to the Decomposition Strategies. The question is, should we create a new microservice specifically to handle the batch job? The batch job is suppose to read the data from the database and make REST calls to external system. 

--
You received this message because you are subscribed to the Google Groups "microservices" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microservice...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/7874fd2d-868a-43c7-a5a7-d4d5210c6611%40googlegroups.com.

--

Learn microservices - http://learn.microservices.io

Microservices application platform http://eventuate.io

Consulting and training http://chrisrichardson.net

[Udit Panchal]

Hi Chris, 

Thanks for the reply. I understand and it makes sense when we think from domain perspective as you said that calculation for next billing cycle should be alongside the same service which handles the other billing domain capabilities. However, my doubt is should any technical factor drive the decomposition of the microservice. 

Continuing on the same example, let's say you have 100K customers and each have their own billing cycle period like weekly, bi-weekly or monthly. Due to such varied billing cycle, the bill generation can run any single day. Considering this frequency, can we decide on that this business capability be a different micro service? Assume that bill generation logic just reads the data from database and sums up the amount for all the subscriptions customer has. 

On Monday, May 11, 2020 at 1:32:49 PM UTC-4, Chris Richardson wrote:

A few generic thoughts related to coupling.

The batch job (e.g. calculate monthly cell phone bill)  is likely to share business logic with the non-batch service (e.g. Billing Service for view bills online), which suggests that it belongs together in the same service.

On the other hand, the non-functional requirements are quite different than, say, a service that implements a REST API, which suggests that it should be deployed/scaled separately.

If you split, I'd have both services owned by the same team (e,g, Billing Team) since two teams working on the same business logic risks having two tightly coupled teams.

I hope this helps.

On Mon, May 11, 2020 at 8:40 AM Udit Panchal <panch...@gmail.com> wrote:

Hi, 

I am reading different posts and books on Microservice Architecture in the hunt to answer my question which is related to the Decomposition Strategies. The question is, should we create a new microservice specifically to handle the batch job? The batch job is suppose to read the data from the database and make REST calls to external system. 

--
You received this message because you are subscribed to the Google Groups "microservices" group.

To unsubscribe from this group and stop receiving emails from it, send an email to micros...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microservices/7874fd2d-868a-43c7-a5a7-d4d5210c6611%40googlegroups.com.

[Chris Richardson]

On Mon, May 11, 2020 at 1:29 PM Udit Panchal <pancha...@gmail.com> wrote:

Hi Chris, 

Thanks for the reply. I understand and it makes sense when we think from domain perspective as you said that calculation for next billing cycle should be alongside the same service which handles the other billing domain capabilities. However, my doubt is should any technical factor drive the decomposition of the microservice. 

A couple of things. Sometimes, for example, you might want to scale readers more than writers.

However, it could be the same service deployment (container image) - perhaps it just runs in a different mode - not handling HTTP requests or messages - and instead simply implements queries.

 

Where it gets a bit tricky is when, for example, you want to implement a batch job using different technology: e.g. map/reduce, Spark. There you have code running in a different architecture that is accessing the same DB and, more conceptually, shares concepts with the rest of the billing service.

Continuing on the same example, let's say you have 100K customers and each have their own billing cycle period like weekly, bi-weekly or monthly. Due to such varied billing cycle, the bill generation can run any single day. Considering this frequency, can we decide on that this business capability be a different micro service? Assume that bill generation logic just reads the data from database and sums up the amount for all the subscriptions customer has. 

Not sure whether frequency changes the decomposition decision.

Chris