Re: [soa-rm] Groups - Draft - Minutes-SOA-RM TC June-21-2017.doc uploade

------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S H330 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-7996
McLean VA 22102-7508

On Jun 28, 2017, at 11:26 AM, Mike Poulin <mpoulin@usa.com> wrote:

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.

… 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.

Cheers,

- Michael Poulin

Sent: Wednesday, June 21, 2017 at 7:10 PM
From: "Rex Brooks" <rexb@starbourne.com>
To: soa-rm@lists.oasis-open.org
Subject: [soa-rm] Groups - Draft - Minutes-SOA-RM TC June-21-2017.doc uploaded

Document Name: Draft - Minutes-SOA-RM TC June-21-2017.doc
No description provided.
Download Latest Revision
Public Download Link
Submitter: Rex Brooks
Group: OASIS SOA Reference Model TC
Folder: Meeting Notes
Date submitted: 2017-06-21 11:10:35

--------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php

soa-rm message