3 ms·

Isn't one of the defining characteristic of Microservices to have a data persistence instance for each service (even at the cost of duplication)? (I am basing

by Pamar 8y ago

Isn't one of the defining characteristic of Microservices to have a data persistence instance for each service (even at the cost of duplication)? (I am basing myself on just a superficial interest for MS so I might be wrong - here is what I am talking about: http://blog.christianposta.com/microservices/the-hardest-part-about-microservices-data/ http://blog.christianposta.com/microservices/the-hardest-par...) If this is correct, than no, Microservices are really not "just like SOA". (If I am wrong, please correct me - I am here to learn).

jmartrican 8y ago
There is no microservices protocol description or RFC so its hard to say anything definitive, but yes you are right. We typically like to have a DB table (or Mongo collection) owned by 1 microservice. This allows changes to be made to the underlying datastore without affecting multiple applications. The other apps that need data, just get it from the microservice without caring about how the microservice handles it. I am in a team now that is just started using to use microservices. And I am noticing that we are stuck on a lot of DB changes we want to make because there are various applications accessing the same tables. So now we are getting into the habit of constraining back-end data stores (tables and collections) to just one microservice because we feel the pain of not doing that now.
- heavenlyblue 8y ago
  Microservice is a monolith. So what you're describing is essentially: I've got a few front-end microservices tied to 1 huge microservice I call the database. There's no "data layer" that is managed outside the microservice. It _is_ a microservice. That's one of the reasons Google uses a monorepo: any microservice can easily import a database instance and start using it as part of it's structure.
  - amirouche 8y ago
    What do you mean by 'database instance'? Is the the instance of the 'class' that represents the database and its records or something else?
hliyan 8y ago
I'm of the same belief: dedicated persistence + a small, single purpose API. That said, there is nothing "micro" about most microservices I've come across over the years. They're "miniservices" at best.

by Pamar 8y ago

jmartrican 8y ago

There is no microservices protocol description or RFC so its hard to say anything definitive, but yes you are right. We typically like to have a DB table (or Mongo collection) owned by 1 microservice. This allows changes to be made to the underlying datastore without affecting multiple applications. The other apps that need data, just get it from the microservice without caring about how the microservice handles it. I am in a team now that is just started using to use microservices. And I am noticing that we are stuck on a lot of DB changes we want to make because there are various applications accessing the same tables. So now we are getting into the habit of constraining back-end data stores (tables and collections) to just one microservice because we feel the pain of not doing that now.

heavenlyblue 8y ago
Microservice is a monolith. So what you're describing is essentially: I've got a few front-end microservices tied to 1 huge microservice I call the database. There's no "data layer" that is managed outside the microservice. It _is_ a microservice. That's one of the reasons Google uses a monorepo: any microservice can easily import a database instance and start using it as part of it's structure.
- amirouche 8y ago
  What do you mean by 'database instance'? Is the the instance of the 'class' that represents the database and its records or something else?

hliyan 8y ago

I'm of the same belief: dedicated persistence + a small, single purpose API. That said, there is nothing "micro" about most microservices I've come across over the years. They're "miniservices" at best.