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