Multi-model Database Key to Successful Microservices
In the last few years, microservices have exploded in popularity, and the trend is only going to grow. In fact, a survey of development professionals revealed 86 percent of respondents expect microservices to be the default architecture within five years. This software development technique, which structures an application as a collection of loosely coupled services, offers a number of benefits.
In a microservices architecture, services are fine-grained and can be deployed, updated or scaled (up or down, as needed) independently. This allows enterprises to greatly accelerate delivery and more efficiently reuse code. Additionally, enterprises are able to deliver higher quality applications since the best technology can be used to support each individual service. The ability to deliver higher quality and more responsive, real-time digital experiences are especially important for meeting consumer expectations and keeping customers engaged and satisfied.
However, making the transition to microservices doesn’t come without its challenges, and companies must formulate a careful strategy to avoid pitfalls. While there are many potential pitfalls, this article will focus on those relating to how data is stored, managed, shared and queried. In order to successfully adopt a microservices approach and reap the aforementioned benefits, enterprises must consider how data fits into the microservices architecture.
First, the microservices architecture means each service has its own database and data is shared between services, rather than leveraging a single large database. Being able to choose the most efficient data storage method for each function (e.g. a key-value store for authentication, a graph database for fraud detection, etc.) is a great benefit of microservices. However, the right data store must be selected, or this flexibility can actually cause more headaches.
Which leads to the second consideration: choosing the right data store for each microservice and their unique performance requirements. It’s important to design every service to provide the best throughput, otherwise one microservice might become a bottleneck in the flow of data and derail the entire system. To choose the best data store, the following metrics must be considered:
- Read performance—this refers to either the number of operations per second or a combination of how fast queries can be run and how fast results are retrieved. The speed of retrieving results hinges on how well data is organized and indexed. For example, an e-commerce product catalog microservice may run queries that apply multiple parameters such as product category, price, user rating, etc. The right database for this function must first organize data to run queries faster, and increase the number of operations per second.
- Write performance—refers to the number of write operations a microservice performs per second. Microservices that collect and process transient data require a database that can perform into the millions of write operations per second.
- Latency—any microservice that must deliver instant user experiences requires an extremely low-latency database, and deploying this service close to its database will minimize network latency.
- Resource efficiency—developers want a database with the smallest footprint possible for each microservice, while retaining the ability to scale on demand.
- Provisioning efficiency—in order to take full advantage of the rapid deployment, testing and production capabilities of microservices, database services supporting them must be able to support the on-demand creation of hundreds of instances per second.
The third aspect developers must take into consideration is data modeling requirements of each microservice. Again, a benefit to microservices is that each service can leverage a database that best suits its own data model, whether key-value, graph, hierarchical, JSN, streams and search engines, etc. But this is only an advantage if the right database is selected for each data model.
While being able to choose different databases best suited for each microservice can improve the functionality of those individual services (aka polyglot data persistence strategy), fragmented data management increases the complexity of orchestration, operations and development, and can require specialized skill sets for each data storage tool employed. Additionally, if two or more microservices need to share a common data set, and they’re designed to access a common database, you risk reverting back to the monolith architecture and missing out on the flexibility and local data access advantages of microservices.
To overcome these challenge, enterprises are better off leveraging a multi-model database that can store and process structurally different data on a single database platform. A multi-model database supports a variety of different use cases including cache, session store, message broker and high-speed transactions, and can serve as a document store, key-value store, graph database and search engine.
Adopting a microservices approach to app development and deployment can yield incredible value when done correctly. Developers will be able to deploy and make updates more quickly and with higher confidence, delivering the high quality app experience customers expect. But if a proper data strategy is ignored, developers can quickly find themselves dealing with a highly fragmented data management environment, which dramatically increases the complexity of both operations and development and drives up operational costs.
Leveraging a multi-model database eliminates these headaches by supporting all data types and use cases and seamlessly sharing data across all microservices within the app. A high-performing multi-model database with high availability and data durability can make the difference between a failed and a successful microservices adoption.