Tag: integration patterns

Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 3

Danish version: http://qed.dk/jeppe-cramon/2014/04/22/micro-services-det-er-ikke-kun-stoerrelsen-der-er-vigtigt-det-er-ogsaa-hvordan-du-bruger-dem-del-3/

Part 1 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 2 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 4 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 5 – Microservices: It’s not (only) the size that matters, it’s (also) how you use them
Part 6 – Service vs Components vs Microservices

In Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 2, we again discussed the problems with using (synchronous) 2 way communication between distributed (micro) services. We discussed how the coupling problems caused by 2 way communication combined with micro services actually result in the reinvention of distributed objects. We also discussed how the combination of 2 way communication and the lack of reliable messaging and transactions cause complex compensation logic in the event of a failure.
After a refresher of the 8 fallacies of distributed computing, we examined an alternative to the 2 way communications between services. We applied Pat Hellands “Life Beyond Distributed Transactions ? – An Apostate ‘s Opinion” (PDF format) which takes the position that Distributed transactions are not the solution for coordinating updates between services. We discussed why distributed transactions are problematic.

According to Pat Helland, we must find the solution to our problem by looking at:

  1. How do we split our data / services
  2. How do we identify our data / services
  3. How do we communicate between our data / services

Section 1 and 2 were covered in Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 2 and can be summarized:

  • Our data must be collected in pieces called entities or aggregates (in DDD terminology).
  • Each aggreate is uniquely identifiable from an ID (for example a UUID / GUID).
  • These aggregates need to be limited in size, so that they after a transaction are consistent.
  • The rule of thumb is: 1 use case = 1 transaction = 1 aggregate.

In this blog post we will look at section 3 “How do we communicate between our data / services”
Continue reading “Microservices: It’s not (only) the size that matters, it’s (also) how you use them – part 3”