CODEWITHSUNDEEP
design-patternsmicroservices
BAMF4bacon
BAMF4bacon

Reputation: 593

Microservices and Coupling - competing design principles

So coupling is a hot topic with microservices, and I have not been able to find specific advice beyond top level design concepts.

I have a service that integrates data from multiple data sources. A key function is associating the data. And now the code is being migrated to a platform with microservices.

So I have one service right now that provides

So if the App A restarts, all associations are lost and we start over.

Now if I split this into two microservices, when microservice A crashes, then the keys in microservice B "expire" and are no longer valid. In my thinking, that makes us tightly coupled.

One microservice goal is loose coupling. But I just don't see how I can do that if I am tightly coupled. Single responsbility principle allows for exception to single responsibility for "cohesive related functions", which seems to apply.

I always thought that the single responsibility principle needs to be tempered with wisdom. Splitting every single tiny function into separate programs at some point becomes wasteful.

So bottom line is I am in a philosophical argument here, and I don't know how to approach the question about coupling. Clearly, at some point it doesn't matter if data is coupled, you have to draw boundaries at some point and this makes this choice to split the service a subjective decision. You could argue that primary key association is least amount of coupling you could ever have, so I should get over myself. At the same time, creating two databases (one for each service) to track key associations seems like overkill.

And there is a practical argument. I have software that works. No need to change that. It would be a lot of work to split these out. I would need to make a permanent database to store these keys, for example. I would need to detangle coupled classes and functionality. In the work vs value equation, it's hard to say "the value of 100 hours of work is microservices for microservices sake." That's not to say microservices for microservices sake isn't valid, but I would rather spend 100 hours on creating "real" value.

How do you decide? Am I missing a clear guiding principle here?

Upvotes: 0

Views: 196

Answers (1)

João Dias
João Dias

Reputation: 17460

My take on microservices is that you don't need a micro codebase to have something that you call microservice. What do I mean by this? I mean that we shouldn't take the micro part to the extreme and have microservices that do almost nothing just for the sake of having 20 different microservices when maybe the best decision was having 3, 2, or even a single one. The important thing is to build a microservice that is actually able to deliver some kind of useful complete feature. However, this feature must be large enough so that it deserves a microservice of its own.

As you describe it, datasource A and datasource B are so tightly coupled that trying to separate them just doesn't seem right. Trying to force a couple of microservices in a use case that does not scream for a microservices approach is the worst thing you can do. Maintaining microservices is hard, much harder than a single monolith in some aspects. Just think about changing a class that is used as a DTO for communication between microservice A and microservice B. You can't do breaking changes otherwise your whole ecosystem will suffer and thus you need to take care and do it in baby steps. When you have a single monolith you can do it in one go.

Having said that, I am not advocating in favor of monoliths. I am just saying that microservices should have the right size, not too small and also not too big and usually, it comes down to whatever is a sensible separation of concerns in your business logic.

Once again, as you described it, I wouldn't go with 2 microservices.

Upvotes: 1

Related Questions