The hardest part of microservices is your data

Hear from Christian Posta, Principal Architect, Red Hat in this breakout session at Red Hat Summit 2017.

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.

https://www.redhat.com/en/summ....it/2017/agenda/sessi