3

I am still trying to find my way around micro-services. I have a fundamental question.

In an enterprise scenario, micro-services would probably have to write to a persistent data-store - be it a RDBMS or some kind of NoSQL. In most cases the persistent data-store is enterprise grade, but a single entity (ofcourse replicated and backed up).

Now, let's consider the case of a single micro-service deployed to private/public cloud environment having it's own persistent data-store (say enterprise grade RDBMS). As I scale my micro-service, there will be multiple instances of the micro-service trying to read/write from the same data-store. A traditional data-store can probably be tuned to handle ~50-200 concurrent connections. How do I handle a situation when my microservices has to be scaled much beyond that?

What are the best practices in such a scenario? Any patterns that can be used?

TechiRik
  • 1,893
  • 6
  • 27
  • 37

1 Answers1

1

Ideally each microservice instance is self-contained so that each instance can scale independently of others while also encapsulating its state so that others can only access it through a well-defined API. So not only do you need to figure out how to scale your database(s) that your microservices use to store state, you also have this encapsulation problem to solve if you really want to nail this architectural pattern.

Have you looked at Service Fabric to solve this? Service Fabric has a concept of stateful services where data is actually stored inside each microservice instance. The platform handles replication and disk persistence automatically for HA and also has data partitioning built-in for distribution across machines. The idea is basically to ditch the central database, instead co-locating your compute and data within a microservice instance. Now your services are self-contained and suddenly the solution fits this architectural pattern nicely, because now each microservice instance can be scaled out and upgraded independently and you have full encapsulation of your data inside the service. The trade-off of course is that you don't get the feature set of a full-blown RDBMS, but if you're considering NoSQL stores anyway that shouldn't be a huge deal.

My thought on this has always been that a central store like a database is somewhat of an anti-pattern in a shared-nothing microservices architecture. Full disclosure though: I work on Service Fabric so my opinion may be a little biased!

Vaclav Turecek
  • 9,020
  • 24
  • 29
  • 2
    I understand the pattern of encapsulated data-store. However, that is hardly the scenario in an enterprise reality. They already have enterprise data stores and now need applications architected based on microservices. How would I tackle such a situation? – TechiRik Jun 02 '16 at 01:21