I'm considering moving a monolithic REST API to a microservice architecture, and I'm getting a bit confused about data storage. As I see it, some of the benefits of microservices would be:
- Horizontally scalable - I can run multiple redundant copies of a microservice to cope with load and/or a server going down.
- Loosely coupled - I can change internal implementations of microservices without having to change the others, and I can independently deploy and change them etc...
My problem is with data storage. As I see it there are several options:
- A single Database service shared by all microservices - this would seem to completely eliminate any benefit of loose coupling.
- A locally installed database instance on each microservice - I can't see a way of horizontally scaling this, so I don't think it would be an option.
- Each microservice has it's own database service - this seems the most promising, as it preserves the benefits of loose coupling and horizontal scaling (using redundant database copies and/or sharding across several)
To me, the third option seems to be the only option, but it seems incredibly heavyweight to me, and a very overengineered solution. If I'm understanding it right, then for a simple application with 4-5 microservices I'd have to run 16-20 servers - two actual microservice instances per microservice (in case of server failure, and for deploying without downtime), and two database service instances per microservice (in case of server failure etc...).
This, quite frankly, seems slightly ridiculous. 16-20 servers to run a simple API, bearing in mind that a realistic project will probably have more than 4-5 services? Is there some fundamental concept that I'm missing that will explain this?
Some things that may help while answering:
- I'm the sole developer on this project, and will be for the foreseeable future.
- I'm using Node.js and MongoDB, but I'd be interested in language-agnostic answers - an answer might even be that I'm just using the wrong technologies!