[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] the passenger bus use/reuse [was: [soa-rm] Microservices re-use?]
On Jun 17, 2016, at 6:12 AM, Mike Poulin <mpoulin@usa.com> wrote:Ken,let me try to answer your question - I have not thought about such angel.1. I am not clear how a new bus assigned to particule route can be linked to a MS Container. What are the MS in this case? [MS are supposed to be components of something - whose components are they in this case?]. I think that an MS Container is NOT the same thing as an App comprised/composed of MS; it is similar to old EJBs: an Application Server has a 'business container'=execution environmnet for EJBs, which can compose a structure/application where the EJBs work with each other.
2. It seems that the answer to 1. is in the idea that a bus is container for an arbitrary payload. I disagree - a bus is designed and sold (i.e. its Service Description defines particular functionality - carry passangers) as a single unit vihicle on wheels aimed to carrey groups of up to 80 people (currently). Thus, the bus Service Description specifies particular load and use pattern. People cannot be seemed as MS becuase they are not a part of the bus; they are not integrated with the bus, they interact with the bus, plus, theu do not share the same goals becuase everyone aimes to his/her stop and actually enforced by the bus to go via other stops required by other passengers.
3. I tend to consider this use pattern as a part/sort of an Execution Context. If we accept this concideration, we can fefine the difference between reuse and multiple use. That is, a use of the service (with specified business function and RWE) multiple times in the same EC is a 'multiple use' - the most common business practice/situation; a use of service in the different EC (not specified in the Service Description) is a 'reuse'. I know that this turns IT upside-down re the purpose of services. However, it is their own fault - initially IT turned SOA on its head claiming a pure technology feature (aka 'reuse of code'=multiple use) a SOA feature. If SOA is a model of business/human/technology activities oriented on service, 'reuse'=multiple use is not a special quality that can deserve additional funding, i.e. it would not be possible to 'sell' technical SOA to check-book holders. It is the IT fault in calling white - black. I only uncover that this is really white and no speculations are accepted. [In business, reuse (use in different EC) exists in VERY limited scope and is not that valuable while multiple use is the basis of SO business].
4. <<I can agree with interface=API but I do not see that as limiting.>> IMO, the limiting her is exactly the same as we had them for Web Service (=API=interface): API/interface define only technology communication contract based on the assumption that the name, input data types and output data type (not reallu RWE) are so fine-frained that explicitly define what the implementation does. This is a classic approach of programmers while we are talking about _functions_ of different complexity. In other words, API/interface do not need Service Description and Service Contract (and a half of SOA RAF). The explicit API-based interfaces are proved (in programming) as terrible in managing any updates (i.e. they are not suitable for the business needs and they result in a business distrust in an ability of IT to adopt changes as quickly as needed). They are the worsed interfaces for business use with 100% impact on existing consumer base for every change. Years of work with Web Services were spent on finding that the WSDL should include only 1 coarse-grained operation and use the Command pattern carring different commands/activities/task (encapculated in the message) that do not enforce consumers, who are not interested in the change, to modify their code. This, a return to API is a step back from the point of progress achieved already.
5. SOA in the form of RAF does have a business value and several business benefits, which allowed me and a few colleagues to apply it in Business Archtiecture for enterprises with very positive effect. Microservices do not have obvious business value and benefits over all: saved time and effortsm on API-type construction of Apps totally wasted on maintenence and unforseen problems when a change to be adopted. In our world, a rapit/flexible adoption of changes is the competitive advantage of its own for any business organization.
Thanbks,- MichaelSent: Thursday, June 16, 2016 at 7:20 PM
From: "Ken Laskey" <klaskey@mitre.org>
To: "Mike Poulin" <mpoulin@usa.com>
Cc: soa-rm@lists.oasis-open.org
Subject: the passenger bus use/reuse [was: [soa-rm] Microservices re-use?]I started responding to this weeks ago and just found the draft, so I am sending this while still catching up on accumulated emails since then.-----Michael,I agree with your questioning of the term reuse. In a SOA-RM context, interacting with a service leads to certain real world effects, and a consumer uses the service if they would like to realize those RWEs. To your bus example, this appears to be what we would call multiple uses of the same service. However, if the bus company buys an extra bus each week and dedicates that new bus to a specific route/time/etc. that would seem like single use in a microservice VM/container. Or is it?I also agree with the use of the bus to carry construction materials is fundamentally different. In many such circumstances, the fundamental RWE can be described at a more abstract level but remains the same (or comes into greater clarity). The bus can carry certain volume and weight as “payload”, where that payload can be people, construction materials, some combination, or other things. Why if the bus keeps the same route and schedule but now carries both people and construction materials. Combinations are endless and it is fruitless to draw the line of when there is reuse or something else. Basically, the service delivers RWE and you use it if you can make it deliver what you need when you need it.I can agree with interface=API but I do not see that as limiting. I am not sure where I find the implementation or how I construct the implementation for which SOA/microservice/… benefits. That is where I am looking for clarity.BTW, I still think there is a relevant interface granularity argument lurking here.------More to come later.Ken------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508On Jun 3, 2016, at 12:51 PM, Mike Poulin <mpoulin@usa.com> wrote:--------------------------------------------------------------------- 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.phpHello Gentlemen,though I miss the meetings, I'd like to participate in this very interesting discussion.Martin: "This is a request for input on how re-use is accomplished in the microservices world."I'd like to start with a clarification of a term "re-use". If I use a bus to carry passengers along a route 5 times a day, do I reuse the bus (bus services) or I simply use an entity (or its instance) for the purpose it has been created as many times as needed? If next day the same physical bus would run along a different route also 5 times, do I reuse the bus service or just use the same service for doing exactly the same as 'yesterday' (while answers to WHEN , WHERE and for WHOM are different 'today')? My answer is - this is not a reuse, but a normal use of the entity designed for multiple 'executions'. It is the same as I am dressed in the same suite when go to my office or to my client's place, I do not 're-wear' the suite.At the level of our 'business' comprehension, we believe that something different happens to the bus or to the suite if, for example, the same physical bus is loaded by whatever construction materials and carries them to the construction place or I wear the same suite to swim in the pool. What is the difference? There are two of them - 1) a change of the purpose of the entity; 2) a principally change in the execution context. I say - if we utilise a service for different purposes or in the principally different execution context, we re-use it. All these arguments were published by me several years ago in InfoQ and similar popular sites.The conclusion of this simple consideration is terrible for the IT's pray on 're-use'. If you re-call when this idea popped-up, you would find it was a time when IT wanted to adopt (technical) SOA and wanted to convince management to fund this. Even by that time, it was clear enough that the idea of re-use of code as a motivation for funding was quite wrong, because it was dictated by reducing cost of software on expensive computing power (regardless the fact that hardware cost climbed down quickly eliminating the business efficiency of the cost reduction of the software). At the same time, a highly re-used code created a problem of tremendous interdependency of the applications on this code and led to a need of keeping all applications under a single control- otherwise, it would not be possible to update/modify/refactor shared code and update all dependent apps.An idea of a reusable service had to signal management that IT minimises the requested funds. If IT would operate in line (in agility) with the business tasks, a topic of re-use would never surface – in the business functionality landscape there are very few activities are re-used, i.e. a ‘re-use’ could not be the major candidate for funding.Let’s look into the statement “…that a microservice instance is confined inside a single container”. This is accompanied by a question: can a microservice be owned by someone other than the developer of the microservice-based application?If we assume that a microservice (aside from pure libraries included in the microservice realm) is an entity with its interface=API AND its working part (implementation), how would the service provider know what the developer does with the microservice like placing in a container? This means to me, that microservice-in-a-container does not have its working part - a body or an implementation. In other words, a microservice is a remote API with a thin Client code, which is different from the billions of other ‘old’ API only in that it relies on the HTTP communication protocol. It is a lightweight-client/interface rather than a service. And as such this lightweight-client must be confined/tuned/linked/configured within its run-time container, as usually. Don’t we compare apples and oranges?Let’s go back to “this would be a significant distinction from an “SOA-style” service, in that it would mean that the only way a microservice could be re-used outside the container would be to copy the code and run an entirely separate instance in another container or elsewhere.” Each run-time environment requires all its elements to be correspondingly adjusted, i.e. the lightweight-client/interface (=microservice) to be adjusted, but this does not mean that the body or working implementation should be adjusted for each run-time environment of its remote API (aka Agent or specialised consumer code). If in “SOA-style” service we separate service from its consumers, it seems that microservices represent service proxies in the form of API. In other words, a real consumer has to deal with the lightweight-client/interface (=service proxy), which utilises the end-point of the real service (=working body/implementation) in run-time. It seems very similar to Web Services technology where the consumer’s side marshalling code (generated from the WSDL) is now called “microservice”. This is how people make money from the changed names.I am afraid that based on the explanation above, the Martin’s conclusions – “This “confinement” also implies that microservces are not “multi-user” (or “multi-tennant”) whereas multi-tenant capability might be considered an intrinsic characteristic of SOA-style services. These apparent characteristics of microservices would seem to give away most of the potential efficiencies of a scaleable, easily maintainable shared service.” – require re-thinking.(To be continued on another topic)Cheers,- MichaelSent: Wednesday, June 01, 2016 at 12:57 AM
From: rexbroo <rexb@starbourne.com>
To: soa-rm@lists.oasis-open.org
Subject: Re: [soa-rm] Microservices re-use?Ken, Martin,
This is turning into an interesting conversation, and one that needs to be made outside of the app provider/paas context. Their self-interest tends to get in the way. I think that's why our ongoing work on SOA is relevent and, to use Ken's metaphor, the kitchen may need to be remodeled.
I think the key issues revolve around ownership boundaries and governance, hence the difficulty with maintaining data integrity across concurrent micro-service iterations housed in containers in differing execution contexts, ie. public v. private clouds, inter-enterprise infrastructure, governmental systems. I can foresee data service providers coming into existence to service these cross-environment apps/microservices that use common datasources.
I also look forward to hearing from a micro-services developer.
Rex
On 5/30/2016 8:50 PM, Martin Smith wrote:Ken -- Always good to open the aperture: referring to your idea of moving the app to the data, etc.However. You identified one requirement for making this work: very robust config/patch/revision control to keep all the copies of the code in synch. Not trivial.Backing further up the development process I think there's another hard problem: where do the requirements for the micro-service come from? Is the motivation for someone to make a micro-service to meet the needs of a single, specific containerized application? If so, it seems a remote possibility that that specification would closely meet the needs of other applications. Result: minimal re-use, unless the whole application is copied. (I admit I am assuming what provides the motivation for creation of a micro-service.)I keep thinking: how does someone creating a micro-service differ from someone adding a new function to an open-source project on Github? The latter seems more valuable both because it's likely to be written in contemplation of re-use by others, and also the code is probably more efficient because it probably uses in-process communication vs. sockets.Looking forward to hearing from a micro-services developer!!MartinPS--Also just starting to noodle around with AWS Lambda ("serverless" framework.)On Fri, May 27, 2016 at 4:45 PM, Ken Laskey <klaskey@mitre.org> wrote:Doing a bit more reading, a consideration could be whether it is easier to move the data to the processing or the processing to the data.In our work on describing SOA, we assumed crossing ownership boundaries was a critical part of the paradigm: the consumer used services where they were offered rather than having a private copy. Part of the rationale was that private copies held by consumers (who were effectively also forcing themselves to be providers) often meant enumerable modified copies that became one-of-a-kind albatrosses to maintain. Under the SOA paradigm, the consumer and provider interacted under agreed upon terms (the execution context) with neither under the other’s control. (What control really existed before is another topic for discussion.)But with VMs and containers, we should be able to manage exact copies, including making sure the copies have a known, controlled configuration. So now if I generate terabytes of data a day, it may be more efficient to bring the processing to the data rather than the data to the processing. My configuration management makes sure the “manifest” for the new VM/container is up to date at all needed locations, and things like applications needing to be deployed are already pre-staged to any place that may need that application.What does this say about deploying on-premise infrastructure vs. cloud vs. what combination? What SOA principles are still useful to guide us? The house of the SOA paradigm may still basically function but it may need to have the kitchen remodeled.Ken------------------------------------------------------------------------------
Dr. Kenneth Laskey
MITRE Corporation, M/S F510 phone: 703-983-7934
7515 Colshire Drive fax: 703-983-1379
McLean VA 22102-7508On May 25, 2016, at 10:58 AM, Martin Smith <bfc.mclean@gmail.com> wrote:This is a request for input on how re-use is accomplished in the microservices world. Please provide info or comment via this list or via the public comment list for this TC: soa-rm-comment@lists.oasis-open.orgPlease also pass this request to others in your network who may have microservices implementation experience.In the April 13, 2016, meeting of the TC there was a discussion of comparison of characteristics of SOA architecture/design principles vs. "microservices" architecture (with specific reference to NIST Special Publication 800-180 (DRAFT) NIST Definition of Microservices, Application Containers and System Virtual Machines of Feb 2016.)One issue discussed was how re-use is accomplished in a microservices-style implementation.It was suggested that the NIST SP seemed to imply that a microservice instance is confined inside a single container. If so, this would be a significant distinction from an “SOA-style” service, in that it would mean that the only way a microservice could be re-used outside the container would be to copy the code and run an entirely separate instance in another container or elsewhere. This “confinement” also implies that microservces are not “multi-user” (or “multi-tennant”) whereas multi-tenant capability might be considered an intrinsic characteristic of SOA-style services. These apparent characteristics of microservices would seem to give away most of the potential efficiencies of a scaleable, easily maintainable shared service.Can anyone with microservices implementation experience explain how re-use is accomplished in this architectural style?Martin----Martin F Smith, PrincipalBFC Consulting, LLCMcLean, Va 22102703 506-0159703 389-3224 mobile-- Rex Brooks Starbourne Communications Design Email: rexb@starbourne.com GeoAddress: 1361 Addison St. Apt. A Berkeley, CA 94702 Phone: 510-898-0670
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]