Story 2: Call it microservices…or distributed modules?

Story 2: Call it microservices…or distributed modules?

It has been a long time since microservices were introduced to the world. They had their ups – yeah, let’s use it everywhere – and downs – whaaat, modular monolith only. But that is not what this story will be about.

I would like to discuss whether the majority of projects based on microservices are actually based on them or something else. Something else? – you might ask. Do we really understand what they should be? Do not misunderstand me, I might be completely wrong but I have started to wonder and it has been bothering me.

Let’s take a look at one of the most popular examples from online tutorials and articles, which is an e-commerce related domain. It can be built out of the following domains (I do not want to focus in this article on core, sub, and generic ones – that’s why I just call it domains):

After deep analysis of requirements, potential traffic, security, fault tolerance, and many more it turned out that the application at the beginning will be small but has a very high potential for growth. The development team decided to follow the modular monolith – quite a smart decision at this point. Modules were created for each domain that was discovered:

So, there is e.g. Orders or Invoices module. After the first release, everything works as it should. However, after some time in production, the team noticed that:
– the Invoices module needed better scalability
– there are a lot of code changes in the Delivery module
– the Complaints module has a lot of errors that bring the entire application down

What usually happens is that the Invoices, Delivery, and Complaints modules are extracted to separate services. Each of them, of course, has its own database. The ecosystem becomes distributed:

And here we come to the point. Based on your experience – in how many cases would each separate service be called a microservice? Another question – if so, is it really a microservice? I used to like the definition – Not bigger than bounded context, not smaller than aggregate. But in practice (and my opinion), bounded context is usually too big to fit the microservice.

Let’s take the first module – Invoices. It might:
– generate a new invoice when the order is made
– generate a correction invoice when the first one is incorrect
– merge several invoices into a single one
– export the invoice to PDF
– export the invoice to DOC
– export the invoice to PNG
– do many more

A pretty big responsibility, don’t you think? If so, should it really be called a microservice? Micro means something very small. Here, we deal with the entire module. So, what would be the microservice in this example?

Let’s assume that we as a team face a very poor performance on the export of invoices. After analysis, we can see that there is a lot of traffic and scaling can help us with this problem. What do we do? We subject our Invoices module to further granulation and extract InvoicesExport service:

Looking at the responsibility of the new module, you can say that it is very small. It has its own, single responsibility – export of invoices. Yes, in the case of code volatility or high usage of PDF exports, it can be further split into other services but in our example, I assume it is used as much as other export types.

I can imagine that the Invoices module sends a message about the need for PDF invoice generation. It is then consumed by one of the instances of InvoicesExport service and the invoice is generated. Further, the Notifications module takes this information and sends the email with the invoice to the buyer. In case of failure of the service, messages wait to be consumed later (or by the other instance) and the invoice is sent anyway.

Can I call the InvoicesExport a microservice? Yes, I can!

The above example shows that the term microservices can often be misused, especially when we translate an entire domain into such a service. I think this causes quite a bit of confusion and leads to situations where entire ecosystems are referred to as microservices, when in fact they are.

Maybe I’m exaggerating and it is not that important. But maybe it is time to think about another name for services like Invoices, Delivery, and Complaints? I personally like the term distributed modules.

And you, what do you think about all this?

2 responses to “Story 2: Call it microservices…or distributed modules?”

  1. Hmm. In my opinion, you have right. But treating subdomain like microservice is wrong. Domain/subdmain they are only some model of reality. This model(subdomain) we could implement like one bounded contexts And for me, that is right but happens in probably only in cinema xD. Subdomain still can be a complex model of reality. And we should focus on finding bounded contexts inside subdomain (like in your example). Invoices subdomain have more than one bounded contexts. Of course, that is only my small opinion…

    Like

    • Exactly, this is the problem described in the above article. When you look at both: production applications and tutorials, there are so many examples when the domain/subdomain is treated as a microservice. But they are not micro – there is a low chance that domain/subdomain will be covered by one, small bounded context 🙂

      Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: