| Michael,
I’m a bit confused. The SOA-RAF discusses service description and the service interface is one aspect of the service that needs to be described. Neither the SOA-RM nor the SOA-RAF talks about identifying the technical scope of a service, and this is something added by the microservice concept.
Ken
I do not understand 'API may be implemented' via SOA. Services in SOA supersede API in all aspects; APIs do not have many architectural and operational aspects that Services have. API/MS represent a next level of development maturity when an interface is finally accompanies with 'wordsabout business functionality but still lacks a mechanism of linking between Interface - the entity that exposes this interface and reprinting an access to the capability - agreement with the consumer on the terms of this access.
Michael
Ken wrote: “Personally, I do not think microservices and APIs are the same thing. An API is an interface, sometimes for a microservice, sometimes not. Also, the (micro)service accessed by an API represents access to some functionality; you still need the “underlying capability” discussed in the SOA-RM.”
I definitely agree with that … in fact, a given API could be implemented via MSA, SOA, WS, or monolithic application architectures, etc., to offer the functionality of the ”underlying capability”.
Or so it seems to me, BobN
Michael,
Personally, I do not think microservices and APIs are the same thing. An API is an interface, sometimes for a microservice, sometimes not. Also, the (micro)service accessed by an API represents access to some functionality; you still need the “underlying capability” discussed in the SOA-RM.
I did a little digging on P2D2 and I am not at all clear how this affects consumer individual accounts. It appears to require common APIs for common functions without specifying how the functionality behind the interface is implemented. So far, so good. It also appears to get directly to information without the bank flooding you with advertisements. This again is consistent with our discussion of services: real world effects.
Now if you are telling me the API can target my account details, that is a larger problem than whether there is a microservice involved. I would hope there are authorization rules (and logging) that go with using an API that accesses personal information.
I am not sure what role this committee would play other than offering technical advice. We certainly do not have expertise in writing regulations.
Ken
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-7996
McLean VA 22102-7508
I ve read through all posts and I agree with all (what a surprise?!) conclusions.
Here I'd like to step one level lower your comments and recall that they said about MS and its scope in the application. In other words, they said (correct me if I am wrong) that MS technology (as it is today) assumes that all MS are local to the application they compose. All questions about referencing external MS (and related consequences about ownership and dependencies with unmitigated risks) just confused our guests.
I have an input that comes from from business and regulations rather than from technology (the latter does not feel a tsunami). However, the first is a question:
when we talk about API, can/may we mean Microservices?
In my mind, Microservices are API are the same, the opposit may be not necessary true. A regulation I've mentiond was released in 2015 for Banks and its name is PSD2. I believe it is applicable in the US and the UK. Amopng others, it states that Banks (starting Jan 2018) must produce APIs that others (non-banking entities) can use to access customer's accounts held by the Banks and, bypassing Bank's services, deal with those accounts.
This means that APIs definetely go into inter-enterprise communication across ownership and legal boundaries. That is, I think that Microservice will be used as such APIs. The problem here is the same as we discussed in our meeting - unmitigated legal and technical risks for the API-providers and consumers.
I concluded the post with a proposal to look at OASIS SOA RAF that prohibits any interaction via API without preliminary explicit or implisit agreement - Service Contract. I also proposed that the Banks should register all requesters before responding to the API requests. I am looking for your support in this movement.
[The regulation also states that Banks have to obtain customer consents before opening the account, but this requirement is 1) not controllable; 2) can contradict the EU GDPR regulation (which requires an explicit permission on the use of your data and the Bank does not know who used the API, i.e. cannot obtain your explicit consent for this entity).]
So, the non-Banking institutions in their fight against Bank's monopoly on money processing has chosen the immature technology (API) placing all of us in the acquard and terribly risky situation. Welcome to the SOA-violation hell - I called for a loud extending SOA onto business a couple of times before, but now it may be too late.
I think this is a very cogent set of comments from Ken, Rex, and Martin. The two that strike me most are:
- Martin: “The objectives [of SOA and MSA] seem to be quite different” - Ken: “agile/lean, cloud, DevOps, … There was general agreement — a point to capture — that it is progress in these (and similar) areas taken together that drives the discussion”
To Ken’s quote: As I have said from the start, MSA – as practiced by the hyperscale cloud service providers in particular – is primarily a packaging construct that optimizes the path from Agile development, continuous deployment mode of DevOps, rapid instantiation of virtualized infrastructure production environments (often in concurrent operational mode), and a host of business practices that would be difficult to carry out (most notably having a multiple distinct customer segments using different versions of a business service, short-term or long-term, for a variety of reasons).
To Martin’s quote: As MSA becomes more popular among organizations other than the hyperscale CSPs, we might see some “smoothing” of the very crisp production-oriented packaging paradigm and a degree of evolution with more of a SOA flavor. The basic point about “quite different” objectives won’t go away, but the business drivers and technical capabilities of the hyperscale CSPs are somewhat distinct from most other categories while the potential business value of MSA has very broad appeal. It will likely remain a fluid proposition for some time, as the hyperscale CSPs continue to refine their practices while the rest of the world attempts to understand, normalize, and standardize.
Even I can tell I’m rambling now!, BobN
From: soa-rm@lists.oasis-open.org [mailto:soa-rm@lists.oasis-open.org] On Behalf Of Martin Smith
Sent: Thursday, April 06, 2017 7:24 PM
To: <rexb@starbourne.com> <rexb@starbourne.com>
Cc: Laskey, Ken <klaskey@mitre.org>; soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] follow-up on RedHat discussion on microservices, etc.
Rex, Ken, all--
Disclaimer first: I had to leave the RH call at about 1:55PM (1 hour in.)
My main takeaway was that many of our tentative conclusions were validated:
1.The focus of MSA is on giving small development teams flexibility and tools to support the overall agile/dev-ops approach.
2. There is, so far, much less attention on re-use, and re-use is taking the form of registries of APIs, with not much robustness (so far) as to SLAs or eve service description, payment arrangements, and update/revision management. (I am not sure, now that I think of it, if this sharing is of access to running services discovered via the API registries, or the registries are just code repos, free or not, for copying MSs.
3. MSs require a good deal of infrastructure support, via container services or other execution environment tool sets.
4. Selection, implementation and operation of these execution environments is an emerging specialization, closer to and mostly staffed so far by the network/ops staff vs. the MS coder types, because the required skill set is closer to the former. (This does seem to beg the question of how much the requirements of the execution environment are or should be driven by characteristics of the supported applications, and how the environment designers find out about those characteristics. Probably "muddle through" at least for now.)
5. Indeed it does seem like application orchestration (vs. dev/ops pipeline orchestration) is typically handled by an "API gateway" product, which also handles dynamic address resolution, access control, protocol translation and maybe more. Truly, the ESB is alive and well and living under an alias!
6. At least for RH, the issue of database consistency (and contention) seems to be solved by having a single database, with the supported MSs only having private "views" of the data.
7. RH cited efficiency of in-process calls as one of the most important benefits of MSA--but I think that's actually attributable to containers.
I guess I don't actually see MSA as SOA "done right" or even as SOA as reinterpreted for the Cloud. The objectives seem to be quite different. Both concepts do seem to be descendants of the basic ideas of componentization and OO (esp implementation hiding behind the advertised interface).
Maybe it would be worthwhile to spend a little time reviewing what the objectives of SOA were/are.
Ken--thanks for setting this up--very interesting.
On Thu, Apr 6, 2017 at 6:49 PM, rexbroo <rexb@starbourne.com> wrote:
I think we are arriving at the point where we see
- the progression of working/teaming moving from Waterfall/Monolith toward agile/lean/devops continuous delivery pipeline as one thread,
- the progression from o-o programming through enterprise-level SOA through to containerized MSA as another thread,
- the progression of computing platforms from mainframes and enterprise-level installations to collections of microcomputers to hybrid networks through to the cloud as a third thread, and
- the progression of execution context from centralized relational highly consistent SQL datastores to more decentralized NoSQL eventually consistent datastores with greater flexibility, faster throughput and higher availability at some risk,
and I think we have the basics covered. But what do we make of it? And how do we boil it down to a coherent set of heuristics for how you analyze and deconstruct business problems to fit all four of these threads together? And how do we make it work for us in a solution set that is doable, reliable and as consistent as you can make it, given a certain unavoidable level of risk? Sheesh! No problem! Rex
On 4/6/2017 8:32 AM, Ken Laskey wrote:
Yesterday’s discussion was stimulating, informative, and a good start to digging into a level of detail that goes beyond a lot of the popular tech literature.
- what do you think are important points we established?
- what are the next set of questions?
I have a lot of notes and am more likely to harvest mine if other harvest theirs.
P.S. The etc. in the subject is because a discussion of microservices wanders into associated aspects of agile/lean, cloud, DevOps, … There was general agreement — a point to capture — that it is progress in these (and similar) areas taken together that drives the discussion.
------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
--
Martin F Smith, Principal
|