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:
- Are all/most MS deployed in containers? (Examples of exceptions?)
- How does MSA encourage re-use? (Is it even a goal?)
- How does MSA handle data-store consistency for data that can be modified by more than one MS? (Rex)
- 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)
- 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?
- 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?)
- 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?)
--
Martin F Smith, PrincipalBFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile