Suggest canceling. Martin
Sent from my iPad Thanks, Rex, for the heads up.
Others, we have plenty to discuss but Rex is usually an active participant.
Who was planning on attending today’s meeting? Should we go ahead with meeting or cancel?
Ken
Just a note to let you
know that I whave a dentist appt. this morning, so I'll miss
today's meeting. Will check out the minutes if available. Cheers,
Rex
On 7/4/2017 9:09 AM, Ken Laskey wrote:
As promised, a long response.
I’m about 3/4 of my way through the SOA-RM reread
and the only thing that doesn’t seem to hold is not having a
private copy of the service. That is discussed further below.
Also, as a teaser for the discussion, I give you
this preview of my wanderings:
Let’s look at
a different twist: is AWS EC2 a SOA service? It provides
access to the capability to spin up the specified server,
making use of an AWS underlying capability through a
well-defined interface and per a well-defined execution
context. AWS constantly makes changes to EC2 and the
consumer may make use of an updated interface to make use
of new capabilities or the consumer may just get changes
that are distributed but don’t require an interface
change. Also, we are obviously crossing ownership
boundaries. The underlying capability is likely
implemented as a set of microservices, but SOA doesn’t
care about that.
Looking forward to your thoughts.
Ken
------------------------------------------------------------------------------
Dr.
Kenneth Laskey
MITRE
Corporation, M/S H330
phone: 703-983-7934
7515
Colshire Drive fax: 703-983-7996
McLean VA
22102-7508
Gentlemen, I was not able to participate in the
last meeting being in the conflict with two other
meetings. I am sorry. Rex has written the last Minutes so well
that I can submit a follow-up – my 2p of
contribution.
- Review SOA-RM – at a
glance, I’d be interested in refining
the definition of service, which would
somehow outline that a service is a
“working body” with interfaces that
provides an access to the execution of
capability and returns the execution
results represented as a RWE. IMO, this
clarification would remove certain
ambiguity and confusion, e.g. between
SOA Services and Microservices.
Nevertheless, I will need to review
SOA-RM accurately.
We have made previous
attempt at redefining “service”
and it has always been like pressing a balloon of water –
what you push in at
one place pushes out at another. My pet
change would be to make the idea of a “business service”
as the union of the
capability and the access mechanism be a first class
definition. Not intending to start a discussion, I will
leave that statement and move onto the next comment.
- AWS Public
Sector Summit – in the light of previous
critics on Public Cloud in the domain
regulated sectors of industry, expected
enforcement of EU GDPR regulation (scoped
world-wide) on the private data protection
across domains/industries makes the use of
AWS way too risky for businesses until
Amazon proves it is GDPR compliant (which
means that Amazon has to kill its economy of
scale as it is today)
AWS has already created
GovCloud for US
Government work requiring ITAR restrictions and C2S for
classified content. I am sure they will be able to tailor
for EU compliance. Typically, the special cloud lags
advances in
the Public Cloud, leading to frustrated developers doing
most of their work in
the Public Cloud until the last minute.
- DevOps – as a methodology for
speeding development has a few traps: 1) it
is especially effective in the cases where
development can be substituted by assembly,
like with Microservices; if assembly is not
possible, the time benefits are not that
significant and an acceleration comes from a
merge between development and Ops –
automated testing and deployment; 2)
efficiency of DevOps is apparent in the
single development stream (for one team). If
the task for development requires two or
more development streams, the value of Ops
degrades significantly because after each
stream conducts its development and testing,
they still cannot deliver results to the
consumer – there should be a cross-stream
integration work and related testing. DevOps
as well as Agile/Scrum methods lack the
architectural e2e cross-stream integrity and
testing (plus, an automation of UAT is
extremely expensive ‘tool’).
One outcome
of taking a DevOps approach is speeding development but
DevOps heavily
leverages principles reaching back to Lean development and
Toyota. I recently gave an internal presentation on
how the buzzwords of Lean, Lean-Agile, Scaled Agile,
Miroservices, Containers,
and DevOps actually reinforce each other and provide real
value. The corresponding principles are valuable
even if the emphasis isn’t on assembly.
The merge between Dev and Ops is an important example of
generating value. The Scaled Agile Framework (SAFe) is an
example of an evolving framework for multiple teams and
traceability to
enterprise goals and priorities.
- …AWS Lamdbda,
severless computing in the cloud environment,
that takes the emphasis away from hardware
capacity specification to software development
environment and continuous
development/delivery. - Well, Peter Drucker said,
“There nothing so useless as doing
efficiently that which should not be done at
all”. Web Services as
well as Microservices constitute a very high
risk to the businesses of the consumers and
expose these businesses to the mercy of WS
and MS providers. There is no
methodologically assurance that the provider
will act in the benefits of consumer even
providing returns as expected. I would not
use such technologies until my business is
protected.
One outcome
of taking a DevOps approach is speeding development but
DevOps heavily
leverages principles reaching back to Lean development and
Toyota. I recently gave an internal presentation on
how the buzzwords of Lean, Lean-Agile, Scaled Agile,
Miroservices, Containers,
and DevOps actually reinforce each other and provide real
value. The corresponding principles are valuable
even if the emphasis isn’t on assembly.
The merge between Dev and Ops is an important example of
generating value. The Scaled Agile Framework (SAFe) is an
example of an evolving framework for multiple teams and
traceability to
enterprise goals and priorities.
- … in the
SOA-RM one uses a service without having a
private copy of it and basically accept
changes as they occur, but with microservices
one retrieves a private copy and receives
notice when there's an update. – This is a delicate topic
or I misunderstand something. If a SOA
Service is only an interface (which I
disagree with), the consumer does not need
to have a private copy of the interface
because the SW behind the interface must
construct this interface in a way that can
handle multiple concurrent requests (based
on the assumption that a normal service
should be able to serve anyone at any time;
otherwise it is a bad service, if at all).
If consider that the SOA Service has a body
(the working executable) and interfaces, the
body should be either multithreaded or work
via multiple instances (i.e. the service is,
actually, a Factory of instances). In this
case, each consumer’s request owns the
thread or instance. If the interface
changes, the consumer SW will be broken; if
the body changes in a way that impacts the
Service Contract, the notification of
customer is mandatory. Plus, a SOA Service
is always bonded with the Execution Context.
Microservices do not have such a bound, they do not know who use them and, thus, no notifications can be sent to nowhere. Microservices have a cloudy concept of the body, which may be humongous and, definitely, cannot be “retrieved” for the consumer. It seems that Microservices are also Factories generating an instance per request but this is the “interface” instance – a typical model used in programming languages. It is unclear to me what may be updated? If this is a new code in the “interface”, then there may be a notification when the instance-in-use should be undeployed to be replaced by a new code, but it is impossible to generate new instance without a new consumer request. Also, it is unclear how a notification can be delivered without a knowledge who use the instance… Ken, to me, the quoted statement is quite unclear; it does not seem right.
The SOA service is the
access mechanism, which
can be more than merely the specification of an
interface. For example, the SOA service can invoke
authentication and authorization logic before allowing the
access. Or the SOA service can validate the request. You
also provide a good example relevant to
the cloud where load balancing can result in spinning up
additional resources
as needed. A microservice architecture
would emphasize defining pieces that are sufficiently
independent that you
could spin up or down the needed resources.
You could think of this as separate resources for the
underlying
capability and the SOA service. A microservice could make
use of a pub/sub
capability to inform a consumer that a microservice has
changed or something in
the request could trigger a response that includes a
recommendation to update
the local microservice. This is in line
with your “undeploy” statement. I don’t see microservices
as being factories;
the load balancers are the factories that create the
microservice instance from
the specifying template/image. One hole in SOA was it was
assumed by some that
the service provider could make changes at will and these
changes suddenly
showed up without warning if the interface didn’t change.
With microservices and containers, the
consumer can be explicitly warned that something will be
triggering an update
of what they have been using and the consumer has some
control over whether to
accept the update. So, yes, this is a big deal
from the SOA
standpoint that consumers have private copies. The
provider controls the
package that is delivered. In addition
to the underlying capability and the SOA service to access
it, the defining
image also specifies the server configuration on which the
service
executes. Assuming the ability to
construct a server on the fly would have been ridiculous;
now it is
commonplace. I don’t think private
copies were feasible when we wrote the SOA-RM.
I think they are much more feasible now for compact
resources and
sufficient connectivity. Despite the
microservice emphasis on independence, there may still be
room for our original
idea of a network accessible resource when a local copy is
insufficient or
infeasible, or the still somewhat open case of reconciling
data changes. Let’s
look at a different twist: is AWS EC2 a SOA service? It
provides access to the capability to spin
up the specified server, making use of an AWS underlying
capability through a
well-defined interface and per a well-defined execution
context. AWS constantly makes changes to Ec2 and the
consumer may make use of an updated interface to make
use of new capabilities
or the consumer may just get changes that are
distributed but don’t require an
interface change. Also, we are obviously
crossing ownership boundaries. The
underlying capability is likely implemented as a set of
microservices, but SOA
doesn’t care about that.
- Ken noted,
with microservices the process of update is
also simplified. Ken said that with
microservice bounded context the idea of
getting a new image is acceptable but
downloading say a whole oracle database
wouldn't be. So, quick exchange of
microservices is doable as long as we keep the
pieces small. – Well, I have never heard that
Microservices have fixed, concrete body.
They are interfaces with declared
functionality, which is not formally
documented-and-tied to the MS. The MS
appears as an entrance into an area
without boundaries. Also, what is the
mechanism that bounds the Microservice
with the context?
I don’t see microservices as
merely interfaces with declared functionality
but rather declared outcomes from an image with a declared
interface. I believe the microservice includes or
otherwise accesses what you call the “body” that gives
rise to the outcomes. I think it would be interesting
to further explore how the
microservice bounded context compares to the execution
context. I believe there may be an alignment.
--
Rex Brooks
Starbourne Communications Design
Email: rexb@starbourne.com
GeoAddress:
1361 Addison St. Apt. A
Berkeley, CA 94702
Phone: 510-898-0670
|