Thanks for the video
link for Ford's spiel. I found it illuminating that we seem to
have come to some fairly common understandings, but I did find
some new observations such as reducing risk by having continuous
delivery and continuous monitoring ensuring that the rapidly
changed microservices can be quickly pulled back/changed if
those changes didn't prove out as anticipated.
Also found one new tool
among the dynamic service registries for service discovery that
I was already looking at in coreos.com/etcd, and a new website
for open source tools at devopsbookmarks.com.
I was somewhat
intrigued by the notion of a middleground of Service-based
architecture between MSA and SOA, which I see as kind of like
the fulcrum of a teeter-totter for the spectrum. I also liked
the notion of starting to decompose monoliths by building fewer,
larger services yet still smaller than coarse-grained
enterprise-level SOA services rather than many smaller
microservices. However, I think that points fairly clearly at
the need for the kind of heuristics for service scoping that we
are leaning toward developing as a committee note.
Cheers,
Rex
On 2/15/2017 7:33 PM, Ken Laskey wrote:
Reading in this space is interesting because it also points out
contradictory explanations in evolving areas. Just listened to Neal
Ford - Building Microservice Architectures on Youtube. Neal
Ford If you’ve looked at the NGINX Microservices — From Design to
Deployment, you find things like
-
The API Gateway is
responsible for request routing, composition, and protocol
translation.
- The API
Gateway will often handle a request by invoking multiple
microservices
and aggregating the results.
There are some other things here that raises
Martin’s question o whether the API Gateway starts looking
like an ESB.
Neal Ford, working for ThoughtWorks at the time of
the video, pillories the ESB and emphasizes dumb pipes and
smart endpoints. While the NGINX story has the API Gateway
doing things like composition, Ford talks about the first
(micro)service called will take on the role of the
orchestration controller or each service knows the next
service in the pipeline and choreography is used for control.
Also found one new tool in
devopsbookmarks.com. Also found the
service-based Architecture middle ground between MSA and SOA a
curious concept. It seems more like a a spectrum than a
teeter-totter.
This looks like a question for NGINX.
The NGINX stuff is still the only one I’ve seen
that gets into detail of what one does to get eventual
consistency — through event processing in their work — and
synchronize each microservice’s local data store.
Should probably look more into ThoughtWorks
material.
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