When discussing the development impact on existing applications while transitioning to microservices, there are five questions that keep popping up in one form or another. They are the same regardless of the size of the organization and seem to become part of strategy discussions later in the process as organizations move towards microservice architectures.
These articles cover questions that everyone should ask about microservices. Their based on experiences from interactions with organizations in the process of conquering microservices for existing development and for delivering modern applications.
Previously we covered the first question around the performance impact of microservices and the second question on state and monoliths. In this third article we’ll take a look at data and your distributed microservices.
Data and microservices
State discussions are central to the move to microservices for many developers and architects. Following that train of thought leads to questions around how to create a consistent state view using the data sources currently in their architecture.
“How to deal with databases backing distributed services so that the state is a single state view in the entire system?”
The best part about this discussion is that a colleague of ours has addressed this quite extensively in a book. Even better, it’s free to download (
bit.ly/mono2microdb) and provides a lot of tips.
Another option you can look at might be an open source tool
Debezium for smart database change data capturing. From their website,
“Debezium is essentially a modern, distributed open source change data capture platform that will eventually support monitoring a variety of database systems.”
Next time in this series of articles, a look at testing stateful microservices.
(article co-authored with Burr Sutter)
Published on Java Code Geeks with permission by Eric Schabell, partner at our JCG program. See the original article here: 5 Questions Everyone’s Asking About Microservices (Question 3) Opinions expressed by Java Code Geeks contributors are their own. |
