OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [soa-rm] microservice material delivered by ThoughtWorks' Neal Ford


The official goal is perfection but isn’t it common to assume something will break  The common joke has been that Microsoft has its user base do its advanced beta testing.  To be fair to Microsoft, there’s a lot of new code and new features and legacy platforms in a typical release.  Solid automated regression testing should give at least a good a set of results.

Ken

On Feb 16, 2017, at 10:32 AM, Martin F Smith, BFC Consulting <bfc.mclean@gmail.com> wrote:

Ken--Maybe, but I wonder if a risk-intolerant organization like a Federal agency would be willing to accept "something going wrong" as a normal and expected part of the SDLC!

Martin


On 2/16/2017 7:33 AM, Ken Laskey wrote:
Continuous delivery should also reduce risk due to having smaller changes with each delivery.  If something goes wrong, there is less code to look through to find the error.

Ken

On Feb 16, 2017, at 12:35 AM, rexbroo <rexb@starbourne.com> wrote:

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 





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]