thinking of this abnormal microservices

0
votes

I am reading a project used microservice. But it seems different from normal microservice.

  1. all microservices deployed in the same docker container, but each microservice has its own HTTP server listened to a random port. normal microservice usage should deploy one microservice on one server.
  2. use only one database, not one microservice one database.

So i have questions as follows.

  1. Is this a distributed system?
  2. What Pros and cons compared with Single Application Service(already seperated to several modules based on DDD) and normal microservice?
1
javamicroservicesdistributed-system
"A distributed system is a system whose components are located on different networked computers, which communicate and coordinate their actions by passing messages to one another from any system" so the moment you have a client and a server on two different computers communicating via a network you have a distributed system. - Federico klez Culloca
Yes, I also see this definition. But when reading many introductions of microservice, it said microservice must be distributed. So i am confused. - user46154
And when summarize the pros and cons of microservice, many should say it will introduce distributed system complex and difficult to test and maintain. - user46154
I think not, not a good distributed system, the part of database, not incorrect, its normal have the same db for many microservices. But, have all your microservice in the same docker instance... doesnt look fine. - A L

1 Answers

1
votes

Your described application doesn't seem like a matured microservice-based architecture.

Having a common database is not a problem, but it depends how you use it. If you have clear responsibilities and don't access the data of other services, it can be a nice way to reduce administrative overhead for multiple databases. On the other hand the database might become a point of failure. So there is a trade-off to be considered. However, if you directly access data of other microservices and there is no clear concept of responsibility for data, I'd say it is an anti-pattern or a smell. You give up the criteria of independent deployability (data model changes will break consumers).

In the described deployment scenario in one docker container this criteria of independent deployability is not given at all, as well as horizontal scalability. I'd strongly advice against it if you want to reap the benefits of microservices. Otherwise you will end up with the drawbacks of both world: a distributed deployment monolith.

I could imagine the described architecture is in a migration phase towards real microservices (docker container each service), but hasn't matured yet.