Re: Fwd: [soa-rm] microservice database consistency

HI All, very interesting finding. Martin.

Such event-based notification is by definition is error-prone and appears as a patch onto the architecture rather than a thought-through solution:

1) sending even asynchronous messages requires an extra time and resources - performance degradation

2) a leg from MS to the message 'broker' (even if it is in the container) can be broken and either the MS does not notify others about the data change or the MS stack/frozen until the communication with the broker is restored

3) another MS may be not on line or busy and cannot get the update on time. This requires queuing of broker's messages and still, this MS may invoke this queue after sending out the result of working with spoiled data

To avoid all these problems, _all_ MS have to be under the same management and development. Good-bye independence of services. As I said many times, MS is another attempt to leach Services and make them Objects (otherwise, developers have to admit that the architects +designers drive the development and equality in the Scrum teams and projects is a bluff).

As of Cloud, Private Cloud (Shared Pribate Cloud) nowadays have the same calculation capacity as Public one and the only difference between them is in the contracts with the customers and, therefore, in the provider's operating model.

Cheers,

- Michael

Sent: Thursday, February 02, 2017 at 9:44 PM
From: "Martin Smith" <bfc.mclean@gmail.com>
To: soa-rm@lists.oasis-open.org, "Dr. Ken Laskey" <klaskey@mitre.org>
Subject: Fwd: [soa-rm] microservice database consistency

Ken --I had a quick look at the first ref. It offers 2 ways of maintaining consistency. I followed the link to the first method (every time a MS changes its copy of data, it generates an event to notify the other services that use that data so they can update their copies.) That link led to this (emphasis added):

" The event store also behaves like a message broker. It provides an API that enables services to subscribe to events. When a service saves an event in the event store, it is delivered to all interested subscribers. "

So now my MS ecosystem has to include a message broker service!

I am getting the impression that the "simplicity" of MSA depends on a LOT of infrastructure--containers, logging services, orchestration services , health check services, reverse proxies, cache services, dynamic discovery services (this list from the NGINX MSA), and now a message broker.

Now I know that AWS (for example) can provide containers, message brokers, an API gateway, and loggers (at least) but: (1) using these services requires familiarity with a lot of tools/services; (2) in some cases, like the health check and event notifications to maintain data consistency, the approach requires code in each MS; and (3) one begins to wonder if all this interaction--e.g., generating and reacting to all the data-update events--doesn't create a lot of transaction overhead. Maybe it's all worth while to get horizontal scalability, and maybe although it looks like a lot of activity it's still more efficient than the dreaded monolith.

And another thing: AWS and other Public Cloud providers may have implemented all these supporting services/tools, but how would that be done in Private Cloud??

My 2c.

Martin

On Thu, Feb 2, 2017 at 3:37 PM, Ken Laskey <klaskey@mitre.org> wrote:

This has been a continuing topic of discussion and I found some info that actually covers this in the level of detail where you an envision a solution.

First see http://microservices.io/patterns/microservices.html, specially

How to maintain data consistency?

and then the link http://microservices.io/patterns/data/event-driven-architecture.html.

Thoughts? Continuing questions?

Ken

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508

Martin F Smith, Principal

BFC Consulting, LLC

McLean, Va 22102

703 506-0159

703 389-3224 mobile

soa-rm message

How to maintain data consistency?