BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Data is the Hard Part Working with Microservices

Data is the Hard Part Working with Microservices

Bookmarks

One of the hardest problem when creating and developing microservices for an enterprise is their data. Analysing the business domain using Domain-Driven Design (DDD) and reason about what the data represents will help in achieving a microservices architecture, Christian Posta claims in one of a series of blog posts about microservices implementations.

For Posta, Principal Middleware Architect at Red Hat, the main reason for choosing a microservices architecture is that it enables teams to work on different parts of a system at different speed and with minimum interference between them. When organizing teams this way, the systems architecture will reflect it and evolve towards a microservices architecture.

The problem though, is to get this autonomy between teams really working and this is not trivial. Leaving the transactions and single database normally used in a monolithic application, for services with one database for each service can be a challenge, especially for traditional enterprises.

Posta notes that there is a huge difference between how internet companies and traditional enterprises implement microservices. While internet companies use microservices mainly for dealing with huge volume and scaling issues, traditional enterprise deal both with business and scaling complexity. The complexity in showing movies and posting tweets is far less than in an insurance claims system.

Building microservices for a reasonably complex enterprise domain, we need to find the boundaries between different responsibilities within that domain. In each of these boundaries we create a domain model, designed for and representing that responsibility. The data model for each boundary is then driven by the domain model in the same boundary. Using DDD we can find theses boundaries and create a bounded context for each, with each context becoming a microservice.

In Posta’s experience developers tend to build distributed systems assuming a single relational database, and try to abstract away the realities of unreliable networks. Often the problem with distributed data is solved using two-phase commits across multiple services. Instead Posta believes we have to look for transactional boundaries within each bounded context and find the smallest unit of atomicity needed to enforce business constraints and invariants, never allowing a transaction to spread to other contexts.

There is still a need for a service to inform other services what is happening and for this Posta recommends using events. One service publishes events about things happening in its domain and other services will read these events, adapt to their own models and persist any changes.

For a more in-depth description of these ideas, Posta refers to a series of blog posts by Vaughn Vernon describing aggregates, transaction boundaries and bounded contexts with a DDD mindset.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Data is difficult

    by Sean Wiley,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I agree with the sentiments expressed here, I've explored some of the CQRS - Microservice implementations and have found the term "eventually consistent" used to explain the inconsistency of data that might exists across services.

    I would like to point out that there are frameworks developers can use to solve this data problem. Baratine is a framework that has reworked the threading and data model to provide operational view services, taking the database bottleneck out of the critical path of execution, and allowing only a single service thread to mutate data. This ownership allows services to continually operate on data (Baratine handles persistence at set intervals) without having a single database be a bottleneck in an application.

    Disclaimer: I work for Caucho, however Baratine is GPL, you can find the source on github & use Baratine standalone or embedd it into your current Spring/Guice/Java EE container :)

  • Information technology is funny

    by Luca Veronese,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We have spent the last 40 years teaching people how to integrate data, now we will spend the next 40 to teach them how to disintegrate it.
    As the author says, Internet companies need this sort of thing. But I'm not yet sold on the need to adopt this approach for traditional IT shops where a data centric vision is the norm, in particular considering that most IT shops use packaged software.
    DDD may be successfully applied to the most critical business processes but is not a general pattern to apply to the development of an entire IT system.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT