Re: [soa-rm] SOA-MSA Side-by-Side Notes

[rexbroo <rexb@starbourne.com>]

Good points.

I think the comment I quoted missed the mark by using the notion of sharing when it really meant dependencies, or, in the case of SOA unintended consequences of dependencies caused by too many shared services (reuse of services); while MSA seeks to severely limit dependencies by focusing on the smallest reasonable scope for individual microservices. Of course, as you point out, changes in individual microservices can also have unintended consequences.

I agree that both architectures have problems with code reuse leading to more coupling. I think we're on the road to discovering some quantitative and qualitative methods to identify where/when either architecture is better suited to a given problem set.

Cheers,
Rex

On 12/22/2016 5:33 AM, Mike Poulin wrote:

Indeed, an nteresting comment.

 

The presented share/non-share notion is quite erroneous, IMO.

 

SOA is not about sharing (which in my interpretation is having something and sharing it with others); it is about cooperating as much as possible with other services in solving tasks, i.e. the only shared thing here is the task. Anything that a service owns cannot be shared (not even "share-as-little-as-possible") becuase of the SO Composability Principle at least.

 

Also, I think that an individual microservice should not share anything as well (becuase of the risk of coupling and limitations  of its usage limitations  in an application). At the same time, the MS-based applications do share used libraries and microservices. As a result, if we have 2 of such applications and they share A microservice, a change of this A microservice for the sake of one application immediately impacts another one. This is a beared problem of code reuse in any programming development - the more reuse, the more coupling.

 

In order to avoid coupling-by-implementation in SO Ecosystem, I  proposed (about 7 years ago) a service development principle known as DOSOM where the design of a service starts with 4 steps:

1) define functionality to be provided;

2) define RWE for particular EC;

3) define service execution boundaries;

4) define the service inputs.

The service execution boundaries prohibit any references to or invocations of the environmnet elements (other services) other than through the service's public interfaces and predefined invocation listeners (to the suppliers). This is where design and implementation of services in SO Ecosystem differes from the MS and MS-based applications.

 

- Michael

 

Sent: Thursday, December 22, 2016 at 12:39 AM
From: rexbroo <rexb@starbourne.com>
To: "soa-rm@lists.oasis-open.org" <soa-rm@lists.oasis-open.org>
Subject: [soa-rm] SOA-MSA Side-by-Side Notes

Came across this in reading the Mark Richards' Microservices vs. SOA book and it struck me as particularly apt:

"SOA is built on the concept of a share-as-much-as-possible architecture style, whereas microservices architecture is built on the concept of a share-as-little-as-possible architecture style."

I will continue posting nuggets for the side-by-side comparison as I come across them.

Rex

-- 
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670 

-- 
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670