I finally got around
to watching the Chris Richardson presentation to the Oracle
Code Developers event and, because I was forewarned, I wasn't
surprised or taken aback by his conclusions. Those conclusions
centered on the scoping of microservices
according to their role within a Microservices Architecture
(MSA) that is strongly oriented toward a given application, so
I'm coming to view MSA as SOA with an Applications Orientation.
I do think the emphasis
on APIs and API gateways as a side issue, you can have them or
not depending on your choices, but that particular mechanism of
communicating between end-user and microservice
or between microservices is not the central
concern of assembling the correctly scoped set of microservices
capabilities to accomplish the application's purposes.
I was intrigued, and
remained concerned, with achieving eventual data consistency
through an event-driven approach because that is exactly what
I'm attempting produce in a reference implementation of the
simplest emergency management pattern, that of an alert message
wrapped by the distribution/routing header that is used for all
our emergency message payloads. And no matter how simple I try
to make it, it remains complex, and I think that is probably the
biggest hurdle to overcome in order to achieve the advantages of
microservices' continuous delivery, high
availability and fast performance.
Cheers,
Rex
On 4/26/2017 6:43 AM, Ken Laskey wrote:
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
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|