View More
View Less
System Message
An unknown error has occurred and your request could not be completed. Please contact support.
Wait Listed
Personal Calendar
Conference Event
There aren't any available sessions at this time.
Conflict Found
This session is already scheduled at another time. Would you like to...
Please enter a maximum of {0} characters.
{0} remaining of {1} character maximum.
Please enter a maximum of {0} words.
{0} remaining of {1} word maximum.
must be 50 characters or less.
must be 40 characters or less.
Session summary
We were unable to load the map image.
This has not yet been assigned to a map.
Search Catalog
Replies ()
New Post
Microblog Thread
Post Reply
Your session timed out.
This web page is not optimized for viewing on a mobile device. Visit this site in a desktop browser to access the full set of features.
Red Hat Summit 2017

S101993 - The hardest part of microservices is your data

Session Speakers
Session description

Slides available at

One of the tenants of microservices, and a way to minimize dependencies, is that “a service should own its own database.” This is easier said than done. Why? Because: your data. In working with data in information systems for 5 decades, application developers have accepted the practice of using relational databases and relying on all of their safety guarantees. But, as we build services architectures that span more than one database by design (as with microservices), things get harder. How do we synchronize data across databases, especially heterogeneous data? Developing for the traditional enterprise, we have to build fast-changing systems that are surrounded by legacy systems with complicated domains like finance, insurance, and retail. So, how do we develop and reason about the boundaries in our system to reduce complexity in the domain?

In this session, we’ll explore these problems and see how domain driven design (DDD) helps grapple with the domain complexity. We’ll see how DDD concepts like entities and aggregates help us understand boundaries—based on use cases and how transactions are affected. With transactional boundaries, we can more carefully adjust our needs from the CAP theorem to scale out and achieve autonomous systems with eventual strictly ordered consistency. We’ll see how technologies like Apache Kafka, Apache Camel, and can help build the backbone for these types of systems. And finally, we’ll look at a working example that brings all of this together.

Additional information
Containers, Application development
Breakout session
45 minutes
Session schedule