0

I told my boss that for our next application, we will be creating rest services that follows the microservices architecture. The design I had was somewhat like this:

all functions related to users - 1 rest service
all functions related to payment - 1 rest service
all functions related to audit log - 1 rest service
all functions related to corporate accounts - 1 rest service
etc..etc..

Problem is he didn't agree with that. He mentioned somewhat like a microservice must contain finer functions. Something like one microservice for this particular type of payment, another for another payment type, one of user creation, one for user details, etc. He says my design shouldnt be called a microservice design architecture.

So my question is...does my design really follow the microservice design principle? it is too coarse grained and should be finer? is my boss right? what is the maximum limit of the finer detail functions a microservice should have?

I need your help. Would appreciate anyone who could shed light on this. Thank you

2

Read the Microservices Guide from Martin Fowler's blog. There you'll find everything you need to discuss the level of granularity for your microservices with your boss, among other things.

But if you want a spoiler: you're right (or at least "righter" than your boss). Microservices are supposed to be self-contained, meaning they should have their own UI and database bundled as a single deployable. As such, having a "microservice" for Sign-Up and another for User Details doesn't fit the concept. Instead, as was your original design, these use-cases should be grouped together in one Microservice which is responsible for Users.

  • how about if i have a complex database query that the product owners want to be easily switched or versioned when business rules change (they foresee that it might change that often). is it practical to have one microservice for each versions of the query? or just put the query in a stored procedure or something? – – Davoin Showerhandles May 13 '17 at 14:15
  • His boss is not that wrong: the user creation can be isolated from the user details if we were speaking about system that works with accounts and users as separated concepts. Different ms for different payment types also make sense, the complexity of having many of them can be mitigated with Gateway pattern. It's hard to say who is right here because we don't have enough details of the system nor requirements. – Laiv May 13 '17 at 15:02
2

There is no hard rule which will tell you that above or below a given amount of granularity, your services stop being microservices. Some services can, indeed, handle a very narrow and specific task, such as dealing with a particular type of payment. Others can be rather large in terms of responsibilities. Moreover, microservices architecture is about the infrastructure which surrounds and supports a set of services, not the size of the services.

A question one should ask is whether it makes sense to have a given piece of code in a form of a standalone service. In other words, would it make sense to use only that service, or most use cases would involve using it in combination with other services.

  • If you have a service for user creation and another one for user details, and in practically every case, they are used together, you've split it too much.

  • If you have a global user service which is used by a set of applications to only create users but never accessing their details, and a different set of applications which manage users' details, but never create new users, the service is a good candidate for a split.

Getting the size of services right is not easy. More importantly, don't try to get it right from the beginning, but rather design them in a way that it would be relatively easy to split and merge them later on, when you have a better understanding of the actual usage of the services.

  • how about if i have a complex database query that the product owners want to be easily switched or versioned when business rules change (they foresee that it might change that often). is it practical to have one microservice for each versions of the query? or just put the query in a stored procedure or something? – Davoin Showerhandles May 13 '17 at 14:13
  • This is something you could achive in a single Microservice which provide the query execution with a public interface. The interface may allow the execution of the different versions of the query. For instance, versioning the public interface. How to do that is implentation detail. You will find design patterns addressed to solve this problem. Remember that Microservices are independent applications per se where SOLID principles and design patterns can be applyed independently of how other services are designed. – Laiv May 13 '17 at 19:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.