Microservices are now nearly ubiquitous in applications. They bring multiple business advantages - scalability, autonomy, higher innovation, and faster time-to-market.
But microserves are designed to be decoupled and autonomous. When services remain coupled, you’re unable to fully receive the benefits of this design paradigm.
The following warning signs may show up as a result:
- Product may still be technically rigid
- The time-to-market value never appears. This reduces competitive edge, makes it harder to adapt to changing market demands, and limits adoption of new and more valuable technology
- Commercial database licensing is too expensive to keep yet too expensive to replace
- Low confidence in the ability to scale the business - an architecture that hinders instead of supports growth
How the monolithic database limits your microservices architecture
These symptoms are the consequence of several root problems.
First, microservices fail to deliver maximum value when sharing a monolithic data store. We decompose applications in order to decouple them. This decoupling should enable service autonomy.
By retaining a monolithic data store, these services remain coupled (see figure 1). When you couple services to a common data store, they can only scale their compute independently. When the data store needs to scale up or down, that impacts all other services sharing that same store. Further, any service consuming high amounts of IOPS puts other services at risk of performance degradation.
Second, there are some schema-related considerations with a shared data store. If more than one service consumes information from the same location (i.e., table), your team can no longer freely change that portion of the schema to support a single service. You have to consider every affected service.
When this dependency is unknown, it requires more due diligence through impact analysis ahead of any planned change. This increases the time required in the development cycle and makes feature changes more complex. Also, there aren’t any databases that excel at every single data use case.
Third, the data landscape is complex. You can see that in the variety of database flavors we have today: relational, NoSQL, time series, document stores, ledgers, etc. When you choose one database to serve needs outside of its design, you see the “square peg in a round hole” problem.
For example, if you have a web application that needs to store and retrieve key-value pairs, you can get much better performance out of a purpose-built data store like DynamoDB than you can a traditional relational data store like SQL Server.
Kenneth Henrichs
Karunakar Kotha
