| Generating comments to the use case email as I also go through this. Some comments in one are also relevant to the other.
Ken
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.
Ken
------------------------------------------------------------------------------
Dr. Kenneth
Laskey
MITRE
Corporation, M/S F510
phone: 703-983-7934
7515 Colshire
Drive fax: 703-983-1379
McLean VA
22102-7508
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?)
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
From his website microservices.io
consultant Chris Richardson cites six microservice deployment
patterns:
Multiple service instances per host: "... Run multiple
instances of different services on a host (Physical or Virtual
machine). There are various ways of deploying a service instance on
a shared host including:
- Deploy each service instance as a JVM process. For example, a
Tomcat or Jetty instances per service instance.
- Deploy multiple service instances in the same JVM. For
example, as web applications or OSGI bundles..."
I wonder how performance measures up when multiple microservice
instances are running within a single JVM, for instance?
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.
See deployment comment in use case response.
- 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.
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.
A long time ago (or so it seems), I asked whether “reuse” was simply making a local copy of the service to be “reused”. I think the answer for microservices is yes. An application can combine several microservices (say) running in there own containers. If Rex developed an OAuth2 authentication service and Martin needed the same functionality, Martin could spin up an instance using Rex’s image, but Rex’s instances would be local to Rex and separate from Martin’s instances except for the image that is their common lineage. Change that image and all instances subsequently spun up are again in synch. Don’t update instances, just regenerate them.
Note this is a significant difference from what we said for SOA. For SOA, we said a consumer used a service from the endpoint at which it was being offered rather than (except for mirrors) having separate local copies. This was because keeping distributed copies in synch was likely to be a nightmare. However, this was before we could spin up instances of fully-configured compute resource images like candy.
Now, do teams doing development have a way of knowing what neat things another team has already done. There we are back to the discovery challenges that burdened SOA. The only things clear was that UDDI was not the answer.
- 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.
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.
One thing I’ve done in my day job is to use processing that is common no matter what the specific content and have a parameter that identifies the content schema (or other data structure) to branch off to schema-specific processing. If a particular service understand the schema, it does the processing; otherwise, it throws a known fault. Sending an alert when a source changes would fall into a common (reusable) service.
- 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.
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.
And what I think I was referring to from “previous email tonight” - Microservices talk to independent deployment of services, and this is potentially the same fallacy as advocated for SOA, i.e. if the interface still works, a new service version (or alternate service) can be swapped in for the one you thought you chose. Assuming the new service does something differently than the old one, it was never resolved when the consumer needed to be told something changes vs. no notice and just the danger of unpleasant surprises. I consider this an open issue.
- 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.
see RedHat attachment. I can provide link to register for the audio.
|