Re: [soa-rm] The Hidden Dividends of Microservices - ACM Queue

["Mike Poulin" <mpoulin@usa.com>]

Ken, 

you have spoted abig BS.

 

"- Such services are typically simple" - this is an uninformed speculation. With Microservices, we have no clue what is behanind them (I can call a rotten redish a peach-API). In reality, here is a significant mistake - we talk about _API_ "are typically simple".

 

About application - this is going without saying - a service's crap.

 

I do not follow this: "

- You're probably not doing microservices if:

• Services share a persistence store.

"

No, normal 'SOA services' do not share persistence stores - this is the job for Data Access Services. 'SOA services' may not share persistence stores becuase of the Principle of Compsability and the risk of "coupling by implementation".

 

Regards,

- Michael 

 

Sent: Friday, August 19, 2016 at 8:27 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: "Martin Smith" <bfc.mclean@gmail.com>
Cc: "Natale, Bob" <RNATALE@mitre.org>, "soa-rm@lists.oasis-open.org" <soa-rm@lists.oasis-open.org>
Subject: Re: [soa-rm] The Hidden Dividends of Microservices - ACM Queue

A number of interesting points but not a lot here that I haven’t seen elsewhere and not any questions answered that I haven’t had elsewhere.

 

But a few particular (some old) questions:

 

- what are “hardened APIs”?  (I’m nit picking on this one unless someone has a significant answer to make me smarter.)

 

- Such services are typically simple, yet they can be composed into very rich and elaborate applications.

Does this mean that the only way to combine microservices is through an “application” that calls individual microservices and you can’t have a microservice calling other microservices?  We still have an unclear definition and characteristic interactions between “(micro)services” and “applications”.  This eventually gets to the reuse questions.

 

- You're probably not doing microservices if:

• Services share a persistence store.

But this tells me nothing about how two (micro)services that must make consistent use of data — or even just informational use — will share that data.  Transaction will have eventual consistency (which may be good enough) but how about if I just need to use your name in several places?

 

I’d be happy to schedule time to discuss this at our next meeting.

 

Ken

 

P.S. A longer (but not difficult) read I’d recommend is still “Building Microservices” by Sam Newman.

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

 

On Aug 19, 2016, at 12:13 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

 

Bob--Sure, I wasn't trying to judge MS completely based on this short write-up and I get it that the author was focused on what he sees as the potential workgroup-effectiveness benefits of the MS approach. I was hoping he might expand on what he meant by saying "it's not for everyone" and "the path to successful use is difficult" but he did not.  Anyhow, why dodn't you join the ne

 

On 8/19/2016 10:55 AM, Natale, Bob wrote:

Thanks, Martin … I thought the article was pretty good … the author can (IMHO) be considered an authoritative source in this wrt how the hyperscale cloud service providers are creating the de facto standard model for microservice architecture.

 

The article assumes that readers already understand that a microservice is a packaging construct for a substantive and separable chunk of business functionality exposed via an API-based service interface and corresponding SLA.

 

Supporting observations from http://thenewstack.io/succeed-failure-microservices/

 

“Microservices architecture is the biggest misnomer since global warming,” Reinhardt said. “‘Global warming’ rolls off the tongue so much better than ‘climate change.’ The drawback is that every time you have a cold winter’s day, people say global warming doesn’t exist, whereas climate change just says that the frequency of weather events is more extreme. It’s the same with microservices: people by instinct immediately focus on the micro part.
 

But microservices architecture is an architectural approach that takes into consideration the way we work and the way we organize.”

- - - - -

One tangential take-away from the ACM article that was a light-bulb moment for me was:

“The effectiveness of a set of tests can be measured less by their rate of problem detection and more by the rate of change that they enable.”

 

Avanti,

BobN

 

From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of BFC.McLean
Sent: Friday, August 19, 2016 9:33 AM
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Fwd: The Hidden Dividends of Microservices - ACM Queue

 

I don't find this very convincing but it's short. <g>

One thing i noted is lack of indication that MS tied to use of containers. 

Sent from my iPad

Begin forwarded message:

From: Martin F Smith Sr <martinfsmith@cox.net>
Date: August 18, 2016 at 11:12:18 PM EDT
To: Martin F Smith <BFC.Mclean@gmail.com>
Subject: The Hidden Dividends of Microservices - ACM Queue

http://queue.acm.org/detail.cfm?id=2956643


Sent from my iPad