When to create more microservices rather than inner functions

Question

I'm trying to architect (breakdown) one application we have at my work in a few microservices. Before starting going down to the rabbit hole, I wanted to ask: when is a good idea to create another model+function instead of creating a microservice?

Creating a microservice involves more work than just a few other functions. Especially if that involves some duplication of data. I saw this question/answer that was really great: How do you handle shared concepts in a microservice architecture?

It helped me a lot to start sketching my macroapplication. But I still cannot solve this one; for example, I have multiple resources which have 1) different types and 2) different attributes for the types. This is a many-to-many relationship.

Example

# ResourceType_Attribute table
| ID | type_id | attribute_id |
|----|---------|--------------|
|  1 |       1 |            1 |
|  2 |       2 |            1 |
|  3 |       2 |            2 |

And we would have a table for type and attribute in the same microservice. But now I want to create a cost calculator of the resource (a function) or a billing service (another microservice). Is it possible to create a new microservice without a big burden?

If I create a cost calculator I'd have to create a new table within the resource manager:

# Cost calculator table
| ID | type_id | attribute_id | unit_cost |
|----|---------|--------------|-----------|
|  1 |       1 |            1 |         10|
|  2 |       2 |            1 |          1|
|  3 |       2 |            2 |          4|

Supposedly now that we have a resource of type_id 2 that has a value of 10 for attribute_id 1 and value of 10 for attribute_id 2. That makes the cost calculation: 10*$10 + 10*$4 = $140.

Having a model+function within the resource manager to handle this problem makes it easier to make changes in the unit_cost column. Since I know what is in attribute_id and in type_id.

On the other hand, if I have a whole new microservice for this table, I won't know what prices I'm updating without consulting the attribute and type tables. I will only have their ids and I have to go to the other database to check what is going on where.

Am I understand the concept of this? If not, please help me to clarify this issue. Thanks a lot!

Answer 1

Microservices boundaries are typically domain boundaries.

So if you have two methods, both of them would conceptually access same back-end data structure, but each would serve a different business domain, then they fall under different microservices.

For example, you might have some attendance tracking method and another method used to calculate payroll based on attendance. The first is used mainly for auditing purposes, to ensure we track who was in office when, while the other one is used to calculate working hours of an employee.

Despite the fact that both of them would access same data (time in and time out) one would fall under audit microservice, while the other fall under payroll microservice.

Reference: Building Microservice, Designing Fine-Grained Systems By Sam Newman

Answer 2

Microservices are part of the solution to scalability problems. Think of microservices as employees who can process different tasks. So, if you have more budget calculations to perform, you can just add more employees and give predefined manuals to do specific tasks.

Implementing microservices has a cost, and advantages. The decision is up to you, considering this benefit/cost rate. Of course, the benefits are not applicable to all cases. You will not solve your emotional problems by delegating actions to more employees.

The cost is that the implementation is complex: you need to be sure that employees can work independently and in coordination. So, you will need to develop more manuals and put more employees to do such task. But if you succeed, you will be able to perform more sales, for example. Basically, you are adding more queues to a process of sales: more desks accepting commands from clients, more desks accepting boxes from packagers, more desks accepting boxes and delivering them.

In your specific case, I don't clearly see how the microservices architecture would help. The problems you address are programmatic, not architectural. If you want to build a "resource manager", as you call it, think of the manual (or manuals) to write for each additional employee to perform such task. If you can create a procedure that can handle the process without affecting the database integrity, and without dependencies between employees using the same manual, you're OK. For example, you can add a (micro)service with new employees that perform atomic calculations (each one calculates one item), and another of employees that just sum values. I would personally not do that, since employees on the second line of desks will create dependencies on results of the first line (e.g. a sum cannot be performed until receiving all calculations, so if one calculator employee has a problem, a group of people will be waiting around a summation desk until he arrives, and if he doesn't, all such pending processes will require handling).

As said, I think you don't need microservices to address this problem, but can't be sure, since I don't know the exact issues here. If I would be learning, I personally would code both, to experience the differences.