No
Yes
View More
View Less
Working...
Close
OK
Cancel
Confirm
System Message
Delete
Schedule
An unknown error has occurred and your request could not be completed. Please contact support.
Scheduled
Wait Listed
Personal Calendar
Speaking
Conference Event
Meeting
Interest
There aren't any available sessions at this time.
Conflict Found
This session is already scheduled at another time. Would you like to...
Loading...
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
Reply
Replies ()
Search
New Post
Microblog
Microblog Thread
Post Reply
Post
Your session timed out.
Red Hat Summit 2017

S101993 - The hardest part of microservices is your data

Session Speakers
Session description

Slides available at https://www.slideshare.net/ceposta/the-hardest-part-of-microservices-your-data

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 Debezium.io 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
Application development, Containers
Breakout session
45 minutes
Session schedule