[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [soa-rm] Fwd: The Hidden Dividends of Microservices - ACM Queue
|
Hi Mike, I think we’re speaking different languages (not maliciously): I am trying to speak the language of those who actually implement what they call microservices today … you might
be speaking the language of SOA advocates (of which I am also one) … the two need not be at odds, at least on many aspects of solution design, development, and deployment. However, what the currently successful advocates of microservices package is not interfaces … it is functionality … the interfaces (APIs) merely expose the high-level functionality
in (business-)usable ways. The value they perceive in the packaging construct they call microservices is more aligned with what they see as an efficient mix of team organization,
design methodology, development methodology, and deployment methodology as it is to any purist notion of software architecture. That those aspects have secondary effects on software architecture that might bend or break some SOA is, in their view, a reasonable
trade-off for the practical value derived. That, at least, is the understanding I am taking away from observing those that are doing it successfully and a highly critical reading of the “mass market” writing about microservices
(which requires a great deal of pruning and normalizing, in my judgement). Avanti, BobN From: Mike Poulin [mailto:mpoulin@usa.com]
Hi Bob, "a microservice is a packaging construct for a substantive and separable chunk of business functionality" - this is where a big devil is hiding!... This text substitudes
existing with ddesirable. The correct statement is: a microservice is a packaging construct for a substantive and separable chunk of INTERFACES. No one API defines any business functionality, it only names something that can be anything in reality.
The owner and provider of the API has no reponsibility to the consumer for what is going on behaind the API. In the contrast, the SOA RAF makes Service Description and Service Contracts the 1st class citizens and API - the 2nd class. The Service Description
and Service Contracts describe, declare and _promise_ certain business functionality to the consumer while the APIs are only the means of programmatic accessibility of the working body that provides/delivers promised functionality. While this seems an unimportant academic neuance, a lot of companies and consumers faild becuase of this. I have not (!) found a bit of a new value that microservices bring over a combination of Web Services (API) and EJB (container-related packaging of API). The latter was the
only enterprise-level components in the pre-Web era. Microservices themselves (as well as Web Services) so not provide orientation on service. Regards, - Michael Poulin
Sent: Friday, August 19, 2016 at 3:55 PM 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 I don't find this very convincing but it's short. <g>
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]