[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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, On 1/19/2017 9:16 AM, Ken Laskey wrote:
-- Rex Brooks Starbourne Communications Design Email: rexb@starbourne.com GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]