I can almost feel the pain of all you good (smart, knowledgeable, professional) service architects beating your heads against the wall in trying to understand MSA relative to
SOA and other architectural styles. I started down that path too and backed off – I am easily bruised and bloodied!
MSA is more of a “packaging” phenomenon for DevOps than anything else … driven by modern logistics and economics on the development side and deployment facility and isolation
on the operations side … in that, it tends to converge with containerization for analogous reasons. This “packaging” is the real driver … what the MSA technical architecture will end up looking like is still up in the air … bouncing on many different “hype
cycles” at the moment … likely either a hybrid of multiple current styles or something completely new, or partly both.
Great to continue the analysis, etc. … but essential to watch what’s really happening with the (few but impactful) large-scale MSA implementations as they continue to emerge and
mature.
Just my humble opinoin … possibly motivated by laziness and dislike of cognitive dissonance (but I hope not),
BobN
True or False?: “Many great artists go undiscovered; no great performers go unnoticed.”
From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org]
On Behalf Of Ken Laskey
Sent: Wednesday, November 23, 2016 5:40 PM
To: Rex Brooks <rexb@starbourne.com>
Cc: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Are API gateways the new ESB?
Thanks, Rex. Too much to read for one person, so I look forward to your processing.
One thing when Bob Natale and I spoke with NGINX was they agreed that berating SOA by holding up the Web Services paper tiger was inaccurate because it ignores the whole community that argued for RESTful interfaces from day one. And a
lot of people who understood this already argued for tooling that provided the sparse functionality that you needed rather than the expensive behemoth you’d likely underuse.
Also, re the canonical schema, (1) you need to declare the schema (or other vocabulary representation) you are using or you can’t have confidence that you understand what the incoming message is asking you to do or the outgoing message
is telling you what happened, and (2) you can almost guarantee failure in coming up with the one true schema, et al, that would satisfies everyone’s needs.
Finally, be careful with “The API Gateway ... provides each of the application’s clients with a custom API.” This gets to the Netflix architecture we discussed several weeks ago. There seems to be need for a teasing out of what constitutes
an appropriate generic interface vs. one that gets unwieldy because it tries to do too much vs, the other end of the spectrum where you get a proliferation of interfaces that become unmanageable. Throw in a concern for chattiness for a little extra icing
on the cake.
P.S. Also to read the link you provided.
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
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 F Smith, Principal
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|