4 ms·
If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.
by erpellan 7y ago
If the application is stateless (all state lives in the DB) you can run as many copies of the monolith as required behind a load balancer.
- rumanator 7y agoIf your application is stateless following your definition then it's trivial to break the monolith down to microservices that focus on a bounded contexts while sharing a common db. This is a very well known microservices pattern. https://microservices.io/patterns/data/shared-database.html https://microservices.io/patterns/data/shared-database.html
- JamesBarney 7y agoMartin Fowler lists the benefits of microservices as Strong module boundaries Independent deployment Technology diversity And with a single database you severely limit the benefits from strong module boundaries and independent deployments. Suddenly you have to synchronize deployments, and anyone can pull or change any data in the database which now must be enforced with discipline which gets you into the same boat as a monolith.
- bogdanu 7y ago> which gets you into the same boat as a monolith Only worse because you don't have tools (IDEs, linters, etc) telling you what parts of the code have to be changed.
- erpellan 7y agoYes, and what does that buy you? Instead of a single deployable unit that owns the database, there are many deployable units, none of which can own the database. That doesn't seem like an improvement.
- dnautics 7y agoYou can still wind up with distributed state errors. Ex:. User requisitions a billable resource, request hits node A. User immediately terminates billable resource, hits node B. Requisition request has a long latency (and termination request does not). So in the billing system, there is a negative time associated with the resource.