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] MSA: list of questions to experienced MS developers -- round 1


Some thoughts and further questions inline.

Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510          phone: 703-983-7934
7515 Colshire Drive                           fax: 703-983-1379
McLean VA 22102-7508

On Feb 1, 2017, at 5:12 PM, Martin Smith <bfc.mclean@gmail.com> wrote:

Ken/all--

OK, pursuant to my action ("develop questions") from today's meeting, I looked at discussion of MSA captured in recent minutes.  I think the following captures most of what has been discussed (though probably not exactly how anyone else would have experssed it. <g>) 

Consider this the first draft of my homework. If I get comments or additions before the next meeting I'll make an effort to incorporate them.

Regards,
Martin

Starter list: 

  1. Are all/most MS deployed in containers? (Examples of exceptions?) 
Seems if not containers, then VMs.  This then depends on VM/container tradeoff.  I don’t recall seeing a microservice deployed separately from a VM or a container 
  1. How does MSA encourage re-use? (Is it even a goal?) 
This still isn’t clear.  If an application consists of communications across numerous microservices, there doesn’t seem to be a reason not to reuse a tightly scoped microservice that has wide applicability.  The microservice would likely be stateless and I believe best practice would  say to avoid integration through the local database.
  1. How does MSA handle data-store consistency for data that can be modified by more than one MS? (Rex)
Falls under Event-Driven Data Management.  One of the benefits of the NGINX eBook is it discusses this in more detail than I’ve seen handled elsewhere.
  1. Is it fair to say that MSA doesn't really address how run-time and versioning dependencies across multiple MS or resource owners/providers are to be managed (when multiple "owners" are involved in delivering a complete application)? (Michael) 
Still a good question.  My previous email tonight touches on this.
  1. What is the basis for any run-time performance benefits attributed to MSA?  Are there inherent efficiencies in inter-process calls, for example?  If so, are these efficiencies due to MSA or to container architecture? 
Think I’ve seen some RedHat material on performance.  Need to distribute a reference.
  1. In a typical MSA-based application made up of multiple MS (plus back-end resources), is there a standard/typical way to control application flow (functions like orchestration, choreography or workflow)? If there is such a  standard/typical component in an MSA-based application, what's it called? (Possibly related: what functions does an "API Gateway" commonly perform?)   
Martin once asked whether an API Gateway is the new ESB.  For me, that is more of a question after reading the NGINX D&D eBook section on the API Gateway.  In particular, what does it mean for the API Gateway to get a request, distribute it to multiple microservices, and then recombine into the final answer?  As with traditional SOA, I can minimize the dependencies for a component service but I still have the dependencies of the “integrating” controller on the pieces it integrates.  The NGINX eBook also notes the API Gateway becomes a critical high availability component.
  1. What are the [three] main benefits of MSA?  How does MSA deliver each (vs a specified alternative methodology)?  (What architectures were MSA developers typically using before adopting MSA?)  
If microservices is SOA done right, the major benefits of microservices are their convincing realization of what SOA was intended to be.






  

--
Martin F Smith, Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile



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