[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
I've entered my thoughts and how aspects of my use can be used to explore those questions below Ken's comments. Rex On 2/11/2017 6:43 PM, Ken Laskey wrote:
Some thoughts and further questions inline.From his website microservices.io consultant Chris Richardson cites six microservice deployment patterns:
I think that behind the scene with Severless deployment and Service deployment platform we could find VMs or Containers/Pods but they are provisioned opaquely on the fly by the PaaS providers (various clouds, AWS, MS Azure, etc.) From the use-case: there could several different microservices that use only certain parts of the raw XML CAP alert message, e.g. the <event>, <headline> and <instructions> which could then be delivered by the microservice to end users on mobile devices(smartphones) as small windows/panes, desktop webpages where they are inserted into small windows within a webage, and as scrolling text across television screens as we see in regular EAS tests. I don't think that MSA does encourage reuse because it encourages formerly monolithic systems to be decomposed into more atomic microservices that are intended to work together (perhaps through a mutual event-driven approach that "commits" updates) with one microservice using the output of another microservice, but with both/many independently choreographed or orchestrated by sharing the choreography rules or orchestration engine. This decomposition of monolithic systems into what can be thought of as relatively "closed" MSA ecosystem doesn't lend itself well to having some other MSA ecosystem to use a particular part of the former MSA ecosystem. For instance, an authorization microservice for an investment banking MSA ecosystem probably wouldn't work well for a credit card MSA ecosystem, even if it was for the same corporate conglomerate. From the use-case: there is a case to be made for a CAP Alert Microservice that could be shared because the CAP-v1.2 specification is so small that the data-rich content could be sliced and diced a dozen different ways by other microservices for delivery to different devices as noted in 1. above. This is something that I am looking into. From the use-case: this is exactly what I'm looking into because the data in a CAP message is fairly easily teased out into special concerns since it covers everything from daily occurences to major events, so while the weather service handles the regular repeating meterological events, other CAP feeds come into play for "Amber" alerts, or roadway closures, or fires, etc. With the worldwide adoption of CAP, there are too many, rather than too few use-cases to be analyzed. And that doesn't touch the surface of the whole Emergency Data Exchange Language (EDXL) set of specifications--they are all data-heavy. The links I provided in 1. highlight the fact that these technological choices are crucial and we need to get more results to look at to benefit from the experience of early adopters. That website also has a collection of such use-cases and if you have the patience to follow links, also offers example code. Warning: this is a Java guy. So am I now that I think about it. Never spent a lot of time in the .Net universe. However, the work I'm doing now to promote adoption of EDXL demands agnosticism and the cloud environment doesn't seem to favor one platform at the expense of others and the Linux/Apache server world still holds sway. At least as far as I know. I think the main point to Microservices was to strip down to optimal functionality for just this purpose, plus the ability to respond to market with continuous deployment so that both the velocity of processing and Lean-DevOps programming move in lockstep to maintain optimality. I think this is the heart of our discussion on appropriate scoping of finer-grained Microservices or coarser-grained SOA services. Also we need to think about how to optimize inter-service messaging for event-driven architectures. We also need to think about how to ensure eventual-consistency
From the use-case: this is one problem that isn't encountered much, but an example in the case of a Winter Storm Warning update would be the added <instruction>Chains are now required from Truckee to South Lake Tahoe on I-80 from 2:30 A.M January 22, 2017 until 12:00 P.M. noon January 22, 2017</instruction> Each microservice that pulls this feed would then update its local database and format the data according to whatever device/application it delivers the change to. Since this is the last-mile to the enduser there is no need to update any other database My reading indicates that we are still faced with the old orchestration or choreography choice. And, of course, we see a lot of combined-product offerings like Red Hat's combination of OpenShift/Kubernetes for container clusters on the orchestration side. Unfortunately this can lead to contract-side coupling and can actually inhibit finding the most appropriate design for a given proposed-scope Microservice. Apparently the smart endpoints-dumb pipes approach of choreographing MS is finding wider appeal. Quoting from the link immediately preceding, "...Applications built from microservices aim to be as decoupled and as cohesive as possible - they own their own domain logic and act more as filters in the classical Unix sense - receiving a request, applying logic as appropriate and producing a response. These are choreographed using simple RESTish protocols rather than complex protocols such as WS-Choreography or BPEL or orchestration by a central tool. The two protocols used most commonly are HTTP request-response with resource API's and lightweight messaging..." From the use-case: this is what we are doing with CAP through an adaptation of Google's CAP Validator which uses a protocol buffer. That protocol buffer is a kind of combination of HTTP request-response and lightweight messaging that can be used between microservices or for capturing direct input from endusers. What are protocol buffers? You can play with the validator using the newly revised use-case example I will be sending shortly or Google's CAP examples available on the site. Please note: when I pasted the xml of the original use-case example into the validator it threw an error so I had to copy the WGS84 coordinates from one of Google's example CAP messages and pasted it into the example to eliminate the error and then pasted the corrected CAP xml into the validator and it worked! I have pasted those same coordinates into the use-case example and sent it to the list again so we will have the corrected version to use. Agreed.
-- 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]