Hi All,
this is probably the last message from a UK pre-Brexit time...
It may be strange, buy I feel that a Microservices Orientation is better (more accurate and consistent) than a Microservices Architecture (is it really Architecture") and and positions Microservices away from service orientation (thanks God!).
The culture change here is the same as we saw for Web Services movement with one additional trick: it is "more of a change to a DevOps/LeanAgile philosophy". Consider this: with Web Services, developers tried to get to the business level by making promices of new/better business values promised by Services. Developers failed becuase they used just technology integration menas such as Web Service interfaces that did not have any direct business impact (except some standardisation and a little saving on maintenence).
With MS the picture is different and much closer to the business/values. Now, developers using MS can talk about business functionality provided by "something" behind the API. While a simple architectural analysis immediately shows that MS-based business solutions are built on a sandy ground with no robustness, but with terrible business risks, DevOps still can claim they work "like business" (until they terribly fail) and, therefore, can have a word at the level of enterprise. This is the strategic goal! Developer has to be a King! We (developers) do not need any annoing architects and silly managers - Scrum/Lean teaches that we have to make decisions and we will (when we will drive our enterprises).
Absurd? I would not be that quick in ignoring it. Read this Site: www.godef.net and especially “Manifesto for digital (architected) enablement” (a Manifest of Absurdo)
I've just come from a real-world big transformation programme in one of the Ireland banks where the vendor has sold Agile development (including DevOps) to the Client. Business people have been trianed on Agile in mass while in reality no one develpment manager applied Agile. Actual work was between Waterfall and Agile - in iterative-incremental style. The DevOps/LeanAgile were removed from the teams when the time to demonstrate the results had come - no one team's decision appeared suitable at the business level. No one Microservice was guaranteed in its execution in the real environmnet of 'rainy days' of operations (no contexts, policies or SLAs for APIs).
The next pase was about development and deployment in Cloud (PaaS and SaaS respectively). The fatal stop came from the point of Federation. There were discusstions about Federated Identity - there was a fundamental problen with existence of Federation. Why? - Becuase EU is probably more regulated market than USA and the Cloud consumers such as Banks are at the top of this regulated world. A simple quiestion - what guarantees the Client that the first line (Cloud) provided would preserve Client (service) contract with the (Cloud) provider of the second line, i.e. federated provider, was answered negatively. Therefore, a SOA Service rile "a provider of my provider is not my provider" is blocked by the Government regulations, which say that the Client is responsible for everything done with its data regardless how long vendor (Cloud service) chains are built for the data processing. Do we need a Federated Identity in this case?
Regards,
- Michael
Sent: Thursday, January 19, 2017 at 6:49 PM
From: rexbroo <rexb@starbourne.com>
To: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] How To Succeed at Failure with Microservices
This was interesting. I was expecting a Fail Fast-Fix Fast-Continuous Improvement story and found a Learn-From-Failure to Change-Culture story. My takeaway was that the author considers the change to a Microservices Orientation (rather than Microservices Architecture) was a matter of culture change, and in that sense, more of a change to a DevOps/LeanAgile philosophy.
That's all a little too vague to me. I think our focus on a side-by-side comparison will be more valuable--with key metrics like finding the optimal number of external calls per microservice as a method for narrowing the microservice scope without narrowing it too far which increases the complexity of the set of microservices needed to provide a complete set of functionalities--such as a shopping service. And, of course we need to find metrics for things like the maximum/minimum number of decision points in a chain of microservices, and how long a period of latency is acceptable in eventual consistency between microservice-dedicated instances of persistent datastores and external master datastores.
The more I learn, the more it seems to me that we're working our way toward a loosely integrated combination of enterprise-wide SOAs servicing/serviced by clusters of user-facing microservices with something like API Gateways and/or NextGen ESBs as middleware between the kinds of architectures. The software development teams seem pretty well locked into DevOps/LeanAgile for Microarchitecture, and some kind of hybrid between Waterfall and Agile for the SOA Macroarchitecture.
Cheers,
Rex
On 1/19/2017 9:16 AM, Ken Laskey wrote:
I mentioned this at our last meeting.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670