0

Our company is designing a new ERP based on microservices. The reason we want to implement microservices is because we noticed that some critical parts of the old ERP are being heavily used by our customers and as we plan to grow our business in the a period of 2 years we want to be able to deploy more instances in new servers as required at any given moment.

This is the very first project we do using microservices so there are many discussions about the design, what should be split into several microservices and what should stay together.

The old version of this ERP is giving service to several customers. Some of those customers requested us to have the application in our servers, but some parts of the DB on their servers (Sensitive information).

Because of that some people on the developer team suggested to build a microservice which only task would be to execute queries, receiving all the data needed to make a connection to the required database in order to connect to the customers DBs when required. Most of the team agreed with the idea, but some of us are not sure about it.

We don't like the idea of passing the data around like that and are concerned with the overall performance. Our concerns are because we think that calling this service every time we need data from the DB could take much time making the call, executing the query, parsing the result to json and then parsing again to the objects in the caller code.

The question is about this specific microservice whose only task will be to execute queries for other services: Would such a execute-queries-only microservice be a good idea?

closed as too broad by Philip Kendall, Ben Cottrell, Thomas Junk, gnat, jwenting Aug 17 '18 at 12:38

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 2
    We have no way of being able to answer this. You will need to try it to find out what the limitations are and to understand where the bottlenecks are. – Ben Cottrell Aug 17 '18 at 6:24
  • So you're building a centralised database access service that will grab data from one of several databases as required? That sounds like a good idea, but might be too large to be considered a microservice. A microservice would typically be more limited in its scope. – jwenting Aug 17 '18 at 12:40
  • It seems to me that one of the key features of microservices is that they need a high degree of autonomy in order to reap the benefits. That is, if you have a lot of services that depend on a single DB, you don't really have microservices. So, the idea that the customer's sensitive data would be separate and hidden behind a service is actually more aligned to microservices than your larger design. I've voted to reopen this but in the meantime, you might want to take another look at what it means to have microservices – JimmyJames Aug 17 '18 at 20:29
2

Our company is designing a new ERP based on microservices.

Why is that?

This is the very first project we do using microservices so there are many discutions about the design, what should be split into several microservices and what should stay together.

Perhaps, it is not a good idea, to go down that road.

We don't like the idea of passing the data around like that and are concerned with the overall performance.

What exactly are these concerns?

Is the suggested approach as bad as some of us think or it would be a suitable option given the circumstances?

I can not answer that: You gave too little information of what you are doing.


I would encourage you to rethink your move towards microservices. Not, that I think that microservices aren't great or not that they might not suit your environment. But I get the impression - which may be wrong - that you are just doing microservices for the sake of doing it - because you want to.

But from my perspective, that is mostly an insufficient reason. Many moved from monoliths to microservices, because they had to - meaning: their overall problems with managing a monolith got so huge, that dealing with microservices and the problems of distributed systems were easier than their scaling problems.

Of course you could just switch from monolith to microservice, if

a) you understand your product well enough and know its domain and the bounded contexts of each part. Then it will be easy to cut along the lines and move step by step to microservices.

b) you have a team, or at least several people on your team, who are skilled enough to tackle the problems of distributed systems.

But asking the question you asked here indicates, that the prerequisites a and b are at least not completely met.

Perhaps I am mistaken.

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