|
Thanks Mike,
I was aware of the
Facade design pattern, and like containers, which also have a
long history in the context of application servers and virtual
machines, these structural designs have been attempts to
efficiently address differing sets of concerns or design
requirements. This has prompted me to do a review of the
development of these architectural patterns leading to SOA and
MSA going back to the fundamentals of Object Orientation, at
least for myself. This has been a response to the amount of
reading material that we have been reviewing. I am not surprised
that you have in some sense, also been stimulated to review
programming design principles leading to your work on COS. I
think the work we're looking at in a side-by-side comparison of
SOA and MSA will be valuable in this overall context.
I also think that Ken's
work with SAFe could be valuable for bringing the practices of
Agile development and DevOps into our perspective since
philosophies behind team-building are crucial to the
architectural choices being made.
Cheers.
Rex
On 11/25/2016 3:05 AM, Mike Poulin
wrote:
First, to Ken, to be accurate I said that some MS are
exposed to consumers, not only to other MS in the same
application/container.
These consumers may be exteranl (regarding to the
application/container) applications/devices; I do not know
if they are 'end-users' or just 'middlemen'. I've seen many
examples of such exposure.
To Rex, an API Gateway is a modern term that realises a
very old pattern known as Facade. If a designer of an
application wants to hide internal components and their
interfaces from the external ((regarding to the application)
consumers, a Facade component is used. This component
translates/transformes externally exposed API into one or
several internal ones. There are may be many patterns (for
invocation of APIs) used; for example: Delagate, Moderator,
Chain of Command, etc. The cost of using API Gateway (and
all related patterns) is performance.
- Michael
This
topic led me to yet more reading, specifically
NGINX articles supporting their API Gateway
product line. In their Introduction to
Microservices, https://www.nginx.com/blog/introduction-to-microservices/?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
they say this:
... On
the surface, the Microservices Architecture pattern
is similar to SOA. With both approaches, the
architecture consists of a set of services. However,
one way to think about the Microservices
Architecture pattern is that it’s SOA without the
commercialization and perceived baggage of web service specifications
(WS-*) and an Enterprise Service Bus (ESB).
Microservice-based applications favor simpler,
lightweight protocols such as REST, rather than
WS-*. They also very much avoid using ESBs and
instead implement ESB-like functionality in the
microservices themselves. The Microservices
Architecture pattern also rejects other parts of
SOA, such as the concept of a canonical schema..."
I don't recall specifying WS-* or a canonical
schema, but I did find their decomposition of the
Microservices Architecture in their diagrams quite
apt. However, since the the following article in
their series, Building Microservices Using an API
Gateway, https://www.nginx.com/blog/building-microservices-using-an-api-gateway/
concludes that
"...For most microservices‑based applications, it
makes sense to implement an API Gateway, which acts
as a single entry point into a system. The
API Gateway is responsible for request routing,
composition, and protocol translation. It provides
each of the application’s clients with a custom API.
The API Gateway can also mask failures in the
backend services by returning cached or default
data...." I suspect that API Gateways are very much
like ESBs were. I have yet to read all of their
articles, but I look forward to reading Event-Driven
Data Management for Microservices https://www.nginx.com/blog/event-driven-data-management-microservices/?utm_source=building-microservices-using-an-api-gateway&utm_medium=blog
Rex
On 11/23/2016 11:55 AM, Martin Smith wrote:
Ken, Rex, Mike, and all-- Didn't get a chance
to bring this up today but maybe we can discuss
next time . ..
This was also partly in response to Mike's
comment that he believes that in Microservices
API interfaces are typically/often exposed
directly to end-users vs only to other MS
components within an application container.
Martin
--
Martin F Smith,
Principal
BFC Consulting, LLC
McLean, Va 22102
703 506-0159
703 389-3224 mobile
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|